Huge Apple gdb code dropping^H^H^H^H

Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

Hi gdb'ers,

Apple maintains a modified version of gdb for their Mach/BSD based OS,
MacOS X.  As I understand it, this gdb was inherited from a port done
and maintained at NeXT many moons ago (shout out to Michael), so it's
got a lot of history.  We have an assignment to the FSF all signed these
days, but we haven't had time to get the patches into an appropriate form
for submission.

Andrew wants to get these patches exposed to the light of day, and
even though we're plugging away at getting some clean submissions
put together, he wants the whole enchilada out there.  I'm always
happy to oblige Andrew, so I've done this.

I want to note that I am creating this patch under duress. :-)  I
think this patch is wholly useless and the only thing accomplished by
assembling it is to keep me from watching TV for an evening.  A
useful result, I'll admit, but I think that's all we'll see.  Here are
some of the reasons I believe this patch is useless:

    The gdb sources have been in cvs for less than two years -
    before that I've heard files were touched by hand.  There is
    a lot of cruft in here; there are pointless changes, changes
    that are wrong, changes that seem to have been made by aliens
    from another planet, changes that will serve as humor if you're
    in the right mood.  There are changes for things I've never
    heard of - what's a Motorola 98k series processor, anyway?  Why
    in the world was bfd/cpu-i960.c changed in our sources?  These
    and many other mysteries await the adventurous diff reader.

    The most recent FSF -> Apple merge that had taken place with
    these sources was November 2000.  We did our first import of
    year 2001 just last month.  Our trunk is not stable after this
    mondo merge, so I wanted to send these patches which are to
    the older, working version of gdb.

    Applying this is not easy.  The gdb repository on sourceware
    was originally imports from the Cygnus repository, which Stan
    and I would do periodically.  For files that didn't have a real
    checkin after these imports were ended, doing a "cvs co -D
    2000-11-13" will give you the 1.1 version, not the correct
    import version.  When doing my initial sanity checks, I had to
    run some scripts over my checkout of the FSF sources to get a
    real vision of what the gdb sources looked like on 2000-11-13.

    The testsuite has been utterly ignored.  It's a mess, you'll
    get 400-800 test failures if you can get it to work at all.
    I gather tcl+expect+dejagnu could crash the early versions of
    MacOS X, so not a lot of time has been spent on the testsuite
    yet.  (they no longer crash the OS, BTW)

    Last I checked, our sources won't even build on non-MacOS X hosts.

    You'll need to create a gdb-next and gdb-next/display-support
    directories (gdb-next is a sibling of gdb/) before applying the
    patch.  This is where all the host support exists.

    Very very very few ChangeLog entries, and the vast majority of
    the cvs commit messages are empty as well.

    This is almost certainly a one-time snapshot.  If people really
    want to see what's up with the Apple sources on a continuing
    basis, the work is all happening on publically visible cvs
    servers.  We require developers to get a login through a
    registration form, but that's a one-time annoyance which people
    can suffer through.
    
    I may put together a similar diff of our current trunk sources
    (which are being regularly merged with current FSF sources) after
    they've become a bit more stable.

To make everyone's lives easier, I'm also providing a copy of the
stable Apple gdb sources in a plain tar file.  You may prefer the
diffs for browsing, but you'll prefer the plain tar file if you're
thinking of building this.


With all that said, why would you want this?  Well, one thing is
that we're getting this all officially on the record as existing.
Apple has talked about submitting things for ages, and I think we
really are close to starting, but it doesn't hurt to throw this
out there.  All of the Objective C gdb support should be in this
file, in one way or another, and I know folks are interested in
that.

You should be able to build the tar file easily on a MacOS X 10.1
system.  You'll need to configure with --enable-gdbmi, but that's
the only oddity that comes to mind right away (some UI_OUT code
isn't guarded with ifdefs).


For people not familiar, basic background:  Mach is the kernel,
BSD sits on top of that, the two combined seem to be called "Darwin".
Our gdb has to handle both Mach signals and POSIX signals, and that
adds a lot of complication.  Apple has an integrated development
environment with a GUI debugger interface, which talks to gdb via MI.
A fair amount of work has gone into tweaking MI, and none of it has
gone into matching changes to the testsuite - cf earlier statement
about 400-800 failures.

Darwin runs mostly on PPC and x86, although I gather it can be made
to work on other processors with enough patience.  Most of our work
at Apple is on the PPC side of things.

Objective C is a version of C with classes from NeXT.  It uses
brackets a lot, and its programmers think it's a great language. :-)
Most importantly to gdb, ObjC names have no mangled form and have
lots of spaces in them - you'll see symbol names like "-[NSExcpetion
raise]" and that's how it looks at all stages of compilation/reading.

