Re: [linuxsh-dev] Re: Question : GBD Stub to boot a machine.

[Fabio G. <fg...@ti...>]

Thnaks a lot. I'll keep you informed about my progresses, if you like.

Regards.

On Thursday 18 July 2002 20:14, Jeremy Siegel wrote:
> Fabio Giovagnini wrote:
> > Hi, every body,
> > I'm woking on porting linux-sh on a my own sh-3 based board.
> > To debug the software regarding the machvect description, I boot my card
> > using sh-ilp+g and everything works good.
> > Now I'd like to put on the flash of another my development sh-2 based
> > card the gdbstub I found on sourceforge to achieve the following target:
> > 1) power up my card;
> > 2) load on ram my program;
> > 3) execute from ram my  program;
> > 4) debug it.
> >
> > Some doubts:
> > 1) How do I have to link my application program I like to debug using
> > gdbstub? 2) Is it possible to use gdbstub to debug a loaded program
> > (using (gdb) load /root/myrog command); or gdbstub has to be a part of my
> > application program? 3) Can I try to compile sh-ipl+g for may sh-7044
> > based card, or it has too much specific part sh-3 and sh-4 related?
>
> Here's my take on it:
>
> 1) I don't think it matters how you link it, as long as it knows where it
> wants to be in RAM.
> 2) You can load w/gdb as long as you're talking to an independent stub. 
> The stub and app have to agree on (a) serial port usage, and (b) exception
> handling; this is necessary whether the app and stub are linked together or
> not.
> 3) There's the rub: I've not used the SH2, but from what little I know it's
> very different than the SH3/4 in terms of exception handling and register
> set. Not only would you need to write the BSC init for your board (like any
> port) but you'd need to rewrite entry.S to deal with the fact that
> exception vectors are addresses rather than code blocks, there are no bank
> registers, etc; the stub itself my need to change the register handling if
> the stacked register set looks different (but that also depends heavily on
> what the gdb the stub is talking to expects).  Even the serial ports (if
> available) may be different, requiring work in sh-sci.c too...
>
> The upshot is that I don't think the SH3/4 version will "drop in" easily. 
> (But there might be an SH2 version floating around... in fact, I think if
> you look at the GDB package there might be some sample stubs there, and the
> SH one might be a good SH2 starting point for linking with your app?)
>
> Good luck,
>   --Jeremy Siegel
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev