This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bug in implementation of __throw in gcc?
- To: "Kevin B. Hendricks" <kevin dot hendricks at sympatico dot ca>
- Subject: Re: bug in implementation of __throw in gcc?
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: 12 Dec 2000 11:56:44 -0800
- CC: gcc at gcc dot gnu dot org
- References: <00121214022600.01317@localhost>
Kevin B. Hendricks <kevin.hendricks@sympatico.ca> writes:
> 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.
>
> Is this a bug? 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.
This works. I don't know if it was intentional, but note that on many
other ports it has the same effect: `pc' points somewhere inside the
call instruction, not necessarily at its start.
I think the important thing is that `pc' doesn't point just after the
end of the call instruction, because that might be the boundary between
two EH regions.
--
- Geoffrey Keating <geoffk@geoffk.org>