This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Submission of a new gdb port


Orjan Friberg wrote:
> 
> I am planning the submission of a new gdb port, and I would appreciate
> some guidance as to the best procedure to do this.
> 
> The port is for an embedded system. The current status of the code is
> that there are no deprecated macros, but I have not yet switched to the
> multi-arch framework. During development, I used the 2000-05-19-release
> source tree, but I just updated to the latest CVS sources.
> 
> * Will I be working with anyone in particular? Will the code be
> scrutinized in the same way patches are?

You'll need to work with a number of people (check the S390 posts). 
Some parts of a GDB release are part of GDB but some are not.  BFD, for
instance, is really part of binutils so changes to that go to the
binutils@sources.cygnus.com mailing list.  Top level changes are
discussed in src/MAINTAINERS.

In terms of process, I'd not follow IBM's lead with the s390 - they are
in a somewhat unusual situtation.  The 68hc11 is probably more typical
of what should happen - the basic thing was committed and then as second
and later passes various issues were resolved.

I'd be looking to breakdown your submittion in to smaller chunks and
then farming them out.  On GDB, once the basics such as file names have
been resolved, there can be a fairly large degree of flexability in now
things are integrated.

> * How stable is the multi-arch framework? Are there any catches
> switching to it? (Will multi-arching allow me to debug APIs that only
> differ in their respective sizes of a double?)

Definitly useable.  Many targets have basicly converted, and yes, it
lets you do things like change the size of a double (and a lot more
:-).  The MIPS target knows how to debug well over 30 different ISA/ABI
combinations....

> * Which currently supported target would be the best example for
> architectural issues? Already being multi-arched, I reckon that the d10v
> and the mn10300 are good candidates.

Yes.

> * Should I submit test results from the DejaGnu testsuite? Should I
> submit patches for XFAILs specific to my target?

People will be interested in testsuite results but, for the most part,
it is the responsibility of the target developer to keep track of such
things.

You should probably also note that an XFAIL doesn't mean ``I know this
doesn't work for my target''.  Rather it means something like
``technical issues outside of GDBs control make fixing this
impossible''.

> * The 4.18 port, on which the 5.0 port is heavily based, was developed
> by another person at my company (for which an assign.future has been
> submitted previously). How do I give proper credit to him?

If they authored the original files then probably mention them as part
of the copyright (along with your company and you :-).

> Thanks for bearing with me on this.

Not a problem,  sory to be so slow in responding.

	Andrew

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]