On 2 Apr 2014, at 5:43 PM, Tom Lane wrote:
> I poked around a bit, and so far as I can tell, OS X does not store debug
> symbol tables in executables.  It looks like gdb goes to the .o files when
> it wants debug info.  What's in the .o files is good ol' DWARF (at least
> in reasonably recent OS X releases), so it's not any harder to pull out
> the typedef names than it is on Linux.  The problem is that you gotta
> iterate over all the .o files in the build tree rather than the installed
> executables.  I looked at fixing find_typedefs but it seems like it's
> pretty fixated on the latter approach; any thoughts on how to revise it?

The Apple development tools gather the debug information during the final link 
stage (the one that produces the executable or shared object) using "dsymutil", 
which simply iterates over all of the .o files and links the debug info into a 
separate object, foo.dSYM. Apple's gdb and lldb then find the relevant .dSYM 
file using a per-build UUID embedded in the executable/library/debug symbol 

The dSYM file is a normal object file which has the DWARF sections but not the 
usual text/data sections, so if it can be generated/found, it should be 
possible to dump the DWARF data from it and look for typedefs that way.

(I'm pretty sure that if you were to run dsymutil and then merge the resulting 
object file's sections into the executable/shlib, you'd get a perfectly 
functional and debuggable result without having to look for or cart around the 
extra dSYM file--- I haven't tried this though.)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to