frameless_look_for_prologue

[David Taylor <taylor@cygnus.com>]

I believe that every target that does:

  set_gdbarch_frameless_function_invocation (gdbarch, 
					     frameless_look_for_prologue);

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
currently stopped".

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
	to frameless_look_for_prologue.

. 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.

Comments?