www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GDB Hacking

reply John Demme <me teqdruid.com> writes:
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
Mar 26 2005
parent reply James Dunne <jdunne4 bradley.edu> writes:
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
Mar 28 2005
parent reply John Demme <me teqdruid.com> writes:
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
Mar 28 2005
parent reply James Dunne <jdunne4 bradley.edu> writes:
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
Mar 29 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 29 2005
parent Brad Anderson <brad dsource.dot.org> writes:
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
Mar 29 2005
prev sibling parent reply John Demme <me teqdruid.com> writes:
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
Mar 29 2005
parent John Demme <me teqdruid.com> writes:
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
Mar 30 2005