The object file format is called MachO.  I don't know much about it,
it appears pretty divergent from everything else I've seen.  Apple has
its own linker and assembler (based on old circa 1.35 gas gld) with
little resemblance to their modern counterparts.  There are some bfd
changes to handle MachO object file reading, and they work well enough
for gdb, but binutils itself is dodgy at best on Darwin.  

Shared libraries are called "dylibs", and MacOS has some system of
libraries called "frameworks".  I don't really understand what
Frameworks are all about - some kind of conglomeration of libraries
and includes for a particular facility.  I think X windows would
be a Framework, for instance.

You'll notice that our gdb depends on electric-fence, a GPL memory
guard program included in the sources, but there's no real dependency;
no one has gotten around to taking out the dependency and removing
the directory from our gdb module.

Ah, as an aside, I created this patch with the "-w" flag to diff
to suppress whitespace diffs.  You'd be surprised how many unnecessary
whitespace diffs were in the sources.

Here is the patch:

ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch-vs-fsf-2000-11-13.diffs.bz2

And here is the tarball:

ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch.tar.bz2


Apple has an anoncvs server where you can get all of this for yourself, 
look at http://www.opensource.apple.com/.  You have to register to get
access to the anoncvs server (don't blame me, I agree that it's weak),
but I've heard it's a trivial little web form where you provide a name and
other information of optional veracity, and it gives you access to the
sources.  BTW I've heard our cvs server is offline currently due to some
problems or something, so don't run right out and be surprised when there
is a problem.  I'd assume it'll be back within the next week, but I know
nothing about what's up.

Feel free to ask questions, but questions that begin with "What the
hell is <crap crap crap> doing in file <shouldn't-be-touching-this>.c"
will not rate very high on my daily TODO list to reply to.

With luck, we'll have some real patch submissions in the near future
and this patch can fade into our distant memories.

Jason
Free the Software!

Re: Huge Apple gdb code dropping^H^H^H^H

[David Relson]

At 03:59 AM 11/29/01, Jason Molenda wrote:


>Objective C is a version of C with classes from NeXT.  It uses
>brackets a lot, and its programmers think it's a great language. :-)
>Most importantly to gdb, ObjC names have no mangled form and have
>lots of spaces in them - you'll see symbol names like "-[NSExcpetion
>raise]" and that's how it looks at all stages of compilation/reading.

Jason,

This is good news!  Objective C is one of the languages supported by 
gcc.  It is also the language used in the GNUstep project, which brings 
NeXTSTEP/OpenStep capability to Linux, BSD, Windoze, etc.  Of importance to 
me, it allows a project I wrote for NeXTSTEP/OpenStep to run on Linux.

Objective C support has not been part of mainline gdb for several years - 
at least since gdb 4.17.  There have been "unofficial" patches for 4.17, 
4.18, and 5.0, but as gdb has evolved over the years it has become 
increasingly difficult to port the unofficial patches to each successive 
version of gdb.  Having the Objective C support code be part of the 
official, mainline of gdb is something I've wanted for the last couple of 
years.

David

Re: Huge Apple gdb code dropping^H^H^H^H

[Stan Shebs]

Jason Molenda wrote:
> 
> I want to note that I am creating this patch under duress. :-)  I
> think this patch is wholly useless and the only thing accomplished by
> assembling it is to keep me from watching TV for an evening.  A
> useful result, I'll admit, but I think that's all we'll see.  Here are
> some of the reasons I believe this patch is useless:

Also, there's reason to believe that it includes sources to the
feared CodeNimdaLovesRedMelissa virus, probably hidden in the
longer filenames.  I was hearing evil cackles from Jason's office
the last time I was in Cupertino.  So beware!

:-)

Stan

Re: Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

Andrew asked for some kind of official sounding statement, so here it 
is.  As a duly appointed employee of Apple, Inc. (All Praise the 
One-button Mouse), I hereby foist unto the FSF this steaming pile o' 
modifications to gdb, to share and enjoy, in sickness and in health, til 
bitrot do you part.

Jason
Apple, Inc.

On Thursday, November 29, 2001, at 12:59 AM, Jason Molenda wrote:

> Apple maintains a modified version of gdb for their Mach/BSD based OS,
> MacOS X.


> Here is the patch:
>
> ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch-vs-fsf-2000-11-13.
> diffs.bz2
>
> And here is the tarball:
>
> ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch.tar.bz2
>

Re: Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

David Relston wrote:

