Fwiw, there is a project coming that looks pretty cool, that addresses a similar problem in a non-gdb context, and that is something called GNU poke[1]. It is a tool for reading and modifying binary files in a symbol fashion. It does require writing definitions (called "pickles") of the binary file format, but if you work on the same kind of files a lot it might be worth investing in writing one, or someone else might have already. I learned about poke by watching a video[2] of a conference I don't think I'd heard of before, called Kernel Recipes from last month. GNU poke is not to version 1 yet, so it is still in flux, but it looked like a potentially useful tool.
[1] http://jemarch.net/poke.html [2] https://youtu.be/dvtZsBlSECk?t=26362 On Fri, Oct 18, 2019 at 9:57 AM Galen Seitz <[email protected]> wrote: > > I occasionally have the need to use gdb for debugging, but not often > enough to be a gdb expert. Typically this debugging is on embedded > systems that have microcontrollers with many peripherals that need to be > controlled, such as AVR or Cortex M devices. The peripheral register > addresses and the bits within them are often defined using C > preprocessor macros. This is fine for coding, but when debugging, > information regarding these macros is typically lost. That means if I > want to examine a hardware register, such as a GPIO port, I have to look > up the appropriate peripheral address, and then do an examine memory > command at that address: > > # Read port E output data register > (gdb) x/x 0x40021014 > 0x40021014: 0x0000007f > > This morning I was looking for a script that would turn preprocessor > macros into gdb macros, in hopes of simplifying this. That's when I > discovered you can tell gcc to add preprocessor macros to the debug > symbols. When compiling for debugging, instead of passing '-g', you > pass '-ggdb3'. Now you can do this: > > # Read port E output data register > (gdb) p/x GPIOE->ODR > $1 = 0x7f > > This is far, far easier than having to look up addresses and bit > positions. The only hitch is that when you halt your code, you have to > be stopped in a context where the preprocessor macros were present. > Most of the time this won't be a problem. > > Even if you're not debugging code that talks to hardware, it can be > quite useful to print out the value of a macro, particularly if it's one > that involves a calculation or another macro. > > // A define in my code. > #define ADC_HV_DIVISOR ((499 + 200e3) / 499) > > # What's that value? > (gdb) p ADC_HV_DIVISOR > $2 = 401.80160320641284 > > > There are some other useful tips here. This particular tip is #5 in the > article. > <https://blogs.oracle.com/linux/8-gdb-tricks-you-should-know-v2> > > > galen > -- > Galen Seitz > [email protected] > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
