Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 18 May 2015 01:24:53 -0400
From: Rich Felker <>
Subject: Re: Potential cleanup work post-1.1.9

On Sat, May 02, 2015 at 06:48:18PM -0400, Rich Felker wrote:
> Just some ideas to jot down somewhere public:
> - Changing pthread_cancel signal handler to use mcontext_t members by
>   name (with the name provided by pthread_arch.h) instead of offset
>   macros and a fake overlaid array.

Not yet started.

> - Re-unifying x86_64 and x32 sigsetjmp.s by moving both saved values
>   to after the signal mask.

Not yet started. Should be trivial to do.

> - Providing inline atomics instead of runtime-switched for sh4a.

Patch under review; looks ok. More related cleanup work may follow.

> - Cleaning out cruft from struct __pthread, possibly condensing
>   multiple locks, packing small/boolean values into chars or
>   bitfields, etc.

Not yet started.

> - Evaluating whether it still makes sense to have struct __libc, or
>   all the members in it.

I got rid of the locale atomics in __libc that had no purpose but
avoiding TLS access. Nothing else there looks immediately removable,
but here's some analysis:

Presently, the following members are unconditionally needed no matter
what you link; there's no size benefit to factoring them out:

- can_do_threads
- secure
- auxv
- tls_size
- page_size
- global_locale

Of these, page_size could be made optional; it only needs to be stored
on archs that have variable PAGE_SIZE. Of these, global_locale is
pretty large and it would be nice if we could avoid it when not using
functions that depend on locale, but the main thread's __pthread
struct needs a pointer to its active locale and that's always
initialized at startup. And can_do_threads may be useless; it's only
probed correctly on i386 now anyway.

As for other members, here's a summary of where they're used (read,
not updated):

- threaded - sigaction, all functions which create FILEs, synccall
- threads_minus_1 - dynlink, malloc, synccall, __lock
- ofl_head and ofl_lock - fclose, all functions which create FILEs,
  stdio exit code

Of these, only the ofl stuff seems practical to move, and it would be
a small savings at best. So for this whole item, I think it makes more
sense to try to gradually phase out members that aren't useful rather
than doing any immediately overhaul or refactoring.

> - Eliminating float code in malloc on soft-float archs.

Moving forward with this requires a way to actually _know_ whether the
target is soft-float. Or we could require the arch to expose a
preferred function for this computation which could theoretically be
independent of whether it's hard- or soft-float.

> - Deduplicating atomic.h emulations of a_* in terms of a_cas, so that
>   archs where everything is emulated in terms of a_cas can just define
>   a_cas (much like how syscall.h and syscall_arch.h work now).

Prototype sent to list already.

> - Default atomics implementation for new archs to use (at least
>   initially) based on __sync_* builtins.

Prototype sent to list already.

> - Bits deduplication.

Still needs to be done. Big task.

> - Possibly eliminating preference of globals over TLS, at least when
>   it uglifies/enlarges/complexifies the code, for example use of
>   libc.threads_minus_1 to determine whether to skip locks and
>   libc.uselocale_cnt (instead of __pthread_self()->locale) in the

The worst offender, locale stuff, is already fixed. There are probably
some places still checking libc.threads_minus_1 or libc.threaded in
ways that don't actually benefit performance and produce uglier code,
but most places doing this actually have good reason to.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.