Re: SH breakpoint problem

[Jonathan Larmour <jlarmour at redhat dot com>]

Kevin Buettner wrote:
> 
> On Aug 9,  8:48pm, Jonathan Larmour wrote:
> > 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.)

This would be defined for the whole SH architecture then. What
ramifications would it have? i.e. what would/could break?

It does seem a bit odd that after going to lengths to analyze the prologue
etc. to determine the right address, it goes and basically ignores that in
favour of the debug info. Why did it bother since it already knew the
address of the start of the function?

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

I'm surprised a function like this only needs using in such a small number
of places, rather than whereever BREAKPOINT_FROM_PC is used. I suppose I
can't really see the difference between them :-|.

Also, I can't help but think people might be annoyed that "b *0x12345678"
may not actually set a bp at exactly that address. As for hardware
breakpoints, I don't know either what would be different.

Anyway, I can't see how that approach wouldn't be required for mips, but
whatever. I was just rather expecting that this type of issue (end of
source line is a delay slot) must have been solved somewhere already.
Surely on some archs the end of the line containing a call to a function
_must_ be a delay slot. Or did the debug info (IMHO if so, erroneously) not
used to include the delay slot as being a part of that line?

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

But on the target, we have to know what traps are assigned to breakpoints,
and what are free for other uses (genuine traps). Is there a right answer,
or should we just pick one?

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