> This is good news!  Objective C is one of the languages supported by
> gcc.  It is also the language used in the GNUstep project, which brings
> NeXTSTEP/OpenStep capability to Linux, BSD, Windoze, etc.  Of 
> importance to
> me, it allows a project I wrote for NeXTSTEP/OpenStep to run on Linux.

Yep, all the ObjC changes are in that mega patch.  As I wrote in the 
note, we
are working on a clean ObjC support patch to be submitted -- this is one 
of
the most useful big changes in our tree and we want to get it integrated 
into
the FSF sources.  I believe we'll have that patch out soon; Andrew is 
less
optimistic and wants an unfiltered patch in the hand instead of two in 
the
bush. :-)

> Objective C support has not been part of mainline gdb for several 
> years -
> at least since gdb 4.17.  There have been "unofficial" patches for 4.17,
> 4.18, and 5.0, but as gdb has evolved over the years it has become
> increasingly difficult to port the unofficial patches to each successive
> version of gdb.  Having the Objective C support code be part of the
> official, mainline of gdb is something I've wanted for the last couple 
> of
> years.

I'm not any kind of expert on the history of ObjC patches, but I believe 
these
patches are originally written by Michael Snyder when he was working at 
NeXT.
He's been trying to get a clear copyright assignment to the FSF for them 
for
years, but hasn't gotten that permission from the NeXT management.  
NeXT+Apple
has Seen The Light and is happy to assign changes to gdb back to the FSF.
(in theory, we could probably even get a clear statement about the old 
ObjC
support patches if someone was really interested in trying to bring them 
up to
date and merge them in.  But I'd obviously prefer that we go with the 
ObjC
patches in use at Apple. :-)

The changes on the net are probably not the same as the changes in the 
Apple
patch I submitted.  I gather there were multiple ObjC implementations 
done at
NeXT, and the one on the net was a big rewrite by Michael intended to 
fix a
number of bogosities in the other one.  We may have this 'other one' as 
our
main sources these days.  As I said, we've got no revision history from 
before
2000, and none of the people currently working on gdb have been at it 
for more
than a few years.

Jason

Re: Huge Apple gdb code dropping^H^H^H^H

[Andrew Cagney]

> Andrew asked for some kind of official sounding statement, so here it is.  As a duly appointed employee of Apple, Inc. (All Praise the One-button Mouse), I hereby foist unto the FSF this steaming pile o' modifications to gdb, to share and enjoy, in sickness and in health, til bitrot do you part.

Thanks!  I'll figure out how to get it into the tree on some sort of branch.

Why is this useful (beside using this warm steaming pile o' for central 
heating)?

It clearly transfers the code to the FSF so that anyone, not just Apple 
employees, can confidently steal the interesting bits so that GDB can be 
made to work.

Andrew
Card carrying memeber of the 3 button USB moose owners association.

Re: Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

On Thursday, November 29, 2001, at 01:33 PM, Andrew Cagney wrote:

> Thanks!  I'll figure out how to get it into the tree on some sort of 
> branch.

You might want to wait for me to send in the current Apple sources.  As 
I noted, they don't work so well right now, but they are merged with the 
latest FSF sources and they should be a little easier to wrangle into 
shape if anyone is interested in doing so.  (our local changes should be 
nearly identical in both cases, they'll just be targeted to a more 
recent gdb version)

BTW you'll obviously want to avoid a cvs import, or all our gdb-next/ 
directory will appear on the trunk.

> Andrew
> Card carrying memeber of the 3 button USB moose owners association.

Hm, I think someone's been up in The Great White North a little too 
long...

Jason

Re: Huge Apple gdb code dropping^H^H^H^H

[Daniel Berlin]

On Thu, 29 Nov 2001, Andrew Cagney wrote:

> > Andrew asked for some kind of official sounding statement, so here it is.  As a duly appointed employee of Apple, Inc. (All Praise the One-button Mouse), I hereby foist unto the FSF this steaming pile o' modifications to gdb, to share and enjoy, in sickness and in health, til bitrot do you part.
>
> Thanks!  I'll figure out how to get it into the tree on some sort of branch.
>
> Why is this useful (beside using this warm steaming pile o' for central
> heating)?
>
> It clearly transfers the code to the FSF so that anyone, not just Apple
> employees, can confidently steal the interesting bits so that GDB can be
> made to work.
>
> Andrew
> Card carrying memeber of the 3 button USB moose owners association.

I was not aware they had three button mooses down there.

--Dan

Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

Hi gdb'ers,

