Thread overview
GDB Hacking
Mar 26, 2005
John Demme
Mar 28, 2005
James Dunne
Re: GDB Hacking (Slightly OT)
Mar 28, 2005
John Demme
Mar 29, 2005
James Dunne
Mar 29, 2005
Brad Anderson
Mar 29, 2005
John Demme
Mar 31, 2005
John Demme
March 26, 2005
OK.. so I've spent the last week (spring break) working on adding D name demangling to GDB... and I'm still having trouble.  The name demangling routine seems to work fine (I ported James Dunne's) but I've been unable to get GDB to use it all the time, so only some D symbols get demangled.

Does anyone here have any experience hacking GDB?  I'll go to the GDB list next, but I was hoping that someone with an interest in D would be able to help.

Thanks
John
March 28, 2005
In article <d24q1p$lv2$1@digitaldaemon.com>, John Demme says...
>
>OK.. so I've spent the last week (spring break) working on adding D name demangling to GDB... and I'm still having trouble.  The name demangling routine seems to work fine (I ported James Dunne's) but I've been unable to get GDB to use it all the time, so only some D symbols get demangled.
>
>Does anyone here have any experience hacking GDB?  I'll go to the GDB list next, but I was hoping that someone with an interest in D would be able to help.
>
>Thanks
>John

Cool!  Do you have a webspace where you could share your work at?  http, ftp, svn, whatever works...  BTW, this is the reason I wrote the demangling routines for ;)  I'd of course be interested in helping hacking on GDB.

Regards,
James Dunne
March 28, 2005
I've got some space, but I'm thinking it might be better to get Brad to host it at dsource.org.  Since it's really just a patch against GDB, however, does one commit revisions to the patch file, or does one essentially fork GDB in to a svn repositiory, then build patches from the svn repos... I'm thinking the latter.

I'll email Brad and ask him to create a new project.. or at least a new repository.

BTW... if this is what you wrote the demangling program for, why'd you write it in D instead of C?

John

On Mon, 2005-03-28 at 17:28 +0000, James Dunne wrote:
> In article <d24q1p$lv2$1@digitaldaemon.com>, John Demme says...
> >
> >OK.. so I've spent the last week (spring break) working on adding D name demangling to GDB... and I'm still having trouble.  The name demangling routine seems to work fine (I ported James Dunne's) but I've been unable to get GDB to use it all the time, so only some D symbols get demangled.
> >
> >Does anyone here have any experience hacking GDB?  I'll go to the GDB list next, but I was hoping that someone with an interest in D would be able to help.
> >
> >Thanks
> >John
> 
> Cool!  Do you have a webspace where you could share your work at?  http, ftp, svn, whatever works...  BTW, this is the reason I wrote the demangling routines for ;)  I'd of course be interested in helping hacking on GDB.
> 
> Regards,
> James Dunne

March 29, 2005
In article <1112049555.20564.4.camel@localhost.localdomain>, John Demme says...
>
>I've got some space, but I'm thinking it might be better to get Brad to host it at dsource.org.  Since it's really just a patch against GDB, however, does one commit revisions to the patch file, or does one essentially fork GDB in to a svn repositiory, then build patches from the svn repos... I'm thinking the latter.

Yeah, now that I think of it, the whole gdb source tree would be best, and you should regularly build patches and regularly update the gdb source.  My only concern would be that dsource.org is mainly for projects written in the D language, while gdb is obviously in C.  OTOH, gdb support for the D language is probably an acceptable exception to the general rule here.

>
>I'll email Brad and ask him to create a new project.. or at least a new repository.
>
>BTW... if this is what you wrote the demangling program for, why'd you write it in D instead of C?

It's easy to write in D, and I was planning on using it in a project later, but got sidetracked.  Besides, it's quite clear what's going on in the D code, whereas you (not you specifically) might get lost in C's strcpy, strcmp, strcat, malloc, free, etc. before you know what's going on.  The code doesn't use many D-isms, so I imagine it wasn't that hard to port ;)

Just curious, which module did you use?  I have two demangler D modules - one that is class/struct oriented which creates linked lists of inherited classes to represent definitions, and the other is pretty much string/token based with no object-oriented features.  It was a long time ago that I wrote these, so I don't remember if I released both or not.


Regards,
James Dunne
March 29, 2005
James Dunne wrote:

> Yeah, now that I think of it, the whole gdb source tree would be best, and you
> should regularly build patches and regularly update the gdb source.  My only
> concern would be that dsource.org is mainly for projects written in the D
> language, while gdb is obviously in C.  OTOH, gdb support for the D language is
> probably an acceptable exception to the general rule here.

GDB sources, with D patches, would be a nice thing to host with GDC...
Only problem is that GDC doesn't have any hosting either, at the moment.

736K    gdc-0.10.tar.bz2

 26M    gcc-3.4.3.tar.bz2
or
 12M    gcc-core-3.4.3.tar.bz2
2.4M    gcc-g++-3.4.3.tar.bz2
4.5M    gcc-java-3.4.3.tar.bz2

 13M    gdb-6.3.tar.bz2

But after the next release version of GDC, it will need a new home page.
And then it would be good to host a patched GDB too, on the same server?


I don't think Dsource has the bandwidth for tarballs and binary files,
but it doesn't hurt to ask of course... Brad can't say more than "no".

--anders
March 29, 2005
On Tue, 2005-03-29 at 18:36 +0000, James Dunne wrote:
> In article <1112049555.20564.4.camel@localhost.localdomain>, John Demme says...
> >
> >I've got some space, but I'm thinking it might be better to get Brad to host it at dsource.org.  Since it's really just a patch against GDB, however, does one commit revisions to the patch file, or does one essentially fork GDB in to a svn repositiory, then build patches from the svn repos... I'm thinking the latter.
> 
> Yeah, now that I think of it, the whole gdb source tree would be best, and you should regularly build patches and regularly update the gdb source.  My only concern would be that dsource.org is mainly for projects written in the D language, while gdb is obviously in C.  OTOH, gdb support for the D language is probably an acceptable exception to the general rule here.

Due to bandwidth and space concerns, I'm going to go with mostly patches.  You'll understand when you see it.  Brad's set up the project, so I'm going to reorganize that I have, and put it up along with some directions.

> 
> >
> >I'll email Brad and ask him to create a new project.. or at least a new repository.
> >
> >BTW... if this is what you wrote the demangling program for, why'd you write it in D instead of C?
> 
> It's easy to write in D, and I was planning on using it in a project later, but got sidetracked.  Besides, it's quite clear what's going on in the D code, whereas you (not you specifically) might get lost in C's strcpy, strcmp, strcat, malloc, free, etc. before you know what's going on.  The code doesn't use many D-isms, so I imagine it wasn't that hard to port ;)
> 
> Just curious, which module did you use?  I have two demangler D modules - one that is class/struct oriented which creates linked lists of inherited classes to represent definitions, and the other is pretty much string/token based with no object-oriented features.  It was a long time ago that I wrote these, so I don't remember if I released both or not.

I used the one that was in dsource.org's bindings repository- no classes.

Hopefully if we can get this working, Walter will get the DWARF2 information generation working. :)  Once that's working, we can really get going on GDB D support.

