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 file. 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: http://www.postgresql.org/mailpref/pgsql-hackers
