------- Additional Comments From opensource at artnaseef dot com 2004-12-13 15:55 ------- Subject: Re: Profiling optimized code causes segfaults on ARM due to missing frames
Alright, since my instructions are not good enough for you, I will put together an example. rearnsha at gcc dot gnu dot org wrote: >------- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-13 >15:43 ------- >Subject: Re: Profiling optimized code causes segfaults > on ARM due to missing frames > >On Mon, 2004-12-13 at 15:28, opensource at artnaseef dot com wrote: > >>------- Additional Comments From opensource at artnaseef dot com 2004-12-13 >>15:28 ------- >>Subject: Re: Profiling optimized code causes segfaults on >> ARM due to missing frames >> >>Two things >> >> 1. Why do you not think the patch is correct? It works great for >>me. Without >> that information, I can only respond with "I think you are wrong," >>and that >> is not productive. >> >> >Because I don't think profiling should need the a frame pointer to >work. If it does, then my feeling is that it's the profiling code >that's broken, not the compiler. The layout of a stack frame is private >to the function that built it, and any code outside of that function >that tries to probe it is simply broken. > > >> 2. The comment in the patch you show is that the Profiler clobbers the >>Link >> Register. That is NOT this problem. >> >> > >Well, that patch was never applied to the 3.3 branch. The bug it refers >to was reported against 3.0, so there's a strong likelihood that it will >be needed in 3.3 as well. > > >>In this problem, the profiler causes a segmentation fault when it reads >>the wrong >>return address off the stack and uses it as an invalid function >>address. It does >>not use the link register value. >> >>To reproduce the problem: >> >> - Build an arm-linux toolchain >> >> - Compile a program with optimization and profiling (try -O2 and -pg). >> >> - Make sure the program includes a function for which the optimizer >> drops its frame pointer (this can easily be verified by looking at >> the assembly output of the compiler). >> >> - Run the program. >> >>If a trace is needed, I will be able to produce one within a few days >>and provide an example. Note that this problem was quite easy for me >>to reproduce, so I would expect reproducing it to be simple enough for >>others. >> > >I'm not in the business of trying to second guess how you encountered a >problem. If you want us to investigate a bug then you need to send us >precise instructions (including source code) so that we can reproduce >it. > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18929
