Re: [patches] AVR32 port

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Wed, 6 May 2009, Bradley Smith wrote:

> 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?

I don't think there's any real practical use in putting the code in the 
other branches, given that it would need an NPTL port to work there; 
putting it in trunk and keeping sysdeps files updated there, as well as a 
working version in 2.5, would be enough.

> 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).

Yes, TLS is required, and some kernel support (how much depends on the 
details of the ISA, e.g. whether it has atomic operations or whether 
kernel support is needed for those).  You could for example work on the 
ABI and post it to the user community for comment.

> 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.

We once applied such patches, then reverted them because of a confusion 
over copyright assignments.  I think the final conclusion 
<http://www.eglibc.org/archives/patches/msg00107.html> was that the 
patches as applied at that time could go back in, with adjustments to the 
ChangeLog entries.

> > 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).

The simplest thing is certainly just going with trunk (after 2.10 
branches) and ignoring compatibility with previous versions.  But that 
depends on whether users will be OK with a future ABI break.  It is 
possible to use GLIBC_2.11 versions on a past branch if you backport 
Ulrich's version of my patch to allow GLIBC_2.10 versions to sort 
correctly in version lists.

> > 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?

http://gcc.gnu.org/wiki/CopyrightAssignment (I think the same form applies 
here as well).

I believe you should name GLIBC as the package, and tell the FSF to let me 
know once the assignment has been processed (since the FSF glibc 
maintainers won't care about it).

> > 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
> deal.

A psABI document is very useful for people trying to deal with bugs in any 
of the components, or make global changes to them, so you can tell what 
the code is trying to implement.

Regarding e_machine values, it is easy to make a binutils port accept old 
objects as input but always use the official value for new objects; just 
define ELF_MACHINE_ALT1 to the old unofficial value if you wish to do 
that.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx