Mail Archives: cygwin/2002/04/02/11:30:20
> 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/
- Raw text -