This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PowerPC shrink-wrap support 0 of 3
- From: Bernd Schmidt <bernds at codesourcery dot com>
- To: Peter Bergner <bergner at vnet dot ibm dot com>, gcc at gcc dot gnu dot org, amodra at gmail dot com
- Date: Thu, 22 Sep 2011 16:47:00 +0200
- Subject: Re: PowerPC shrink-wrap support 0 of 3
- References: <20110917071643.GT10321@bubble.grove.modra.org> <4E749FFD.8030507@codesourcery.com> <20110919001656.GZ10321@bubble.grove.modra.org> <4E77319B.4030809@codesourcery.com> <20110921152851.GE10321@bubble.grove.modra.org> <20110922144017.GF10321@bubble.grove.modra.org>
On 09/22/11 16:40, Alan Modra wrote:
> The bootstrap breakage happens on libmudflap/mf-hooks1.c, compiling
> __wrap_malloc. Eliding some detail, this function starts off as
>
> void *__wrap_malloc (size_t c)
> {
> if (__mf_starting_p)
> return __real_malloc (c);
>
> The "if" is bb2, the sibling call bb3, and shrink wrap rather nicely
> puts the prologue for the rest of the function in bb4. A great
> example of shrink wrap doing as it should, if you ignore the fact that
> optimizing for startup isn't so clever. However, bb-reorder inverts
> the "if" and moves the sibling call past other blocks in the function.
> That's wrong, because the dwarf unwind info for the prologue is not
> applicable for the sibling call block: The prologue hasn't been
> executed for that block. (The unwinder sequentially executes all
> unwind opcodes from the start of the function to find the unwind state
> at any instruction address.) Exactly the same sort of problem is
> generated by your "unconverted_simple_returns" code.
dwarf2cfi should be able to figure this out. I'd need to see RTL dumps
to get an idea what's going on.
Bernd