Re: assignment forms

[Daniel Berlin <dan at www dot cgsoftware dot com>]

On Mon, 2 Apr 2001, Mark Byler wrote:

>
>
> Michael Snyder wrote:
> >
> > Mark Byler wrote:
> > >
> > > Hello,
> > >
> > > I am looking into contributing to gdb sources.  Your
> > > "Contributing to GDB" page talks about some documents like
> > > http://gcc.gnu.org/fsf-forms/assignment-instructions.html,
> > > but this page does not exist.
> > >
> > > Is the copyright assignment really the first step?  Should
> > > I talk to somebody about the kind of changes I want to
> > > contribute?
> >
> > The copyright assignment is an essential step, but not necessarily
> > the first.  Jim Blandy (jimb@redhat.com) is your contact for the
> > copyright forms.  If you'd like to discuss the changes you're
> > contemplating and look for feedback, this is an appropriate forum.
> > What did you have in mind?
> >
> > Michael
>
> I work with Kuck & Associates (KAI C++ compiler people)
> who recently were bought by Intel.  KAI would like to make gdb
> the principal debugger for use with KAI C++, dropping an
> in-house debugger.
>
> KAI C++ uses an EDG front end.  The changes we need are related
> to EDG style of compilation, which probably has broader application
> than just KAI C++.  Specifically, we need
> 	- local variable demangling is slightly different, this
> 		is about a 20-line change in libiberty/cplus-dem.c
	Make sure it can be autodetected, like the other styles.

> 	- C++ baseclasses are represented differently, especially
> 		virtual baseclasses.
Look at the C++ ABI abstraction stuff, and implement your ABI based on it.
It shouldn't be that difficult at all.

If your ABI will be the same as the G++ new-abi, then your problem is
solved to begin with. However, since you mentioned cplus-dem, i assume you
are at least using EDG's mangling, and likely some other ABI.

> 	- Digital alpha (aka axp/osf, tru64) does not know anything
> 		about baseclasses at all, as far as I can tell
Correct. Well, depends on how you look at it. The info is now there in
newer versions of Tru64, but it would take some work to use it.
> 	- might be some changes related to finding methods for classes
There shouldn't be.
Unless you are fixing some of the bugs that exist.
However, things like virtual function finding and wahtnot have been
abstracted, since it's abi dependent.
>
> This is not a complete list, but this is the sort of thing
> we are looking at.  We would like to plow these changes back into
> the general source of gdb.

Please don't use the word "plow". We get scared.
>  On some platforms we might be interested
> in fixing some bugs.  We might help get some ports done (I have a
> question out about 64-bit sparc).
>
> What do you think?  Is this worth pursuing?

Of course.

But before you start adding code to implement your C++ ABI to GDB, you
need to look at the abstraction stuff, which will be in RSN .
  Things like rtti,  virtual function calling, baseclass offset finding,
etc, are now completely abstracted away. So if you have added code to do
this stuff directly to those functions, or anywher eelse, it'll need to be
moved into a new file (kcc-abi.c i would guess, unless you change the C++
abi based on the platform), and called through the abstracted functions.
This is pretty mechnical, however, except in the case of baseclass_offset,
where it requiers about 10 seconds of thought.

I'm also interested in your finding method differences, etc.
If you have GPL'd the code, I can look at it and tell you, what, if
anything, is/isn't acceptable, at least from my point of view (I"m the C++
maintainer).  For instance, i'm certainly not going to let anymore ABI
specific  workaround/hacks/etc into the generic code, if you have them.
Just to give you an example. I'm more than happy to work with you to
extend the C++ abi abstract so that encompasses other differences you may
need.
I'm also grateful for any general bug fixes to the C++ support.


 . >
> Mark. >