|
From: Florian K. <br...@ac...> - 2012-05-21 19:48:47
|
While we're on the topic... There's one more place where fomit-frame-pointer is fiddled with: ./memcheck/Makefile.am:mc_main.o: CFLAGS += -fomit-frame-pointer ./memcheck/Makefile.am:mc_replace_strmem.o: CFLAGS += -fno-omit-frame-pointer These were added in r3540 and r1774, respectively. With no commentary that would shed some light as to why it appeared necessary. Removing those did not make a difference on amd64, ppc, and s390x. Any objections to removing those? Florian |
|
From: Julian S. <js...@ac...> - 2012-05-21 20:53:45
|
On Monday, May 21, 2012, Florian Krohm wrote: > While we're on the topic... > There's one more place where fomit-frame-pointer is fiddled with: > > ./memcheck/Makefile.am:mc_main.o: CFLAGS += -fomit-frame-pointer > ./memcheck/Makefile.am:mc_replace_strmem.o: CFLAGS += > -fno-omit-frame-pointer > > These were added in r3540 and r1774, respectively. With no commentary > that would shed some light as to why it appeared necessary. The rationale is: mc_main.c contains the expensive bit of Memcheck (the helper functions that get called millions of times per second). On x86 it's important to build this with -fomit-frame-pointer so as to maximise performance. mc_replace_strmem.c runs on the simulated CPU, and it often appears in stack traces shown to the user. It is built with -fno-omit-frame-pointer so as to guarantee robust backtraces on x86, on which CFI based unwinding is not the "normal" case and so is sometimes fragile. > Removing those did not make a difference on amd64, ppc, and s390x. > Any objections to removing those? I'd like to preserve these settings. IIUC, recent changes to Makefile.all.am (??) cause mc_main.c to be built -fomit-frame-pointer on all platforms anyway (is that correct? I didn't follow all the details of the discussion on it). So that can be rm'd. -fno-omit-frame-pointer for mc_replace_strmem.c, I'd like to preserve, for the reason above. Yell if my understanding of what happened recently with these changes is wrong .. it could well be. It's easier to make sense of this stuff when experimenting with x86, since that's the one platform on which -fomit-frame-pointer does make a sometimes dramatic difference (between stack traces and no stack traces). J |
|
From: Florian K. <br...@ac...> - 2012-05-21 21:08:50
|
On 05/21/2012 04:51 PM, Julian Seward wrote: > The rationale is: > > mc_main.c contains the expensive bit of Memcheck (the helper functions > that get called millions of times per second). On x86 it's important > to build this with -fomit-frame-pointer so as to maximise performance. > > mc_replace_strmem.c runs on the simulated CPU, and it often appears > in stack traces shown to the user. It is built with > -fno-omit-frame-pointer so as to guarantee robust backtraces on x86, > on which CFI based unwinding is not the "normal" case and so is > sometimes fragile. > >> Removing those did not make a difference on amd64, ppc, and s390x. >> Any objections to removing those? > > I'd like to preserve these settings. IIUC, recent changes to > Makefile.all.am (??) cause mc_main.c to be built -fomit-frame-pointer > on all platforms anyway (is that correct? No, only x86, amd64, and s390x have -fomit-frame-pointer universally enabled. When we discussed this on IRC, you weren't sure whether it was the right thing to do for ppc. Also, ARM does not have -fomit-frame-pointer enabled. > I didn't follow all the > details of the discussion on it). So that can be rm'd. Not quite, I guess. > > -fno-omit-frame-pointer for mc_replace_strmem.c, I'd like to > preserve, for the reason above. > Yeah makes sense. I presume you won't object if I add your explanation as a comment in the Makefile :) > It's easier to make sense of this stuff when experimenting with x86, > since that's the one platform on which -fomit-frame-pointer does make > a sometimes dramatic difference (between stack traces and no stack traces). I used to have access to an x86 but no more... Florian |
|
From: Philippe W. <phi...@sk...> - 2012-05-21 21:11:26
|
On Mon, 2012-05-21 at 17:08 -0400, Florian Krohm wrote: > I used to have access to an x86 but no more... If you have an intel 64 bits, then --enable-only32bit will compile only V in x86, and all the regtests will be run in this mode. Should be equivalent to testing natively on x86 I guess. Philippe |