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