Apple maintains a modified version of gdb for their Mach/BSD based OS,
MacOS X.  As I understand it, this gdb was inherited from a port done
and maintained at NeXT many moons ago (shout out to Michael), so it's
got a lot of history.  We have an assignment to the FSF all signed these
days, but we haven't had time to get the patches into an appropriate form
for submission.

Andrew wants to get these patches exposed to the light of day, and
even though we're plugging away at getting some clean submissions
put together, he wants the whole enchilada out there.  I'm always
happy to oblige Andrew, so I've done this.

I want to note that I am creating this patch under duress. :-)  I
think this patch is wholly useless and the only thing accomplished by
assembling it is to keep me from watching TV for an evening.  A
useful result, I'll admit, but I think that's all we'll see.  Here are
some of the reasons I believe this patch is useless:

    The gdb sources have been in cvs for less than two years -
    before that I've heard files were touched by hand.  There is
    a lot of cruft in here; there are pointless changes, changes
    that are wrong, changes that seem to have been made by aliens
    from another planet, changes that will serve as humor if you're
    in the right mood.  There are changes for things I've never
    heard of - what's a Motorola 98k series processor, anyway?  Why
    in the world was bfd/cpu-i960.c changed in our sources?  These
    and many other mysteries await the adventurous diff reader.

    The most recent FSF -> Apple merge that had taken place with
    these sources was November 2000.  We did our first import of
    year 2001 just last month.  Our trunk is not stable after this
    mondo merge, so I wanted to send these patches which are to
    the older, working version of gdb.

    Applying this is not easy.  The gdb repository on sourceware
    was originally imports from the Cygnus repository, which Stan
    and I would do periodically.  For files that didn't have a real
    checkin after these imports were ended, doing a "cvs co -D
    2000-11-13" will give you the 1.1 version, not the correct
    import version.  When doing my initial sanity checks, I had to
    run some scripts over my checkout of the FSF sources to get a
    real vision of what the gdb sources looked like on 2000-11-13.

    The testsuite has been utterly ignored.  It's a mess, you'll
    get 400-800 test failures if you can get it to work at all.
    I gather tcl+expect+dejagnu could crash the early versions of
    MacOS X, so not a lot of time has been spent on the testsuite
    yet.  (they no longer crash the OS, BTW)

    Last I checked, our sources won't even build on non-MacOS X hosts.

    You'll need to create a gdb-next and gdb-next/display-support
    directories (gdb-next is a sibling of gdb/) before applying the
    patch.  This is where all the host support exists.

    Very very very few ChangeLog entries, and the vast majority of
    the cvs commit messages are empty as well.

    This is almost certainly a one-time snapshot.  If people really
    want to see what's up with the Apple sources on a continuing
    basis, the work is all happening on publically visible cvs
    servers.  We require developers to get a login through a
    registration form, but that's a one-time annoyance which people
    can suffer through.
    
    I may put together a similar diff of our current trunk sources
    (which are being regularly merged with current FSF sources) after
    they've become a bit more stable.

To make everyone's lives easier, I'm also providing a copy of the
stable Apple gdb sources in a plain tar file.  You may prefer the
diffs for browsing, but you'll prefer the plain tar file if you're
thinking of building this.


With all that said, why would you want this?  Well, one thing is
that we're getting this all officially on the record as existing.
Apple has talked about submitting things for ages, and I think we
really are close to starting, but it doesn't hurt to throw this
out there.  All of the Objective C gdb support should be in this
file, in one way or another, and I know folks are interested in
that.

You should be able to build the tar file easily on a MacOS X 10.1
system.  You'll need to configure with --enable-gdbmi, but that's
the only oddity that comes to mind right away (some UI_OUT code
isn't guarded with ifdefs).


For people not familiar, basic background:  Mach is the kernel,
BSD sits on top of that, the two combined seem to be called "Darwin".
Our gdb has to handle both Mach signals and POSIX signals, and that
adds a lot of complication.  Apple has an integrated development
environment with a GUI debugger interface, which talks to gdb via MI.
A fair amount of work has gone into tweaking MI, and none of it has
gone into matching changes to the testsuite - cf earlier statement
about 400-800 failures.

Darwin runs mostly on PPC and x86, although I gather it can be made
to work on other processors with enough patience.  Most of our work
at Apple is on the PPC side of things.

Objective C is a version of C with classes from NeXT.  It uses
brackets a lot, and its programmers think it's a great language. :-)
Most importantly to gdb, ObjC names have no mangled form and have
lots of spaces in them - you'll see symbol names like "-[NSExcpetion
raise]" and that's how it looks at all stages of compilation/reading.

