I remember being impressed by someone using windbg to map an address back to the pointers. I was never useful with windbg but looking now it looks like it has a builtin to scan memory for values; I'm not sure how you'd go back from those addresses to code, though.
Compilers can generate a map file that associates relative addresses with variable and function names. They can also store such information in the compiled executable.
I use this for debugging embedded code, if I get a null pointer exception or bus fault I log the calling address. 99% of the time running addr2line points me directly to the offending lines of code. There are also builtins that allow you to walk back up the stack and and thus fink on who's been naughty.
For those that don't know, rr is a fantastically powerful tool that everyone should learn about. It's a record-and-replay debugger (actually a backend for gdb) with low overhead so it's actually practical for normal debugging, unlike the standard r-and-r backends built into gdb, which have very high overheads. Since the user interface is currently via gdb, it might seem a bit underwhelming at the moment.
I remember being impressed by someone using windbg to map an address back to the pointers. I was never useful with windbg but looking now it looks like it has a builtin to scan memory for values; I'm not sure how you'd go back from those addresses to code, though.
Compilers can generate a map file that associates relative addresses with variable and function names. They can also store such information in the compiled executable.
I use this for debugging embedded code, if I get a null pointer exception or bus fault I log the calling address. 99% of the time running addr2line points me directly to the offending lines of code. There are also builtins that allow you to walk back up the stack and and thus fink on who's been naughty.
For those that don't know, rr is a fantastically powerful tool that everyone should learn about. It's a record-and-replay debugger (actually a backend for gdb) with low overhead so it's actually practical for normal debugging, unlike the standard r-and-r backends built into gdb, which have very high overheads. Since the user interface is currently via gdb, it might seem a bit underwhelming at the moment.