This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: initfini.c -> crt[in].S


On Mon, 6 Feb 2012, Roland McGrath wrote:

> The wildcard sysdirs stuff makes me squirm.  It's not pedantically perfect,
> though in practice I'm sure it's fine.  But it's just such an ugly thing to
> be doing that I'm inclined to say we should just make it unconditional and
> have the arch maintainers do their parts promptly.

I think that would be a bad idea; we should try to keep things working on 
all libc platforms at every commit (at least to the extent of building OK 
and most tests passing) to avoid breaking things for anyone who happens to 
want to test and contribute a patch while things are in flux, and to keep 
bisection working optimally to find when problems were introduced.  
Naturally I'll clean things up *after* the libc architectures have all 
been converted; the state after my patch is intended to be an interim 
state to keep things working during the conversion.

(This does mean I think ____longjmp_chk could have been done better - I 
thought at the time it was a case of something needing arch maintainers to 
write the code, although with Chris's C implementation for linux-generic 
maybe that wasn't actually the case after all, but there could have been a 
dummy version omitting the checks for architectures that hadn't yet been 
converted.  And of course the sort of explanation I sent in 
<http://sourceware.org/ml/libc-ports/2009-08/msg00002.html> is always 
something it's useful to have for anything requiring arch maintainer 
action, so they don't need to reverse-engineer things from the changes for 
other architectures.)

> What I had in mind for the parameterization for pt-* was something that let
> have a single nptl/pt-crti.S file rather than each arch needing one.  That
> seems preferable, even though it makes the use of macros crti.S a bit more
> fiddly.  e.g., two macros PREINIT_FUNCTION (default to __gmon_start__) and
> PREINIT_FUNCTION_WEAK (default to 1).

I don't see any great advantage either way, and it seems better to me to 
do things simply until we have multiple architecture versions and can see 
better just how much is actually common between the ways they do things.  
If at that point it seems useful to have a single pt-crti.S - if there 
really is enough in common - it will be easy enough to do the refactoring 
without needing expertise in all architectures.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]