The object file format is called MachO.  I don't know much about it,
it appears pretty divergent from everything else I've seen.  Apple has
its own linker and assembler (based on old circa 1.35 gas gld) with
little resemblance to their modern counterparts.  There are some bfd
changes to handle MachO object file reading, and they work well enough
for gdb, but binutils itself is dodgy at best on Darwin.  

Shared libraries are called "dylibs", and MacOS has some system of
libraries called "frameworks".  I don't really understand what
Frameworks are all about - some kind of conglomeration of libraries
and includes for a particular facility.  I think X windows would
be a Framework, for instance.

You'll notice that our gdb depends on electric-fence, a GPL memory
guard program included in the sources, but there's no real dependency;
no one has gotten around to taking out the dependency and removing
the directory from our gdb module.

Ah, as an aside, I created this patch with the "-w" flag to diff
to suppress whitespace diffs.  You'd be surprised how many unnecessary
whitespace diffs were in the sources.

Here is the patch:

ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch-vs-fsf-2000-11-13.diffs.bz2

And here is the tarball:

ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch.tar.bz2


Apple has an anoncvs server where you can get all of this for yourself, 
look at http://www.opensource.apple.com/ .  You have to register to get
access to the anoncvs server (don't blame me, I agree that it's weak),
but I've heard it's a trivial little web form where you provide a name and
other information of optional veracity, and it gives you access to the
sources.  BTW I've heard our cvs server is offline currently due to some
problems or something, so don't run right out and be surprised when there
is a problem.  I'd assume it'll be back within the next week, but I know
nothing about what's up.

Feel free to ask questions, but questions that begin with "What the
hell is <crap crap crap> doing in file <shouldn't-be-touching-this>.c"
will not rate very high on my daily TODO list to reply to.

With luck, we'll have some real patch submissions in the near future
and this patch can fade into our distant memories.

Jason
Free the Software!

Re: Huge Apple gdb code dropping^H^H^H^H

[David Relson]

At 03:59 AM 11/29/01, Jason Molenda wrote:


>Objective C is a version of C with classes from NeXT.  It uses
>brackets a lot, and its programmers think it's a great language. :-)
>Most importantly to gdb, ObjC names have no mangled form and have
>lots of spaces in them - you'll see symbol names like "-[NSExcpetion
>raise]" and that's how it looks at all stages of compilation/reading.

Jason,

This is good news!  Objective C is one of the languages supported by 
gcc.  It is also the language used in the GNUstep project, which brings 
NeXTSTEP/OpenStep capability to Linux, BSD, Windoze, etc.  Of importance to 
me, it allows a project I wrote for NeXTSTEP/OpenStep to run on Linux.

Objective C support has not been part of mainline gdb for several years - 
at least since gdb 4.17.  There have been "unofficial" patches for 4.17, 
4.18, and 5.0, but as gdb has evolved over the years it has become 
increasingly difficult to port the unofficial patches to each successive 
version of gdb.  Having the Objective C support code be part of the 
official, mainline of gdb is something I've wanted for the last couple of 
years.

David

Re: Huge Apple gdb code dropping^H^H^H^H

[Stan Shebs]

Jason Molenda wrote:
> 
> I want to note that I am creating this patch under duress. :-)  I
> think this patch is wholly useless and the only thing accomplished by
> assembling it is to keep me from watching TV for an evening.  A
> useful result, I'll admit, but I think that's all we'll see.  Here are
> some of the reasons I believe this patch is useless:

Also, there's reason to believe that it includes sources to the
feared CodeNimdaLovesRedMelissa virus, probably hidden in the
longer filenames.  I was hearing evil cackles from Jason's office
the last time I was in Cupertino.  So beware!

:-)

Stan

Re: Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

Andrew asked for some kind of official sounding statement, so here it 
is.  As a duly appointed employee of Apple, Inc. (All Praise the 
One-button Mouse), I hereby foist unto the FSF this steaming pile o' 
modifications to gdb, to share and enjoy, in sickness and in health, til 
bitrot do you part.

Jason
Apple, Inc.

On Thursday, November 29, 2001, at 12:59 AM, Jason Molenda wrote:

> Apple maintains a modified version of gdb for their Mach/BSD based OS,
> MacOS X.


> Here is the patch:
>
> ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch-vs-fsf-2000-11-13 .
> diffs.bz2
>
> And here is the tarball:
>
> ftp://sources.redhat.com/pub/gdb/contrib/apple-puma-branch.tar.bz2
>

Re: Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

David Relston wrote:

