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

[Michael Snyder <msnyder at redhat dot com>]

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