|
From: Francesco Z. N. <fra...@gm...> - 2011-10-10 19:39:39
|
Dear all if I understand correctly, the function VG_(get_datasym_and_offset)(..addr..&name...) looks at the debug informations to return the name and the offset of the (global) variable stored at addr. This works fine on linux, but when I compile my valgrind application on macosx 10.6 (valgrind comes from a recent e.g. < 1 month svn) the above does not seem to work anymore: name is always null (independently of the --dsymutil=yes option -- and yes, I checked that my binary has debug informations with gdb). I am confused. I though that in both cases the debug format used was DWARF, and I can't understand why it does not work on mac. Do you have any intuition / suggestion? I can provide a 3 lines patch to lackey to reproduce the problem. Thank you in advance. Best -francesco |
|
From: Julian S. <js...@ac...> - 2011-10-10 20:34:13
|
On Monday, October 10, 2011, Francesco Zappa Nardelli wrote: > Dear all > > if I understand correctly, the function > > VG_(get_datasym_and_offset)(..addr..&name...) > > looks at the debug informations to return the name and the offset of > the (global) variable stored at addr. > > This works fine on linux, but when I compile my valgrind application > on macosx 10.6 (valgrind comes from a recent e.g. < 1 month svn) the > above does not seem to work anymore: name is always null > (independently of the --dsymutil=yes option -- and yes, I checked that > my binary has debug informations with gdb). > > I am confused. I though that in both cases the debug format used was > DWARF, and I can't understand why it does not work on mac. Do you > have any intuition / suggestion? The problem is that reading of data symbol addresses was never made to work (properly? at all? I can't remember) for Mach-O. Hence VG_(get_datasym_and_offset) will never return any useful info. There is a big comment about this about 100 lines after the start of ML_(read_macho_debug_info) in coregrind/m_debuginfo/readmacho.c. If you want to become an expert on Mach-O and figure out how to fix this (or you are one already), that would be great. The normal problem is to come up with correct values for di->data_avma and di->data_svma (and therefore for di->data_bias). For explanation of the avma/svma/bias values, see comment at the top of debuginfo.c. I'm afraid there's no easy (1/2 hour) fix for this, unless maybe you are a Mach-O guru. J |
|
From: Francesco Z. N. <fra...@gm...> - 2011-10-11 08:51:56
|
Dear Julian > I'm afraid there's no easy (1/2 hour) fix for this, unless maybe you are a Mach-O guru. I am afraid I am not. Thanks for your help, will find an alternative way. -francesco |