[RFC] Darwin port (Part 0)

[RFC] Darwin port (Part 0)

[Tristan Gingold]

Hello,

here are a patch to add a new host/target: Darwin (or MacOS X).

Only a minimal set of features has been implemented: x86 and x86_64  
only (not ppc),
no support for core files, no support for fat files, no support for  
dynamic libraries,
no support for stabs (dwarf only).

The mach-o reader can handle dsym files and in object files dwarf -  
but both need to be improved.

Even all these restrictions I think the port is in good shape enough  
to be merged.  I have made
the minimal changes to common files in order to ease the merge.  Some  
planned changes (particularly
in the mach-o reader) will require modification to some common files  
and I'd prefer a first merge
before.

Two majors components (machoread.c and macosx-nat.c) have been  
rewritten from scratch but other
files (mainly i386-macosx-*.?) comes from Apple own branch of gdb.  As  
the Apple branch have never
been formally submitted the copyright status is not clear: I don't  
know if we can assume they have
been assigned to the FSF.  We have tried to contact Apple - but  
without success.  I am ready to rewrite
them in case of issue.

Also, this is my first contribution to gdb.  Comments will be very  
useful to me but please don't be
too harsh :-)

Tristan.

gdb:/
2008-11-10  Tristan Gingold  <gingold@adacore.com>

	* configure.host: Add Darwin host.
	* configure.tgt: Add Darwin target.
	* defs.h (enum gdb_osabi): Add GDB_OSABI_DARWIN and
	GDB_OSABI_DARWIN64.
	* osabi.c (gdb_osabi_names): Add names for darwin abis.
	* i386-macosx-nat.c: New file.
	* i386-macosx-tdep.c: New file.
	* i386-macosx-tdep.h: New file.
	* machoread.c: New file.
	* macosx-nat-info.c: New file.
	* macosx-nat.c: New file.
	* macosx-nat.h: New file.
	* macosx.defs: New file.
	* config/nm-macosx.h: New file.
	* config/i386/macosx.mh: New file.
	* config/i386/nm-i386-macosx.h: New file.

Re: [RFC] Darwin port (Part 0)

[Stan Shebs]

Tristan Gingold wrote:
> here are a patch to add a new host/target: Darwin (or MacOS X).
This is very exciting! I've made a couple tries at getting this going, 
but never managed to get the code disentangled enough to be useful. 
Rewriting sounds like it was the right way to cut the knot. :-)

What kind of pass/fail numbers are you seeing for the testsuite right 
now? (There's no threshold for submittability, but it tells us what to 
expect.)

There is no copyright obstacle that I know of - Apple made a blanket 
assignment to the FSF for all future GDB changes.

Stan

Re: [RFC] Darwin port (Part 0)

[Joel Brobecker]

> There is no copyright obstacle that I know of - Apple made a blanket 
> assignment to the FSF for all future GDB changes.

I'm still a bit concerned, primarily because I'm not a lawyer.
But does having a blanket assignment for all past and future changes
mean that any GDB code they write and put on their website is
automatically assigned to the FSF? I would have been less concerned
if they did a code drop for instance.

In terms of the patches themselves, I asked Tristan to remove
support for watchpoints because they are implemented the "old" way,
with macros defined in the NM file. I'd like to see them being
implemented through the gdbarch vector, but this can be done as
a separate patch. I haven't looked at the rest of the code yet,
but that was one thing that came up during our discussion on the
phone this morning.

-- 
Joel

Re: [RFC] Darwin port (Part 0)

[Stan Shebs]

Joel Brobecker wrote:
>> There is no copyright obstacle that I know of - Apple made a blanket 
>> assignment to the FSF for all future GDB changes.
>>     
>
> I'm still a bit concerned, primarily because I'm not a lawyer.
> But does having a blanket assignment for all past and future changes
> mean that any GDB code they write and put on their website is
> automatically assigned to the FSF? 
That's exactly what the blanket assignment means. In fact one of the 
goals, going back to the overall Darwin open source effort, was to 
enable non-Apple people to contribute code to public repositories 
without being blocked on Apple engineers unavailable due to internal 
deadlines and such. (Yes, it could also be thought of as exploiting the 
community :-) , but now it's working to our advantage.)

Stan

Re: [RFC] Darwin port (Part 0)

[Joel Brobecker]

> That's exactly what the blanket assignment means.

Great! So we can start reviewing this code whenever we want, then...

> In fact one of the goals, going back to the overall Darwin open source
> effort, was to enable non-Apple people to contribute code to public
> repositories without being blocked on Apple engineers unavailable due
> to internal deadlines and such. (Yes, it could also be thought of as
> exploiting the community :-) , but now it's working to our advantage.)

I've always seen this as a win-win situation, so I personally have never
had any problem with that. Someone donates contributions in one form and
someone else takes it from there to finish the work. Both parties do less
than they would have otherwise. The thing about "trying to exploit the
community" is that you're never guaranteed that someone will be interested
enough to pick it up, nor that he'll take your contributions in the
direction that you'd like. So there is still strong incentives to do
everything yourself - if you have the resources ;-).

-- 
Joel

Re: [RFC] Darwin port (Part 0)

[Tristan Gingold]

On Nov 10, 2008, at 6:44 PM, Stan Shebs wrote:

> Tristan Gingold wrote:
>> here are a patch to add a new host/target: Darwin (or MacOS X).
> This is very exciting! I've made a couple tries at getting this  
> going, but never managed to get the code disentangled enough to be  
> useful. Rewriting sounds like it was the right way to cut the  
> knot. :-)

Thanks.

> What kind of pass/fail numbers are you seeing for the testsuite  
> right now? (There's no threshold for submittability, but it tells us  
> what to expect.)

I haven't tried the GDB testsuite yet.  On our testsuite the results  
are rather good (less than 5% of
failures) but:
* as there is no support for shared libraries GDB can't call malloc()
* dSYM files should work well but they are not automatically generated
* reading dwarf from .o mostly works provided -fno-common is used...

Tristan.