> I haven't looked at it recently, but I really doubt that the code would > deal with the stabs symbol table that gcc/gas/ld use and allow symbolic > representation of symbols.
My code certainly doesn't, it only deals with basic Win32. You get symbols for addresses only if imagehlp library can get them. IIRC this means anything exported from a DLL if no other info is available, and I'd assume it works the same on cygwin since the export mechanism doesn't change. > The hints I gave in my previous email really are the best way to go on > this. Quite right. One addition: address-to-symbol look-up gets complicated with dynamically loaded shared libraries. Post-mortem analysis (say addr2line) doesn't combine well with dynamic loading, which may or may not matter, depending on how much grief you are ready to get into. It does matter to me, hence I use imagehlp, and it has worked for so far (but I haven't used the code on gcc/cygwin, only for native Win32, and virtually all our code is in DLLs and is exported, so most gets mapped correctly; I should check what it actually does on MSVC++, it is a long time I looked at that). To read read symbols from a running program with bfd, look at mpatrol; it has code to fetch symbols from the program itself and any shared libraries currently mapped in. However, the version of mpatrol I used only reads symbols at program start-up, which isn't so great for dynamic loading. (On the other hand, reading symbol data in fatal signal handler is not the greatest of ideas either :-) //lat -- Real programmers don't document. Documentation is for simps who can't read the listings or the object deck. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
