From: Julian S. <js...@ac...> - 2009-01-28 11:15:01
|
Hi, I'd like to release Valgrind 3.4.1 on Sunday 15 Feb. This is much sooner than usual between x.y.z releases, but it's clear now that 3.4.0 had some serious regressions in stack unwinding, and so it's important to push out a new stable version soon. In the past few days I merged in a bunch of stack unwinding fixes from Tom, plus misc other debuginfo reading fixes, and I think 3_4_BRANCH is now in a pretty good state. If there are any other high priority bug fixes that should go in 3.4.1, please let me know, preferably with trunk rev numbers. But please no build system changes. Josef, you committed a non-power-of-two cache size change for Callgrind. I would like to ship that in 3.4.1 if it is stable enough and will not cause any problems. (Rationale: CPUs with non-power-of-2 cache sizes are already common, and 3.4.x is likely to stay alive approximately a year). What do you think? J |
From: Tom H. <to...@co...> - 2009-01-28 12:40:42
|
Julian Seward wrote: > Josef, you committed a non-power-of-two cache size change for Callgrind. > I would like to ship that in 3.4.1 if it is stable enough and will not > cause any problems. (Rationale: CPUs with non-power-of-2 cache sizes > are already common, and 3.4.x is likely to stay alive approximately > a year). What do you think? I think we should put it in. I've just tested it on both a Core 2 with a 6Mb L2 and an Atom with a 24Kb D1 with no obvious ill effects other than the warning going away. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
From: Josef W. <Jos...@gm...> - 2009-01-28 18:19:15
|
On Wednesday 28 January 2009, Tom Hughes wrote: > > Josef, you committed a non-power-of-two cache size change for Callgrind. > > I would like to ship that in 3.4.1 if it is stable enough and will not > > cause any problems. (Rationale: CPUs with non-power-of-2 cache sizes > > are already common, and 3.4.x is likely to stay alive approximately > > a year). What do you think? Yes, that was my intention with the patch. From the stability point of view, for Cachegrind it is minimalistic, and it is sane from a technical point of view. For Callgrind, it is more or less the same, with a few "|" changed to "+" in addition. I am sufficiently sure that it is correct. All simulator variants are tested with non-power-of-two cache sizes. Also, the nightly tests just showed the addition of the 5 added tests. What do you think of the manual changes in Cachegrind? (the Callgrind manual just refers to Cachegrind). As given in the commit message, the patch needs r8912, which gets rid of some code duplication for getting the cache parameters via CPUID (obviously correct). > I think we should put it in. I've just tested it on both a Core 2 with a > 6Mb L2 and an Atom with a 24Kb D1 with no obvious ill effects other than > the warning going away. Good to know. Anyway, this was expected, as all the added tests for non-power-of-two overwrite the cache parameters to check for exactly these cases on every system. Josef > > Tom > |
From: Bart V. A. <bar...@gm...> - 2009-01-29 10:24:37
|
On Wed, Jan 28, 2009 at 12:14 PM, Julian Seward <js...@ac...> wrote: > If there are any other high priority bug fixes that should go in > 3.4.1, please let me know, preferably with trunk rev numbers. But > please no build system changes. I would like to see r9087 to go in release 3.4.1. But maybe it's best to wait for the next nightly build results before merging this change. Bart. |
From: Julian S. <js...@ac...> - 2009-01-29 10:55:04
|
> I would like to see r9087 to go in release 3.4.1. But maybe it's best > to wait for the next nightly build results before merging this change. I already added it to my list of stuff-that-needs-to-be-merged. But if you want to wait for test results, then fine; just lmk in the next few days if you want it merged. J |
From: Bart V. A. <bar...@gm...> - 2009-01-30 19:45:24
|
On Thu, Jan 29, 2009 at 11:54 AM, Julian Seward <js...@ac...> wrote: > >> I would like to see r9087 to go in release 3.4.1. But maybe it's best >> to wait for the next nightly build results before merging this change. > > I already added it to my list of stuff-that-needs-to-be-merged. But > if you want to wait for test results, then fine; just lmk in the next > few days if you want it merged. Can you please merge the trunk revisions 9087, 9090, 9091 and 9092 to the 3.4.1 branch ? The descriptions are as follows: ------------------------------------------------------------------------ r9092 | bart | 2009-01-30 19:31:54 +0100 (Fri, 30 Jan 2009) | 1 line Removed mandatory redirections for DRD since these made DRD impossible to use on openSUSE 10.3 ppc. ------------------------------------------------------------------------ r9091 | bart | 2009-01-30 18:52:39 +0100 (Fri, 30 Jan 2009) | 1 line Generalized suppression patterns. ------------------------------------------------------------------------ r9090 | bart | 2009-01-30 18:52:21 +0100 (Fri, 30 Jan 2009) | 1 line Do not only recognize .plt and .plt.got sections inside the mapped address range, but also outside the mapped address range (necessary for ppc). ------------------------------------------------------------------------ r9087 | bart | 2009-01-29 10:57:22 +0100 (Thu, 29 Jan 2009) | 1 line Suppress any error whose top frame is in libc.so. While not very elegant, this is an effective way to suppress data race reports triggered by glibc's stdio functions (which uses inlined locking functions). ------------------------------------------------------------------------ Thanks, Bart. |
From: Nicholas N. <n.n...@gm...> - 2009-01-30 22:39:23
|
On Wed, Jan 28, 2009 at 10:14 PM, Julian Seward <js...@ac...> wrote: > > If there are any other high priority bug fixes that should go in > 3.4.1, please let me know, preferably with trunk rev numbers. But > please no build system changes. On Monday I might have a fix for some borked line number reading in the stabs reader, believe it or not -- I was looking into it for the Darwin port because DWARF is such a pain on Darwin. But it probably doesn't matter for 3.4.1, I don't think stabs gets much use any more. N |
From: Julian S. <js...@ac...> - 2009-01-31 14:36:15
|
> Darwin port because DWARF is such a pain on Darwin. But it probably > doesn't matter for 3.4.1, I don't think stabs gets much use any more. Indeed, I believe gcc switched to Dwarf by default when 3.0.0 was released, which was about 7 1/2 years ago. J |
From: Nicholas N. <n.n...@gm...> - 2009-01-31 20:53:33
|
On Sun, Feb 1, 2009 at 1:35 AM, Julian Seward <js...@ac...> wrote: > >> Darwin port because DWARF is such a pain on Darwin. But it probably >> doesn't matter for 3.4.1, I don't think stabs gets much use any more. > > Indeed, I believe gcc switched to Dwarf by default when 3.0.0 was released, > which was about 7 1/2 years ago. And yet it doesn't seem to be possible to include Dwarf debug info in a .a file on Mac. Sigh. N |
From: Nicholas N. <n.n...@gm...> - 2009-02-05 06:41:55
|
On Sun, Feb 1, 2009 at 7:53 AM, Nicholas Nethercote <n.n...@gm...> wrote: > > And yet it doesn't seem to be possible to include Dwarf debug info in > a .a file on Mac. Sigh. Ah... it turns out that 'dwarfdump', the program that shows you debug info in a compiled file, cannot handle .a files. However, Dwarf debug info can be present in .a files and is propagated by the compiler into executables. Which means that building the libreplacemalloc.a library is ok. Nick |
From: Nicholas N. <n.n...@gm...> - 2009-02-03 00:23:35
|
On Sat, Jan 31, 2009 at 9:09 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Wed, Jan 28, 2009 at 10:14 PM, Julian Seward <js...@ac...> wrote: >> >> If there are any other high priority bug fixes that should go in >> 3.4.1, please let me know, preferably with trunk rev numbers. But >> please no build system changes. > > On Monday I might have a fix for some borked line number reading in > the stabs reader, believe it or not -- I was looking into it for the > Darwin port because DWARF is such a pain on Darwin. But it probably > doesn't matter for 3.4.1, I don't think stabs gets much use any more. Or not. Turns out that GCC's stabs generation on Darwin is totally borked, or, at least, follows a different convention to that used on Linux. Consider this program: ---- #include <stdio.h> int f(void) { int x; printf("f1\n"); printf("f2\n"); printf("f3\n"); printf("f4\n"); printf("f5\n"); printf("f6\n"); if (x) printf("f7a\n"); else printf("f7b\n"); return 0; } int main(void) { printf("1\n"); printf("2\n"); printf("3\n"); printf("4\n"); printf("5\n"); printf("6\n"); return f(); } ---- Here's the x86-linux stabs. N_SO indicates a new file, N_FUN indicates a new function, N_SLINE indicates a new line. N_SO(L): string=a.c, n_value(addr)=0x80483c4 N_FUN: string=f:F(0,1), n_desc(linenum)=0, n_value(addr)=0x80483c4 N_SLINE: n_value(addr)=0x0, n_desc(line_num)=4 N_SLINE: n_value(addr)=0x6, n_desc(line_num)=6 N_SLINE: n_value(addr)=0x12, n_desc(line_num)=7 N_SLINE: n_value(addr)=0x1e, n_desc(line_num)=8 N_SLINE: n_value(addr)=0x2a, n_desc(line_num)=9 N_SLINE: n_value(addr)=0x36, n_desc(line_num)=10 N_SLINE: n_value(addr)=0x42, n_desc(line_num)=11 N_SLINE: n_value(addr)=0x4e, n_desc(line_num)=12 N_SLINE: n_value(addr)=0x54, n_desc(line_num)=13 N_SLINE: n_value(addr)=0x62, n_desc(line_num)=15 N_SLINE: n_value(addr)=0x6e, n_desc(line_num)=16 N_SLINE: n_value(addr)=0x73, n_desc(line_num)=17 N_FUN: string=main:F(0,1), n_desc(linenum)=0, n_value(addr)=0x8048439 N_SLINE: n_value(addr)=0x0, n_desc(line_num)=20 N_SLINE: n_value(addr)=0x11, n_desc(line_num)=21 N_SLINE: n_value(addr)=0x1d, n_desc(line_num)=22 N_SLINE: n_value(addr)=0x29, n_desc(line_num)=23 N_SLINE: n_value(addr)=0x35, n_desc(line_num)=24 N_SLINE: n_value(addr)=0x41, n_desc(line_num)=25 N_SLINE: n_value(addr)=0x4d, n_desc(line_num)=26 N_SLINE: n_value(addr)=0x59, n_desc(line_num)=27 N_SLINE: n_value(addr)=0x5e, n_desc(line_num)=28 N_SO(L): string=, n_value(addr)=0x80484a0 Here's the x86-darwin stabs. Note that (a) the N_FUN comes at the *end* of the function, not the start, and (b) some of the N_SLINE addresses are relative, but some are absolute (furthermore, in bigger examples I can't see any consistent logic underlying the choice of relative vs. absolute): --5677-- Looking for debug info in ./a.out ... --5677-- Reading nlist symbols and STABS debuginfo for ./a.out (0x1000) (8 160) N_SO(L): string=a.c, n_value(addr)=0x1ede N_SLINE: n_value(addr)=0x0, n_desc(line_num)=4 N_SLINE: n_value(addr)=0xd, n_desc(line_num)=6 N_SLINE: n_value(addr)=0x1b, n_desc(line_num)=7 N_SLINE: n_value(addr)=0x29, n_desc(line_num)=8 N_SLINE: n_value(addr)=0x37, n_desc(line_num)=9 N_SLINE: n_value(addr)=0x45, n_desc(line_num)=10 N_SLINE: n_value(addr)=0x53, n_desc(line_num)=11 N_SLINE: n_value(addr)=0x61, n_desc(line_num)=12 N_SLINE: n_value(addr)=0x67, n_desc(line_num)=13 N_SLINE: n_value(addr)=0x77, n_desc(line_num)=15 N_SLINE: n_value(addr)=0x85, n_desc(line_num)=16 N_SLINE: n_value(addr)=0x8a, n_desc(line_num)=17 N_FUN: string=f:F(0,1), n_desc(linenum)=0, n_value(addr)=0x1ede N_SLINE: n_value(addr)=0x1f6e, n_desc(line_num)=20 N_SLINE: n_value(addr)=0x1f7b, n_desc(line_num)=21 N_SLINE: n_value(addr)=0x1f89, n_desc(line_num)=22 N_SLINE: n_value(addr)=0x1f97, n_desc(line_num)=23 N_SLINE: n_value(addr)=0x1fa5, n_desc(line_num)=24 N_SLINE: n_value(addr)=0x1fb3, n_desc(line_num)=25 N_SLINE: n_value(addr)=0x1fc1, n_desc(line_num)=26 N_SLINE: n_value(addr)=0x1fcf, n_desc(line_num)=27 N_SLINE: n_value(addr)=0x1fd4, n_desc(line_num)=28 N_FUN: string=main:F(0,1), n_desc(linenum)=0, n_value(addr)=0x1f6e N_SO(L): string=, n_value(addr)=0x1fda Argh. No wonder -gstabs wasn't helping on Darwin. (It turns out there's a -gfull option which adds some extra stab entries and almost makes it work, but N_FUNs are still at the function ends.) Looks like I won't have a fix to check in after all, because it's not the stabs reader that is broken. N |
From: Julian S. <js...@ac...> - 2009-02-03 08:52:50
|
> Here's the x86-darwin stabs. Note that (a) the N_FUN comes at the *end* of > the function, not the start, and (b) some of the N_SLINE addresses are > relative, but some are absolute (furthermore, in bigger examples I can't > see any consistent > logic underlying the choice of relative vs. absolute): When you say "relative vs absolute" do you mean "svma vs avma", a la comment at top of debuginfo.c ? That's strange. So the difference between 0x0 (lowest svma for f) and 0x1f6e (lowest svma for main) is not reflected in the output of nm or objdump (or equivalent) on Darwin? What does the "nm" output for the executable look like? I'm sure the above q is poorly phrased. What I mean is, you are implying that different bias values need to be added to the svmas of f and main in order to get the correct avmas. Which is something I don't think I've ever seen for functions that come from the same source file. > Looks like I won't have a fix to check in after all, because it's not > the stabs reader that is > broken. Is the native Darwin GDB or whatever, able to navigate correctly around this file, at the source line level, based on only the stabs info? J |
From: Nicholas N. <n.n...@gm...> - 2009-02-03 22:46:44
|
On Tue, Feb 3, 2009 at 7:53 PM, Julian Seward <js...@ac...> wrote: > > When you say "relative vs absolute" do you mean "svma vs avma", a la > comment at top of debuginfo.c ? Not quite. By "relative" I mean "offset from the start address of the function". By "absolute"... well the given address matches where it is loaded. And Darwin seems to reserve the first page so nothing can go below 0x1000. So it seems to really be "absolute", ie. the stated address matches where it is loaded. > That's strange. So the difference between 0x0 (lowest svma for f) and > 0x1f6e (lowest svma for main) is not reflected in the output of > nm or objdump (or equivalent) on Darwin? What does the "nm" output > for the executable look like? The relevant part: 00000000 - 00 0000 OSO 00000000 - 00 0000 EINCL 00000000 - 00 0000 EINCL 00000000 - 00 0000 EINCL 00001fda - 01 0000 SO 00001fd4 - 01 001c SLINE 00001fcf - 01 001b SLINE 00001fc1 - 01 001a SLINE 00001fb3 - 01 0019 SLINE 00001fa5 - 01 0018 SLINE 00001f97 - 01 0017 SLINE 00001f89 - 01 0016 SLINE 00001f7b - 01 0015 SLINE 00001f6e - 01 0014 SLINE 00001f6e - 01 0000 RBRAC 00001ede - 01 0000 LBRAC 0000008a - 01 0011 SLINE 00000085 - 01 0010 SLINE 00000077 - 01 000f SLINE 00000067 - 01 000d SLINE 00000061 - 01 000c SLINE 00000053 - 01 000b SLINE 00000045 - 01 000a SLINE 00000037 - 01 0009 SLINE 00000029 - 01 0008 SLINE 0000001b - 01 0007 SLINE 0000000d - 01 0006 SLINE 00000000 - 01 0004 SLINE Much the same info as Valgrind's debugging output showed. > I'm sure the above q is poorly phrased. What I mean is, you are > implying that different bias values need to be added to the svmas > of f and main in order to get the correct avmas. Which is something > I don't think I've ever seen for functions that come from the same > source file. Something like that. I think it's so broken and inconsistent that there's not much point trying to accurately describe what it does. > Is the native Darwin GDB or whatever, able to navigate correctly around > this file, at the source line level, based on only the stabs info? Actually, no! Here's a GDB session. Basically, I tried to single step through the whole thing. I could do so in main(), but GDB executed all of f() in a single step: (gdb) break main Breakpoint 1 at 0x1f7b: file a.c, line 21. (gdb) run Starting program: /Users/njn/grind/ws5/a.out Reading symbols for shared libraries ++. done Breakpoint 1, main () at a.c:21 21 printf("1\n"); (gdb) n 1 22 printf("2\n"); (gdb) n 2 23 printf("3\n"); (gdb) n 3 24 printf("4\n"); (gdb) n 4 25 printf("5\n"); (gdb) n 5 26 printf("6\n"); (gdb) n 6 27 return f(); (gdb) s 0x00001ee2 in f () at a.c:17 17 } (gdb) n [I subsequently tried 's' here, got the same result] f1 f2 f3 f4 f5 f6 f7a main () at a.c:28 28 } (gdb) n 0x00001eb2 in start () (gdb) n Single stepping until exit from function start, which has no line number information. 0x00003000 in dyld_stub_exit () I think the conclusion is that stabs is broken on Darwin and I will give up trying to use it. So I'm back to trying to work out how to get Dwarf info into a .a file. Or, how to build libreplacemalloc_toolpreload_* as something other than a .a file. Nick |
From: Greg P. <gp...@ap...> - 2009-02-03 23:04:54
|
On Feb 3, 2009, at 2:46 PM, Nicholas Nethercote wrote: > I think the conclusion is that stabs is broken on Darwin and I will > give up trying to use it. stabs ought to work fine. It was until recently the only available debugging format, and is still supported. Can you package your "can't step in gdb" into a self-contained example? -- Greg Parker gp...@ap... Runtime Wrangler |
From: Nicholas N. <n.n...@gm...> - 2009-02-03 23:59:35
Attachments:
a.c
|
On Wed, Feb 4, 2009 at 10:04 AM, Greg Parker <gp...@ap...> wrote: > On Feb 3, 2009, at 2:46 PM, Nicholas Nethercote wrote: >> >> I think the conclusion is that stabs is broken on Darwin and I will >> give up trying to use it. > > stabs ought to work fine. It was until recently the only available debugging > format, and is still supported. Can you package your "can't step in gdb" > into a self-contained example? Compile the attached file: gcc -gstabs a.c Run gdb like I did in my previous email -- just try to single step through, it works in 'main' but not in 'f'. And the 'nm -a' output from the previous email shows the screwy addresses. Also, reading "Mac OS X Internals" it appears that putting the the N_FUN stabs entry at the end of a function (along with N_LSYM and N_PSYM entries) is expected on Darwin. This is unfortunately different to Linux where it's put at the start of a function. Maybe Valgrind's stabs reader could be taught this, but the address problems would have to be resolved first. N |
From: Greg P. <gp...@ap...> - 2009-02-04 01:56:44
|
On Feb 3, 2009, at 3:59 PM, Nicholas Nethercote wrote: > On Wed, Feb 4, 2009 at 10:04 AM, Greg Parker <gp...@ap...> > wrote: >> On Feb 3, 2009, at 2:46 PM, Nicholas Nethercote wrote: >>> >>> I think the conclusion is that stabs is broken on Darwin and I will >>> give up trying to use it. >> >> stabs ought to work fine. It was until recently the only available >> debugging >> format, and is still supported. Can you package your "can't step in >> gdb" >> into a self-contained example? > > Compile the attached file: > > gcc -gstabs a.c > > Run gdb like I did in my previous email -- just try to single step > through, it works in 'main' but not in 'f'. You're right. Looks like -gstabs doesn't work, but -gstabs+ does. How does Valgrind fare with -gstabs+ ? > And the 'nm -a' output from the previous email shows the screwy > addresses. > > Also, reading "Mac OS X Internals" it appears that putting the the > N_FUN stabs entry at the end of a function (along with N_LSYM and > N_PSYM entries) is expected on Darwin. This is unfortunately > different to Linux where it's put at the start of a function. Maybe > Valgrind's stabs reader could be taught this, but the address problems > would have to be resolved first. I don't remember having any trouble with debug info back before I turned dwarf on. But it's possible that the only info I saw came from the ordinary symbols, not stabs. -- Greg Parker gp...@ap... Runtime Wrangler |
From: Nicholas N. <n.n...@gm...> - 2009-02-04 02:25:52
|
On Wed, Feb 4, 2009 at 12:56 PM, Greg Parker <gp...@ap...> wrote: > > You're right. Looks like -gstabs doesn't work, but -gstabs+ does. How does > Valgrind fare with -gstabs+ ? It doesn't work. -gstabs+ seems to be the same as -gstabs -gfull, which I tried previously. The differences with linux are: - N_FUN symbols are at the end of functions, not the start - N_SLINE addresses are relative to the start address of the enclosing function So the stabs reader would have to be partly split in two. But stabs is old and people don't use it much any more. And Apple doesn't seem to have qualms about dropping support for old features. So I'm a bit reluctant to bet the farm on stabs, even though (if the reader was modified) it is more convenient than .dSYM Dwarf. Nick |
From: Greg P. <gp...@ap...> - 2009-02-04 21:23:57
|
On Feb 3, 2009, at 6:25 PM, Nicholas Nethercote wrote: > On Wed, Feb 4, 2009 at 12:56 PM, Greg Parker <gp...@ap...> > wrote: >> >> You're right. Looks like -gstabs doesn't work, but -gstabs+ does. >> How does >> Valgrind fare with -gstabs+ ? > > It doesn't work. -gstabs+ seems to be the same as -gstabs -gfull, > which I tried previously. > The differences with linux are: > - N_FUN symbols are at the end of functions, not the start > - N_SLINE addresses are relative to the start address of the > enclosing function > > So the stabs reader would have to be partly split in two. > > But stabs is old and people don't use it much any more. And Apple > doesn't seem to have qualms about dropping support for old features. > So I'm a bit reluctant to bet the farm on stabs, even though (if the > reader was modified) it is more convenient than .dSYM Dwarf. If you only get to use one, use dwarf. I wouldn't be surprised if stabs were eventually dropped from the rest of Apple's toolchain. (For example, I don't know if LLVM-based compilers can or ever will produce stabs.) -- Greg Parker gp...@ap... Runtime Wrangler |
From: Julian S. <js...@ac...> - 2009-02-04 17:30:56
|
> I don't remember having any trouble with debug info back before I > turned dwarf on. But it's possible that the only info I saw came from > the ordinary symbols, not stabs. Indeedy. I would have thought that MachO (hence its reader) produced the symbol addresses, and Stabs produced info on line numbers (and types, etc). Same kind of work-split as with ELF+Stabs or ELF+Dwarf. Speaking of which, how does stack unwinding on 64-bit Darwin work? Is it the same as for 32-bit -- that is, just follow the chain of blocks %rbp, *%rbp, **%rbp, etc? Or does it use the same complicated, ugly and fragile Dwarf-based scheme as on Linux? J |
From: Greg P. <gp...@ap...> - 2009-02-04 21:20:32
|
On Feb 4, 2009, at 9:31 AM, Julian Seward wrote: >> I don't remember having any trouble with debug info back before I >> turned dwarf on. But it's possible that the only info I saw came from >> the ordinary symbols, not stabs. > > Indeedy. I would have thought that MachO (hence its reader) produced > the symbol addresses, and Stabs produced info on line numbers > (and types, etc). Same kind of work-split as with ELF+Stabs or > ELF+Dwarf. > > Speaking of which, how does stack unwinding on 64-bit Darwin work? > Is it the same as for 32-bit -- that is, just follow the chain of > blocks %rbp, *%rbp, **%rbp, etc? Or does it use the same complicated, > ugly and fragile Dwarf-based scheme as on Linux? %rbp-based unwinding works most of the time; currently we have little code that uses -fomit-frame-pointer. DWARF-based eh_frame unwind info is present almost everywhere, but that info isn't correct at every instruction, so valgrind can't depend on it. DWARF dSYMs (when present) might provide more precise unwind info than eh_frame, and handle -fomit-frame-pointer correctly. (I'd expect Darwin's x86_64 ABI to be almost exactly the same as Linux; it's the SysV spec with a handful of small differences.) -- Greg Parker gp...@ap... Runtime Wrangler |
From: Greg P. <gp...@ap...> - 2009-02-04 21:27:54
|
On Feb 4, 2009, at 9:31 AM, Julian Seward wrote: >> I don't remember having any trouble with debug info back before I >> turned dwarf on. But it's possible that the only info I saw came from >> the ordinary symbols, not stabs. > > Indeedy. I would have thought that MachO (hence its reader) produced > the symbol addresses, and Stabs produced info on line numbers > (and types, etc). Same kind of work-split as with ELF+Stabs or > ELF+Dwarf. I'm 99% sure that I was getting line numbers out of valgrind before dwarf, though. (There was one bug where I had the line numbers but not the symbol names, which looks awfully strange in a backtrace.) Perhaps the valgrind-confusing stabs data ended up presenting good line numbers but nothing else. Alternatively, it may have broken unnoticed at some later point. -- Greg Parker gp...@ap... Runtime Wrangler |
From: Nicholas N. <n.n...@gm...> - 2009-02-04 22:54:04
|
On Thu, Feb 5, 2009 at 8:27 AM, Greg Parker <gp...@ap...> wrote: > On Feb 4, 2009, at 9:31 AM, Julian Seward wrote: >>> >>> I don't remember having any trouble with debug info back before I >>> turned dwarf on. But it's possible that the only info I saw came from >>> the ordinary symbols, not stabs. >> >> Indeedy. I would have thought that MachO (hence its reader) produced >> the symbol addresses, and Stabs produced info on line numbers >> (and types, etc). Same kind of work-split as with ELF+Stabs or >> ELF+Dwarf. > > I'm 99% sure that I was getting line numbers out of valgrind before dwarf, > though. (There was one bug where I had the line numbers but not the symbol > names, which looks awfully strange in a backtrace.) Perhaps the > valgrind-confusing stabs data ended up presenting good line numbers but > nothing else. Alternatively, it may have broken unnoticed at some later > point. I did get some correct line numbers out of it for at least one example. It was a total fluke, though, basically Valgrind was doing the wrong (for Darwin) calculations of addresses but it happened to work out to the right answer because the inputs were incorrect in just the right (wrong?) ways. The good news is that I've worked out how to run dsymutil for the regtests within the build system, and I'm close to a solution for vg_replace_malloc.c -- by avoiding building it as an archive. Nick |