> This is good news!  Objective C is one of the languages supported by
> gcc.  It is also the language used in the GNUstep project, which brings
> NeXTSTEP/OpenStep capability to Linux, BSD, Windoze, etc.  Of 
> importance to
> me, it allows a project I wrote for NeXTSTEP/OpenStep to run on Linux.

Yep, all the ObjC changes are in that mega patch.  As I wrote in the 
note, we
are working on a clean ObjC support patch to be submitted -- this is one 
of
the most useful big changes in our tree and we want to get it integrated 
into
the FSF sources.  I believe we'll have that patch out soon; Andrew is 
less
optimistic and wants an unfiltered patch in the hand instead of two in 
the
bush. :-)

> Objective C support has not been part of mainline gdb for several 
> years -
> at least since gdb 4.17.  There have been "unofficial" patches for 4.17,
> 4.18, and 5.0, but as gdb has evolved over the years it has become
> increasingly difficult to port the unofficial patches to each successive
> version of gdb.  Having the Objective C support code be part of the
> official, mainline of gdb is something I've wanted for the last couple 
> of
> years.

I'm not any kind of expert on the history of ObjC patches, but I believe 
these
patches are originally written by Michael Snyder when he was working at 
NeXT.
He's been trying to get a clear copyright assignment to the FSF for them 
for
years, but hasn't gotten that permission from the NeXT management.  
NeXT+Apple
has Seen The Light and is happy to assign changes to gdb back to the FSF.
(in theory, we could probably even get a clear statement about the old 
ObjC
support patches if someone was really interested in trying to bring them 
up to
date and merge them in.  But I'd obviously prefer that we go with the 
ObjC
patches in use at Apple. :-)

The changes on the net are probably not the same as the changes in the 
Apple
patch I submitted.  I gather there were multiple ObjC implementations 
done at
NeXT, and the one on the net was a big rewrite by Michael intended to 
fix a
number of bogosities in the other one.  We may have this 'other one' as 
our
main sources these days.  As I said, we've got no revision history from 
before
2000, and none of the people currently working on gdb have been at it 
for more
than a few years.

Jason

Re: Huge Apple gdb code dropping^H^H^H^H

[Andrew Cagney]

> Andrew asked for some kind of official sounding statement, so here it is.  As a duly appointed employee of Apple, Inc. (All Praise the One-button Mouse), I hereby foist unto the FSF this steaming pile o' modifications to gdb, to share and enjoy, in sickness and in health, til bitrot do you part.

Thanks!  I'll figure out how to get it into the tree on some sort of branch.

Why is this useful (beside using this warm steaming pile o' for central 
heating)?

It clearly transfers the code to the FSF so that anyone, not just Apple 
employees, can confidently steal the interesting bits so that GDB can be 
made to work.

Andrew
Card carrying memeber of the 3 button USB moose owners association.

Re: Huge Apple gdb code dropping^H^H^H^H

[Jason Molenda]

On Thursday, November 29, 2001, at 01:33 PM, Andrew Cagney wrote:

> Thanks!  I'll figure out how to get it into the tree on some sort of 
> branch.

You might want to wait for me to send in the current Apple sources.  As 
I noted, they don't work so well right now, but they are merged with the 
latest FSF sources and they should be a little easier to wrangle into 
shape if anyone is interested in doing so.  (our local changes should be 
nearly identical in both cases, they'll just be targeted to a more 
recent gdb version)

BTW you'll obviously want to avoid a cvs import, or all our gdb-next/ 
directory will appear on the trunk.

> Andrew
> Card carrying memeber of the 3 button USB moose owners association.

Hm, I think someone's been up in The Great White North a little too 
long...

Jason

Re: Huge Apple gdb code dropping^H^H^H^H

[Daniel Berlin]

On Thu, 29 Nov 2001, Andrew Cagney wrote:

> > Andrew asked for some kind of official sounding statement, so here it is.  As a duly appointed employee of Apple, Inc. (All Praise the One-button Mouse), I hereby foist unto the FSF this steaming pile o' modifications to gdb, to share and enjoy, in sickness and in health, til bitrot do you part.
>
> Thanks!  I'll figure out how to get it into the tree on some sort of branch.
>
> Why is this useful (beside using this warm steaming pile o' for central
> heating)?
>
> It clearly transfers the code to the FSF so that anyone, not just Apple
> employees, can confidently steal the interesting bits so that GDB can be
> made to work.
>
> Andrew
> Card carrying memeber of the 3 button USB moose owners association.

I was not aware they had three button mooses down there.

--Dan

Re: More code code dropping

[Andrew Cagney]

[I changed mailing list to the more procedural gdb@]
[Doh! No I didn't I'll try again.]

