This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: SH breakpoint problem
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