John Demme

March 29, 2005
Anders F Björklund wrote:
> James Dunne wrote:
> 
>> Yeah, now that I think of it, the whole gdb source tree would be best, and you
>> should regularly build patches and regularly update the gdb source.  My only
>> concern would be that dsource.org is mainly for projects written in the D
>> language, while gdb is obviously in C.  OTOH, gdb support for the D language is
>> probably an acceptable exception to the general rule here.
> 
> 
> GDB sources, with D patches, would be a nice thing to host with GDC...
> Only problem is that GDC doesn't have any hosting either, at the moment.
> 
> 736K    gdc-0.10.tar.bz2
> 
>  26M    gcc-3.4.3.tar.bz2
> or
>  12M    gcc-core-3.4.3.tar.bz2
> 2.4M    gcc-g++-3.4.3.tar.bz2
> 4.5M    gcc-java-3.4.3.tar.bz2
> 
>  13M    gdb-6.3.tar.bz2
> 
> But after the next release version of GDC, it will need a new home page.
> And then it would be good to host a patched GDB too, on the same server?
> 
> 
> I don't think Dsource has the bandwidth for tarballs and binary files,
> but it doesn't hurt to ask of course... Brad can't say more than "no".
> 
> --anders

These sizes don't necessarily scare me.  Those sizes plus *lots* of traffic kind of scares me, but *lots* is to be determined.

I'm not sure about hosting the gcc/gdb tarballs, but holding gdb code in a repos (maybe private, only for the patch developers) would be okay. It would be great to go to one place to get all of this, but maybe at first, we could try the private repos and no gcc/gdb tarballs.

BA
March 31, 2005
OK... I've put some code up on DSource, and a short message on the forum explaining what the files are.

It doesn't really.. umm... work at this point, but I think it's close.... just can't figure out all this GDB stuff... grrr...

John Demme

In article <1112132615.8515.3.camel@localhost.localdomain>, John Demme says...
>
>On Tue, 2005-03-29 at 18:36 +0000, James Dunne wrote:
>> In article <1112049555.20564.4.camel@localhost.localdomain>, John Demme says...
>> >
>> >I've got some space, but I'm thinking it might be better to get Brad to host it at dsource.org.  Since it's really just a patch against GDB, however, does one commit revisions to the patch file, or does one essentially fork GDB in to a svn repositiory, then build patches from the svn repos... I'm thinking the latter.
>> 
>> Yeah, now that I think of it, the whole gdb source tree would be best, and you should regularly build patches and regularly update the gdb source.  My only concern would be that dsource.org is mainly for projects written in the D language, while gdb is obviously in C.  OTOH, gdb support for the D language is probably an acceptable exception to the general rule here.
>
>Due to bandwidth and space concerns, I'm going to go with mostly patches.  You'll understand when you see it.  Brad's set up the project, so I'm going to reorganize that I have, and put it up along with some directions.
>
>> 
>> >
>> >I'll email Brad and ask him to create a new project.. or at least a new repository.
>> >
>> >BTW... if this is what you wrote the demangling program for, why'd you write it in D instead of C?
>> 
>> It's easy to write in D, and I was planning on using it in a project later, but got sidetracked.  Besides, it's quite clear what's going on in the D code, whereas you (not you specifically) might get lost in C's strcpy, strcmp, strcat, malloc, free, etc. before you know what's going on.  The code doesn't use many D-isms, so I imagine it wasn't that hard to port ;)
>> 
>> Just curious, which module did you use?  I have two demangler D modules - one that is class/struct oriented which creates linked lists of inherited classes to represent definitions, and the other is pretty much string/token based with no object-oriented features.  It was a long time ago that I wrote these, so I don't remember if I released both or not.
>
>I used the one that was in dsource.org's bindings repository- no classes.
>
>Hopefully if we can get this working, Walter will get the DWARF2 information generation working. :)  Once that's working, we can really get going on GDB D support.
>
>John Demme
>