Ada Core Techologies, Inc., is also in possession of a large set of 
modifications to GDB to make it Ada aware, which require quite a bit more
processing to turn into patches.  So, like Apple, we'd like to deposit
this heap o'code in a spot more convenient to the general public.  Not 
having
done this before, however, I'd appreciate knowing the appropriate procedure
for making such a deposit.

Can I suggest grabbing a current gdb snapshot from 
ftp://sources.redhat.com/pub/gdb/snapshots/current/ and then create a 
diff and tar ball using that as the reference point reference.  If you 
can make that available somewhere (posting here) I'll then pull it into 
the same directory as Apple's dropping.

After that, doing something like importing that tar ball into a vendor 
branch might be useful.

enjoy,
Andrew

Re: More code code dropping

[Paul Hilfinger]

Folks,

In discussing with Andrew Cagney the proper procedure for depositing ACT's 
Ada-related changes to GDB, I raised the question of what the most useful
patch would be (or if it matters).  Inasmuch as ACT's current GDB sources
are derived from the GDB 5.0 release from spring 2000, last re-merged 
in September 2000, I thought that a diff against the gdb 5.0 release 
was probably most useful.  Andrew had suggested a patch against the
latest, bleeding-edge changes.  Since the idea of a diff is to give the
curious some idea of our changes, it seemed to me that the latter diff would
show mostly undoings of more recent changes to GDB.  If anyone else out
there has an opinion on this subject, I'd like to hear it.

Paul Hilfinger

Re: More code code dropping

[Kevin Buettner]

On Dec 8,  3:15am, Paul Hilfinger wrote:

> I thought that a diff against the gdb 5.0 release 
> was probably most useful.  Andrew had suggested a patch against the
> latest, bleeding-edge changes.  Since the idea of a diff is to give the
> curious some idea of our changes, it seemed to me that the latter diff would
> show mostly undoings of more recent changes to GDB.  If anyone else out
> there has an opinion on this subject, I'd like to hear it.

I think it depends upon what you want.  Personally, I'd be interested
in seeing a patch that shows the changes that ACT has made.  So the
best candidate for diffing against would be the version of GDB that
you merged with in your most recent merge.

OTOH, a patch against the bleeding edge sources gives us a method of
obtaining your source tree.  Personally, I think it'd just be better
for you to drop a tarball someplace if this is what's desired.

As I think about it now, I think a tarball is probably the best
approach anyway.  That, along with a pointer to the version of
GDB that you merged against should allow those interested to
do their own diffs in whatever why they want...

Kevin

Re: More code code dropping

[David Relson]

At 10:54 AM 12/8/01, you wrote:
>On Dec 8,  3:15am, Paul Hilfinger wrote:
>
> > I thought that a diff against the gdb 5.0 release
> > was probably most useful.  Andrew had suggested a patch against the
> > latest, bleeding-edge changes.  Since the idea of a diff is to give the
> > curious some idea of our changes, it seemed to me that the latter diff 
> would
> > show mostly undoings of more recent changes to GDB.  If anyone else out
> > there has an opinion on this subject, I'd like to hear it.
>
>I think it depends upon what you want.  Personally, I'd be interested
>in seeing a patch that shows the changes that ACT has made.  So the
>best candidate for diffing against would be the version of GDB that
>you merged with in your most recent merge.
>
>OTOH, a patch against the bleeding edge sources gives us a method of
>obtaining your source tree.  Personally, I think it'd just be better
>for you to drop a tarball someplace if this is what's desired.
>
>As I think about it now, I think a tarball is probably the best
>approach anyway.  That, along with a pointer to the version of
>GDB that you merged against should allow those interested to
>do their own diffs in whatever why they want...
>
>Kevin

My vote would be for a tarball of the ACT version PLUS the diff.  The 
tarball would allow rebuilding of the executable, for those who want to do 
that.  The diff would allow the changes to be viewed and would allow the 
changes to be applied to (merged with) the latest version of gdb.

David

Re: More code code dropping

[Andrew Cagney]

 > Folks,
 >
 > In discussing with Andrew Cagney the proper procedure for depositing 
ACT's
 > Ada-related changes to GDB, I raised the question of what the most useful
 > patch would be (or if it matters).  Inasmuch as ACT's current GDB sources
 > are derived from the GDB 5.0 release from spring 2000, last re-merged
 > in September 2000, I thought that a diff against the gdb 5.0 release
 > was probably most useful.  Andrew had suggested a patch against the
 > latest, bleeding-edge changes.  Since the idea of a diff is to give the
 > curious some idea of our changes, it seemed to me that the latter 
