This is the mail archive of the
mailing list for the glibc project.
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
> 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