This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] add 'rs6000_in_function_epilogue_p()'
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: jimb at red-bean dot com
- Cc: pgilliam at us dot ibm dot com, gdb-patches at sources dot redhat dot com
- Date: Fri, 2 Dec 2005 19:28:09 +0100 (CET)
- Subject: Re: [PATCH] add 'rs6000_in_function_epilogue_p()'
- References: <200511301225.56802.pgilliam@us.ibm.com> <8f2776cb0512011707p120df411w3a685c453d4ec625@mail.gmail.com>
> Date: Thu, 1 Dec 2005 17:07:24 -0800
> From: Jim Blandy <jimb@red-bean.com>
>
> Whatever we do immediately, the underlying cause here is that
> unwinding isn't working at every instruction. If it were, then the
> call to frame_find_by_id would find the frame containing the watched
> variable, and watchpoint_check would correctly conclude that the
> variable was still in scope.
>
> Paul, does your test program have Dwarf CFI for the functions in question?
Unfortunately, GCC's CFI is not complete. At one point GCC did
generate CFI for epilogues, but that really screwed up cases like:
main:
prologue
jump to body
epilogue:
epilogue
body:
...
...
jump to epilogue
whis GCC was generating quite a lot. So generating CFI for epilogues
was disabled.
I vaguely remember that Richard Henderson said that generating correct
CFI for the above case would be possible with tree SSA. But I don't
think this has ahppened yet.
Actually I think the fact that CFI works at all is mostly because it
is also used for exception handling. Obviously, generating correct
CFI for the epilogue isn't terribly important for exception handling,
since there is no code that can throw exceptions in the epilogue
(although it becomes somewhat important if you allow for asynchronous
exceptions). It'd be great if we could get some of the GCC hackers a
bit more interested in gdb.
Mark