diff would
 > show mostly undoings of more recent changes to GDB.  If anyone else out
 > there has an opinion on this subject, I'd like to hear it.


Valid point.  Apple handled this by putting up both an older stable
release and a current snap.

Anyway, regardless of how it is done, I think the main objective is to
just get Act's GDB changes contributed to the FSF.  That way they can be
merged in.

enjoy,
Andrew

Re: More code code dropping

[Jason Molenda]

On Thu, Dec 06, 2001 at 10:41:36PM -0800, Paul N. Hilfinger wrote:

> Not having
> done this before, however, I'd appreciate knowing the appropriate procedure
> for making such a deposit.

I thought my process was a reasonable one when I made the Apple
snapshot.  Our last merge to the FSF was Nov 2000, so the patch I
created showed the differences between our sources and the Nov 2000
FSF sources.  When I have some time, I plan to make another snapshot
of our sources against the current sources (Klee has brought our
internal gdb branch up to date with the FSF sources recently).  I
think trying to do both of these - send in your changes and update
your changes against the current gdb snapshots - will make the
process more difficult to complete.

When creating the diff, I used the obvious diff options; -Nwup if
I remember correctly.  I added -w because we had many meaningless
whitespace changes in our sources and I didn't want to bloat the
patch.

After doing this, I looked over my patch with diffstat to see the
distribution of changes and get a feel for whether the patch makes
sense.  I was doing my diff with cvs, and cvs was unhelpful when
the changes to a file were entirely whitespace - I'd end up with
an empty patch to that file (just the patch header, no actual
patches).  These don't cause any problems, but they make it look
like the patch is more widespread than it really is.  I removed
them by hand.

  (incidentally, if you are using cvs to do this, I'd try to use
   cvs 1.11 on the server and client - it records the directories
   in the diff filenames.  It makes patching infinitely easier.
   The cvs server on sourceware is still 1.10 for complicated
   reasons.)

Incidentally, I know you'll be diffing against an import in your
own tree or the gdb 5.0 tarball, but I was doing it against the
FSF cvs sources, so I found it very helpful to rsync over a copy
of the gdb CVS repository to my local system while I was doing all
these operations.  This also meant I could use cvs 1.11 on my local
system and get the pretty diffs that I wanted.  Details here:
	http://sourceware.cygnus.com/sourceware/rsync.html

When completed, I bzip2'ed the patch, and I included a .bz2 tarball
of the correctly patched sources.  In theory anyone should be able
to recreate that tarball given the patch file and the original
sources, but why not make it a bit easier for them.  That tarball
and patch are in
	ftp://sourceware.cygnus.com/pub/gdb/contrib

with a README file pointing to my mailing list announcement about
it and a short description of what these files are.  We might as
well give some tips to some poor sucker trying to understand what
these random files are years from now. :-)

I think the whole process took me five or six hours, but I had some
issues with cvs which added a fair amount of time.  A no-thinking-allowed
approach could finish this task in under an hour, I'm sure.

Hope that helps,

Jason

Re: More code code dropping

[Paul N. Hilfinger]

I have placed the Ada Core Technology Ada-aware GDB sources temporarily in

  http://www.cs.berkeley.edu/~hilfingr/gnat-gdb/

Andrew has kindly offered to move them to a more appropriate place at some
point.  After considering the various suggestions, I decided to drop
three things:

      1. Our sources.

      2. A copy of the CVS sources from which they branched off (as of
         4 Sept 2000 at 1326 PDT) 

      3. The patch file to get from 2 to 1.  

At some point, we will be integrating all of this into the public sources, and
of course, incorporating more recent changes.  

Paul Hilfinger

Re: More code code dropping

[Andrew Cagney]

> I have placed the Ada Core Technology Ada-aware GDB sources temporarily in
> 
>   http://www.cs.berkeley.edu/~hilfingr/gnat-gdb/
> 
> Andrew has kindly offered to move them to a more appropriate place at some
> point.  After considering the various suggestions, I decided to drop
> three things:


[I'm assuming this was ``Paul Hilfinger'' of Act :-)]

I've moved them to snapshot FTP site and added an item mentioning both 
this and the Apple contribution on the news page.


>       1. Our sources.
> 
>       2. A copy of the CVS sources from which they branched off (as of
>          4 Sept 2000 at 1326 PDT) 
> 
>       3. The patch file to get from 2 to 1.  
> 
> At some point, we will be integrating all of this into the public sources, and
> of course, incorporating more recent changes.  


Ok thanks.
	Andrew