Fri Mar 9 06:50:00 GMT 2001
I believe that every target that does:
has a bug.
The function frameless_look_for_prologue invokes PROLOGUE_FRAMELESS_P
with one argument -- the pc of the *START* of the function.
For backtraces, get_prev_frame wants to know not "does this function
eventually set up a frame if I execute far enough into it", but rather
"does this function have a frame at the point where the program has
If the function has to execute some instructions to set up the frame
(and if it doesn't, why are you setting FRAMELESS_FUNCTION_INVOCATION
to frameless_look_for_prologue?), then those questions potentially
have different answers.
Potential solutions include:
. change the interface of PROLOGUE_FRAMELESS_P --
==> invoke it with the current pc, not the start pc
have it call get_pc_function_start
Pro: no namespace pollution; don't need to create yet
another macro / multi-arch function
Con: need to change the PROLOGUE_FRAMELESS_P functions for all
of the targets that currently set FRAMELESS_FUNCTION_INVOCATION
. create a new variant of PROLOGUE_FRAMELESS_P
==> either the new variant takes one argument (the current or
'limit' pc) and calls get_pc_function_start or it takes two
arguments (the start pc and the current/limit pc).
Pro: don't need to change existing targets
Con: creates yet another multi-arch macro / function; doesn't fix
a known bug in several existing targets.
My personal preference would be --
. a new variant of PROLOGUE_FRAMELESS_P which takes two arguments
. put a comment next to the old method saying that it is deprecated
and why and suggesting that people use the new method instead
. 'encourage' maintainers to fix existing targets
If people agree, I'll try to find the time in the next few days to put
together a patch.
More information about the Gdb-patches