|
From: Nicholas N. <n.n...@gm...> - 2009-01-19 02:47:03
|
Hi, I get lots of regtest failures on Mac at the moment. Many are because debug info isn't being found. Here's an example message from memcheck/tests/badaddrvalue: ==56103== Invalid write of size 1 ==56103== at 0x1FBE: main (in ./badaddrvalue) ==56103== Address 0x3ec34f is 1 bytes before a block of size 8 alloc'd ==56103== at 0x22D63: malloc (in /Users/njn/grind/ws2/memcheck/vgpreload_memcheck-x86-darwin.so) ==56103== by 0x1FB6: main (in ./badaddrvalue) It's not finding the debug info for the executable 'badaddrvalue', nor for vgpreload_memcheck-x86-darwin.so; all those stack trace entries should have source code locations. I discovered that on Darwin, DWARF debug info doesn't get put into executables. Rather, if you do something like this: gcc -g a.c Then alongside the created executable 'a.out', a directory called 'a.out.dSYM' is made, and it holds the debug info. Greg's patch looks for such directories when loading debuginfo. However, if you do the compilation in two steps: gcc -g -c a.c gcc -g a.o then the .dSYM directory is not created. Rather, you have to do an additional step to create it: dsymutil a.out Unfortunately, all our regression tests and libraries are built using the two-step approach, which is why no debug info is found. Greg, you originally had '-gstabs' in AM_CFLAGS_BASE and AM_CFLAGS_PIC in Makefile.flags.am. I changed this back to -g because it broke things on Linux and didn't seem to make any difference on Darwin anyway. Perhaps this was an attempt to avoid this .dSYM problem? Anyway, I guess we need to build these .dSYM dirs whenever necessary. Annoyingly enough, there doesn't seem to be any way to automatically run 'dsymutil' when linking, so I think some Makefile.am magic will be needed to ensure that 'dsymutil' gets run after linking; I don't yet know what that magic will look like. Or does anyone else have any other ideas? Nick |
|
From: Tom H. <to...@co...> - 2009-01-19 08:49:41
|
Nicholas Nethercote wrote: > I discovered that on Darwin, DWARF debug info doesn't get put into > executables. Rather, if you do something like this: > > gcc -g a.c > > Then alongside the created executable 'a.out', a directory called > 'a.out.dSYM' is made, and it holds the debug info. Greg's patch looks > for such directories when loading debuginfo. > > However, if you do the compilation in two steps: > > gcc -g -c a.c > gcc -g a.o > > then the .dSYM directory is not created. Rather, you have to do an > additional step to create it: > > dsymutil a.out That's quite bizarre though, as it means the data must be present in the executable if dsymutil can extract it to the separate directory? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-19 08:57:11
|
On Mon, Jan 19, 2009 at 7:49 PM, Tom Hughes <to...@co...> wrote: > Nicholas Nethercote wrote: > >> I discovered that on Darwin, DWARF debug info doesn't get put into >> executables. Rather, if you do something like this: >> >> gcc -g a.c >> >> Then alongside the created executable 'a.out', a directory called >> 'a.out.dSYM' is made, and it holds the debug info. Greg's patch looks >> for such directories when loading debuginfo. >> >> However, if you do the compilation in two steps: >> >> gcc -g -c a.c >> gcc -g a.o >> >> then the .dSYM directory is not created. Rather, you have to do an >> additional step to create it: >> >> dsymutil a.out > > That's quite bizarre though, as it means the data must be present in the > executable if dsymutil can extract it to the separate directory? AIUI the debug info is in the .o files, and the .o files can be found from the executable. See http://wiki.dwarfstd.org/index.php?title=Apple's_"Lazy"_DWARF_Scheme N |
|
From: Greg P. <gp...@ap...> - 2009-01-19 19:43:05
|
On Jan 18, 2009, at 5:45 PM, Nicholas Nethercote wrote: > Greg, you originally had '-gstabs' in AM_CFLAGS_BASE and AM_CFLAGS_PIC > in Makefile.flags.am. I changed this back to -g because it broke > things on Linux and didn't seem to make any difference on Darwin > anyway. Perhaps this was an attempt to avoid this .dSYM problem? That was intended to get useful debug info for valgrind itself, when debugging valgrind. -gstabs might work for the regtests too, though. I think Xcode is able to build dwarf-in-executable, but I don't know what options or programs it uses to do that. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-23 06:50:04
|
On Tue, Jan 20, 2009 at 6:33 AM, Greg Parker <gp...@ap...> wrote: > On Jan 18, 2009, at 5:45 PM, Nicholas Nethercote wrote: >> >> Greg, you originally had '-gstabs' in AM_CFLAGS_BASE and AM_CFLAGS_PIC >> in Makefile.flags.am. I changed this back to -g because it broke >> things on Linux and didn't seem to make any difference on Darwin >> anyway. Perhaps this was an attempt to avoid this .dSYM problem? > > That was intended to get useful debug info for valgrind itself, when > debugging valgrind. -gstabs might work for the regtests too, though. > > I think Xcode is able to build dwarf-in-executable, but I don't know what > options or programs it uses to do that. I got the .dSYM dirs being built for the regtests by hacking up a replacement linker script -- on non-Darwin platforms, it just calls the C compiler to do the linking. On Darwin it does that and then runs dsymutil on the result. It's hacky but it works for executables. Now I'm stuck generating debug info for Valgrind's replacement libraries, eg. coregrind/libreplacemalloc_toolpreload_x86_darwin.a. On Linux, if you create a .a file using 'ar', any debug info in the input .o files is preserved. On Darwin, it's not, and dsymutil doesn't appear to work on .a files. This is a problem! Unfortunately there seems to be very little documentation about .dSYM dirs on the web. Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-27 04:26:26
|
On Tue, Jan 20, 2009 at 6:33 AM, Greg Parker <gp...@ap...> wrote: > > I think Xcode is able to build dwarf-in-executable, but I don't know what > options or programs it uses to do that. I tried using Xcode. It has three options for debug info: stabs, DWARF, DWARF + dSYM. The DWARF seems to be exactly the same as DWARF + dSYM except that it doesn't create the .dSYM directory -- ie. it doesn't put the debug info in the executable, just the object files, which isn't much help. Frustrating. Nick |