This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix PPC scan_prologue for code generated with -mno-update
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: fnf at specifix dot com
- Cc: gdb-patches at sources dot redhat dot com, fnf at specifix dot com
- Date: Fri, 16 Feb 2007 09:22:34 +0100 (CET)
- Subject: Re: [PATCH] Fix PPC scan_prologue for code generated with -mno-update
- References: <200702151807.06227.fnf@specifix.com>
> From: Fred Fish <fnf@specifix.com>
> Date: Thu, 15 Feb 2007 18:07:06 -0700
>
> If the PPC gcc is used with the -mno-update option, it generates a
> prologue instruction to allocate cache that gdb does not recognize.
> Gdb disassembles it as "addi r1,r1,NUM".
>
> If you run the gdb testsuite for powerpc-eabi and add -mno-update to
> the list of compilation options, you get a huge increase in failures,
> most due to problems doing backtraces. Without using -mno-update
> you get:
>
> # of expected passes 36024
> # of unexpected failures 756
>
> With -mno-update you get:
>
> # of expected passes 33220
> # of unexpected failures 3928
>
> After applying the attached patch, the results with -mno-update
> become:
>
> # of expected passes 36028
> # of unexpected failures 752
>
> This also fixes an existing failure (1 for each multilib):
>
> 4448c4446
> < FAIL: gdb.base/recurse.exp: next over b = 0 in second instance
> ---
> > PASS: gdb.base/recurse.exp: next over b = 0 in second instance
>
> I didn't examine why that failure was fixed by the patch.
Looks reasonable to me. However there's one thing I don't understand.
Presuming you're using DWARF2 debug info, why does improving the
prologue scanner make such a big difference?
Mark