Technology Temple

The GNU Debug­ger is a very pow­er­ful and fear­some beast. It seems that I’ve found a cou­ple of use­ful tricks which are not pop­u­lar as they should.

• The watch com­mand: any script kid­die knows about break­points. Watch­points are based on the same con­cept applied to not to code, but to data mem­ory. You can set a watch­point on a vari­able using the fol­low­ing syn­tax: watch var. It is also pos­si­ble to watch a spe­cific mem­ory address with the syn­tax: watch *0xdeadbeaf. A watch­point trig­gers when the con­tents of the mem­ory loca­tion changes, so they are use­ful when try­ing to find out when a vari­able is mod­i­fied. (remem­ber that in C++ you should always use pri­vate and pro­tected sec­tions to stop vari­ables from being accessed/modified out­side the expected code flow). It is also pos­si­ble to set read watch­points using the rwatch com­mand, which trig­gers when the loca­tion is accessed. This fea­ture is mainly use­ful when reverse engi­neer­ing com­piled code, to find out which code path make use/are influ­enced by a cer­tain variable/memory loca­tion. The major draw­back of watch­points is that com­mon hard­ware sup­port only a few of them. When gdb runs out of hard­ware watch­points it resorts to soft­ware emu­la­tion, which is very slow, and not pos­si­ble at all for the read ones. This also means that putting watch­points on big struc­tures and classes is highly discorauged.
• set print object: If you’ve ever made exten­sive use of poly­mor­phic classes or oth­er­wise com­plex class hier­ar­chies, you will find this set­ting very use­ful. The print com­mand, when print­ing point­ers of base classes, will take look at the vir­tual table to find out the actual object type, and print it beside the address. More­over when deref­er­enc­ing point­ers it will print the full object con­tents, not only the base class members.
• info threads com­mand: When you face a dead­lock in your mul­ti­threaded code, the first step to under­stand the prob­lem is to find out which threads are blocked. The dead­lock is often not eas­ily repro­ducible, so should at first attach gdb the the process using the attach <pid> com­mand, the typ­ing info threads you will get for each thread the func­tion name where it is cur­rently stopped. Threads involved in a dead­lock con­di­tions are usu­ally stopped in sem_wait or sim­i­lar sem­a­phore related functions

Well... I guess I’m using gdb way too much, maybe I’m not a good programmer

The GNU Debug­ger is a very pow­er­ful and fear­some beast. It seems that I’ve found a cou­ple of use­ful tricks which are not pop­u­lar as they should.

• The watch com­mand: any script kid­die knows about break­points. Watch­points are based on the same con­cept applied to not to code, but to data mem­ory. You can set a watch­point on a vari­able using the fol­low­ing syn­tax: watch var. It is also pos­si­ble to watch a spe­cific mem­ory address with the syn­tax: watch *0xdeadbeaf. A watch­point trig­gers when the con­tents of the mem­ory loca­tion changes, so they are use­ful when try­ing to find out when a vari­able is mod­i­fied. (remem­ber that in C++ you should always use pri­vate and pro­tected sec­tions to stop vari­ables from being accessed/modified out­side the expected code flow). It is also pos­si­ble to set read watch­points using the rwatch com­mand, which trig­gers when the loca­tion is accessed. This fea­ture is mainly use­ful when reverse engi­neer­ing com­piled code, to find out which code path make use/are influ­enced by a cer­tain variable/memory loca­tion. The major draw­back of watch­points is that com­mon hard­ware sup­port only a few of them. When gdb runs out of hard­ware watch­points it resorts to soft­ware emu­la­tion, which is very slow, and not pos­si­ble at all for the read ones. This also means that putting watch­points on big struc­tures and classes is highly discorauged.
• set print object: If you’ve ever made exten­sive use of poly­mor­phic classes or oth­er­wise com­plex class hier­ar­chies, you will find this set­ting very use­ful. The print com­mand, when print­ing point­ers of base classes, will take look at the vir­tual table to find out the actual object type, and print it beside the address. More­over when deref­er­enc­ing point­ers it will print the full object con­tents, not only the base class members.
• info threads com­mand: When you face a dead­lock in your mul­ti­threaded code, the first step to under­stand the prob­lem is to find out which threads are blocked. The dead­lock is often not eas­ily repro­ducible, so should at first attach gdb the the process using the attach <pid> com­mand, the typ­ing info threads you will get for each thread the func­tion name where it is cur­rently stopped. Threads involved in a dead­lock con­di­tions are usu­ally stopped in sem_wait or sim­i­lar sem­a­phore related functions

Well... I guess I’m using gdb way too much, maybe I’m not a good programmer