From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: SH breakpoint problem Date: Thu, 09 Aug 2001 14:05:00 -0000 Message-id: <3B72FB2D.F62163BB@redhat.com> References: <3B6F5625.ADBD6F53@redhat.com> <1010807224211.ZM23418@ocotillo.lan> <1010808054531.ZM26428@ocotillo.lan> <3B72E91A.7FB86E08@redhat.com> <1010809202926.ZM12327@ocotillo.lan> X-SW-Source: 2001-08/msg00094.html 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