Re: bug in implementation of __throw in gcc?

[Mike Stump <mrs at windriver dot com>]

> From: David Edelsohn <dje@watson.ibm.com>
> Date: Tue, 12 Dec 2000 14:02:26 -0500

> The libgcc2.c _throw code is:

>   /* Now reset pc to the right throw point.  */
>   pc = __builtin_extract_return_addr (__builtin_return_address (0)) - 1;

>   handler = throw_helper (eh, pc, my_udata, &offset);

> If I disassemble this code under ppc linux, it shows pc getting
> decremented by 1 (not by 4) which makes pc on entry to throw_helper
> not point to the address of the __throw but instead to 3 bytes after
> it.

Ok.

> Is this a bug?

No.

> Why use the "-1" here and not -4 (bytes) so that the actual address
> of the __throw is in pc as the comments in libgcc2.c indicate they
> should for entry to throw_helper.

-1 must be strictly more correct than -4.  On a machine with 1, 2 or 3
byte instructions, -4 would be too big.  On no machine, would -1 be
too big, where -4 works.

> Is this just a mistake in pointer arithmetic?

Nope.

> If a mistake, does this even matter when it comes to finding the
> right handler to catch the exception (I am worried about the end
> conditions tested for in the find_fde code).

__builtin_extract_return_addr (__builtin_return_address (0))-1 is
constrained to point to _some part_ of the call instruction.  It
practice, on most pachines, it points to the last byte of the call
instruction.  It doesn't help, if it points to the first byte of the
call instruction.  That is usually harder.  SPARC is the oddball here.

I'd be happy to answer any other questions you have.  If you feel I
say something that isn't clear in the documentation, I'd love it if
you refined it.