Re: SH breakpoint problem

[Kevin Buettner <kevinb at cygnus dot com>]

On Aug 9,  8:48pm, Jonathan Larmour wrote:

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

You might try defining PROLOGUE_FIRSTLINE_OVERLAP for your port.  (This
might cause other things to break though.)

> Perhaps it would be better (assuming it is allowed) to modify the PC
> in sh_breakpoint_from_pc()?

It is allowed, but is generally used for such things as clearing
bits which might make the address odd (see mips).

I don't recall the details, but changing the address in
*_breakpoint_from_pc() didn't work when I had a (sort of) similar
problem about a year ago.  I ended up submitting the following patch
which may be used for adjusting the breakpoint address:

    http://sources.redhat.com/ml/gdb-patches/2000-06/msg00257.html

Unfortunately, this patch needs a bit of work before it can go in.
(See Eli Zaretskii's comments.)

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

Maybe both of them?

They're both trapa instructions.  The sh_breakpoint_from_pc() version
is ``trapa #c3'' and the {BIG,LITTLE}_REMOTE_BREAKPOINT version is
``trapa #20''.

Kevin