Re: Porting GDB to a new target processor architecture -- what's involved?

Re: Porting GDB to a new target processor architecture -- what's involved?

[Salman Khilji]

I have recently worked on understanding the gdb code by stepping through 
modules.  I am not aware of any document other than GDB internals that 
explains the details, but if you start off by taking a paticular task and 
step thru the code, you should be able to understand it with relative ease.

I found the programming style and the # of comments to be simply wonderful 
and easy to understand!

Salman

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Porting GDB to a new target processor architecture -- what's involved?

[Stefan Heinzmann]

Hello,

a potential customer wants me to port GDB to a new processor architecture (a
32-bit RISC processor) used in embedded systems. As I'm unfamiliar with the
GDB internals, I have difficulties estimating the time needed to do this.
What do I need to know? Has anyone got a reading list?

The GCC (2.95.3) and binutils apparently have been ported already. To which
extent can I reuse code from those? I remember having read somewhere that
gas and gdb use common target definition files, is that true?

The GDB internals document is quite helpful, but it appears to be incomplete
(stack frame interpretation, compiler characteristics). Is there additional
information available (other than the source code itself)?

How does the development process work assuming that the new target is
contributed back to the community? Do I have to follow the most up-to-date
CVS tree closely or is it more useful to work "off-line"?

Is it reasonable to assume that the general gdb code can be used unchanged
and only a few target-specific files need to be provided, or is it common
that such a porting effort brings up issues with gdb in general (or even
with a graphical frontend) that will have to be addressed, too?

Thanks for your help

Cheers
Stefan

Re: Porting GDB to a new target processor architecture -- what's involved?

[Michael Snyder]

Stefan Heinzmann wrote:
> 
> Hello,
> 
> a potential customer wants me to port GDB to a new processor architecture (a
> 32-bit RISC processor) used in embedded systems. As I'm unfamiliar with the
> GDB internals, I have difficulties estimating the time needed to do this.
> What do I need to know? Has anyone got a reading list?

No reading list, sorry.  Maybe someday someone who is doing a 
first-time port will write up the experience.  You?

I usually start by adding a couple of lines to configure.tgt
to set up my new target (there are plenty of examples to look at).

Then I'll create a subdirectory under gdb/config for my target, 
and populate it with empty or minimal file fragments patterned 
after existing ones (best to pick a recent port as a template).

Finally you'll create a *-tdep.c file which will implement 
your target methods.  One way to start, again, is to begin
with a copy of another recent port's tdep file and strip out
all the code (bodies of the functions), rename the functions
to correspond to your target, and then start filling in the details.

I know I'm making this sound easier than it actually is...

> The GCC (2.95.3) and binutils apparently have been ported already. To which
> extent can I reuse code from those? I remember having read somewhere that
> gas and gdb use common target definition files, is that true?

Not really, but they share the bfd and opcodes libraries, which
will take care of (respectively) reading object files and disassembling.

> The GDB internals document is quite helpful, but it appears to be incomplete
> (stack frame interpretation, compiler characteristics). Is there additional
> information available (other than the source code itself)?

Yeah, it's always been incomplete, and no there isn't much else
(other than the source code, the changelogs, and the newsgroups.)

> How does the development process work assuming that the new target is
> contributed back to the community? Do I have to follow the most up-to-date
> CVS tree closely or is it more useful to work "off-line"?

Best to stay current.  Your eventual submission will have to be a
clean diff against the current tree.

> Is it reasonable to assume that the general gdb code can be used unchanged
> and only a few target-specific files need to be provided,

Yes.

> or is it common
> that such a porting effort brings up issues with gdb in general (or even
> with a graphical frontend) that will have to be addressed, too?

Not too common (knock on wood).  If it seems to you that you can't
do what you want to without changing the rest of gdb, you should
try looking at it from a different angle first.

Best of luck, 
Michael