[Bug target/18929] Profiling optimized code causes segfaults on ARM due to missing frames
rearnsha at gcc dot gnu dot org
gcc-bugzilla@gcc.gnu.org
Mon Dec 13 15:43:00 GMT 2004
------- 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
More information about the Gcc-bugs
mailing list