Re: [patches] AVR32 port

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

On Wed, 6 May 2009, Bradley Smith wrote:

> Hi,
> 
> I'm current working on an AVR32 port of glibc[0], which is pretty much done
> now, and is being used in the Debian port of the architecture. Although
> due to lack of TLS support in the toolchain, only 2.5 can be ported, (with
> the help of the notls patch from Debian). So I'm just writing to ask if it
> is possible to work towards merging this in the 2.5 branch? Or is the
> purpose of that branch only for bug fixes? Regardless, I thought I'd give
> people a heads up as to the arrival of this port. Once the time comes and
> TLS is done, I'd very much like to become the maintainer of this port if
> needed. (I'm not sure how this works in eglibc?). Any advice on how to
> proceed with all of this would be very much appreciated.

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.

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.  This 
would require having an NPTL port, though.  Another thing is 
arch_minimum_kernel; set that to the version for which kernel support was 
merged in kernel.org, or the version for which the kernel/userspace ABI 
was fixed if later, and ensure that your kernel-features.h file properly 
handles all the macros the libc version only defines for some 
architectures.

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

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.

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

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx