[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patches] AVR32 port

On Wed, 6 May 2009 14:28:58 +0000 (UTC)
"Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx> wrote:

> New ports may be accepted in past branches to a limited extent, but we 
> don't want newer branches and trunk to regress relative to them; at
> least, if adding a port to an old branch I'd say you need also to have a
> trunk version, with all the sysdeps files updated for all the post-2.5
> changes in the libc versions of those files, to commit to trunk at the
> same time, and to keep that version up to date in future, even if if
> won't work for lack of TLS.  I also strongly recommend working on TLS
> support and an NPTL port.

Mm, tracking trunk as well as having code in the 2.5 branch seems like a
sensible thing to do, I assume I wouldn't have to worry about the other
branches between 2.5 and trunk?

TLS is something that is on the cards, but as fair as I'm aware, isn't
going to pursued until the toolchain patches have found their way
upstream. As fair as I'm aware NPTL requires TLS? So not much can be done
about that at this stage. (Other than preliminary work obviously).

Also, in order to get 2.5 to work all the notls patch[0] from debian has
been used, as I mentioned. Is this something that could potentially be
commited into this branch? If it hasn't already been.

> One thing to consider for a new port is symbol versions; if you are not 
> bound by backwards compatibility to old binaries, you can set the
> minimum symbol version (DEFAULT line in shlib-versions) to the version
> for which you add support on trunk (GLIBC_2.11, supposing this is not in
> before 2.10 branches) and so avoid some compatibility code in the
> libraries.

How would this work if there was a port put into the 2.5 branch? I assume
you'd have to have GLIBC_2.5 in trunk also? Or could you just forget
about that and use GLIBC_2.11? In that light do you think it's really
worth pushing code into the 2.5 branch or just worry about trunk?
(obviously with it not working due to the lack of TLS).

> EGLIBC follows the same copyright assignment requirements as FSF glibc,
> so all significant contributors to the port must have copyright
> assignments for it (naming GLIBC / GNU C Library, not EGLIBC), and
> employer assignments/disclaimers as needed, on file at the FSF before we
> can consider the port.

This is something I need to do, are there any documents anywhere
explaining what needs to be done for this?

> Subject to that, EGLIBC can certainly take ports
> not in the FSF glibc ports collection, although that would mean you need
> to undertake to update sysdeps files in EGLIBC to account for changes to
> the libc version after I merge in the libc changes from FSF glibc at
> irregular intervals (as opposed to after the changes are committed to
> FSF glibc, which would be the case for ports in the FSF ports
> collection).

Going into EGLIBC first and then to the FSF glibc once everything is
finished and ready seems like a less painful, more sensible route to me,
so I'm happy with the need to do that.

> Although I don't think there is a requirement that the other toolchain 
> components have their ports present upstream before a port goes into 
> EGLIBC, getting them upstream is still a very good idea to facilitate 
> testing; a conventional order would be to get binutils upstream first 
> (since a binutils port can be tested using just the binutils
> testsuites), then GCC (which may be tested on simulators if available
> for a bare-metal target, for which the libc (newlib?) port is likely to
> be simpler than glibc), then EGLIBC once the tools are available to
> build the EGLIBC port. If support has been added to a free simulator
> (e.g. QEMU or the GDB simulator), then that would be contributed at any
> convenient point; likewise a GDB port.  So I encourage working on those
> other submissions (and the prerequisite copyright assignments) if not
> already done.  They may be more critical if you wish at some point to
> add the port to the FSF ports collection.

The binutils and GCC ports (and possibly GDB) are already making their way
upstream (currently stuck in the legal department I believe), and there is
a uclibc port already. A QEMU port has been attempted in the past by
myself and others, so this is something that may reappear in the future.

> At least, you need to point to where the ports of other components can
> be found.  Likewise, there should be a public psABI document available
> at a known location.  Do you have an official ELF e_machine value for
> the port (obtained from registry@xxxxxxx; nowadays CC the 
> http://groups.google.com/group/generic-abi group)?  That's something
> that it's also a good idea to finalise before submitting toolchain ports 
> upstream (actually, it's a good idea to get at the very first stages of 
> starting a port).

Currently there isn't a public psABI document anywhere, although I'm told
there is an unofficial one available which I'm currently trying to get hold
of, I shall look further into this. In light of what you said about the
e_machine number, I've just discovered that the value currently being used
is an unofficial one, so this is going to need to be sorted out too, but
is obviously very much in Atmels hands since it will affect them a great

Bradley Smith

[0] http://files.brad-smith.co.uk/local-notls.diff.txt

Bradley Smith                                     brad@xxxxxxxxxxxxxxxx
Debian GNU/Linux Developer                         bradsmith@xxxxxxxxxx
GPG: 0xC718D347       D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347

Attachment: signature.asc
Description: PGP signature