Re: SH breakpoint problem

[Jonathan Larmour <jlarmour at redhat dot com>]

Kevin Buettner wrote:
> 
> On Aug 8,  1:54am, Alexandre Oliva wrote:
> 
> > On Aug  7, 2001, Kevin Buettner <kevinb@cygnus.com> wrote:
> >
> > > My opinion is that gdb should use the information obtained from
> > > find_pc_line() only to refine the limit searched by the prologue
> > > scanner.  The prologue scanner needs to be taught that it must
> > > never scan past an instruction which modifies the flow of control
> > > (i.e, branch or call instructions).
> >
> > This would cause a yet-to-be-contributed port I worked on to stop the
> > search too early, because some peculiarities of the ABI require
> > function calls to be inserted in the prologue in certain
> > circumstances.
> 
> That sort of thing is okay so long as you teach the prologue analyzer
> about these special functions.

It depends if it can be distinguished from a branch that we do want to
ignore though.

I tried Kevin's suggestion anyway, and hit a problem in that even if I
return the correct address from sh_skip_prologue(), the code that calls it
in find_function_start_sal() in symtab.c "corrects" it due to the check:

2055	  /* Check if SKIP_PROLOGUE left us in mid-line, and the next
2056	     line is still part of the same function.  */

So even if we do correct it, it will still put it back :-|. Perhaps it
would be better (assuming it is allowed) to modify the PC in
sh_breakpoint_from_pc()?

One semi-related question: sh_breakpoint_from_pc() in sh-tdep.c says:

  /* 0xc3c3 is trapa #c3, and it works in big and little endian modes */
  static unsigned char breakpoint[] =  {0xc3, 0xc3};

whereas config/sh/tm-sh.h says:

#define BIG_REMOTE_BREAKPOINT    { 0xc3, 0x20 } /* Used in remote.c */
#define LITTLE_REMOTE_BREAKPOINT { 0x20, 0xc3 } /* Used in remote.c */

Which is right?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine