This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc
On Fri, 22 Aug 2008, Richard Henderson wrote:
> H.J. Lu wrote:
> > Can we declare that Linux/ia32 generates i486 insn by default?
>
> We the gcc team? I'm not sure. For now I'll say no.
>
> We an individual linux distributor? Certainly.
> In fact I would be surprised if i586 wasn't a
> decent minimum these days.
glibc has certainly required -march=i486 or greater for some time to build
for IA32; it will fail to link for -march=i386 because of missing atomic
operations. (And I hold that i686-* should mean -march=i686 default not
-mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64,
subject to --with-arch etc. in both cases.)
For the C++ interfaces in question, atomic and threading interfaces of
C++0x, and atomic and threading interfaces that may end up in C1x, I think
there are several cases to consider:
* Does the target support threads? If so, let's assume for now that GCC
will always know about what sort of threads are in use at configure time.
(In principle, generic bare-metal *-elf and *-eabi targets might allow
someone to swap in their choice of RTOS threading library, not present
when GCC is built, but I doubt that works well at present.)
* Does the CPU support atomic operations? If not, are there OS-provided
atomic operations that can be used as a fallback.
Then some cases are clear:
* If the CPU provides atomic operations, libstdc++ can use them,
independent of what OS may be in use.
* libstdc++ can only provide some threading interfaces if underlying OS
threads are available.
Now consider the case where no threads are available. The atomic
interfaces still need to be atomic if they are meant to be
async-signal-safe as well as thread-safe - are they? What about the
exception interfaces in question that use atomic operations internally?
Is atomicity needed for signal-safety here, or only for thread-safety?
Perhaps an implementation of the standard interfaces should be provided
even if it's not safe with signals in certain cases.
The most troublesome case is where there are threads but no adequate
atomic operations. (It's not clear to me that threads exist without *any*
atomic operations, but there may be cases without *enough* atomic
operations for libstdc++, e.g. ColdFire Linuxthreads using test-and-set
with no compare-and-exchange operation available.) In such a case certain
interfaces may not be providable in a thread-safe way without kernel help.
In a way it might be good to provide the interfaces in single-threaded
programs and somehow give a link failure if the interfaces are used in a
program linked with -lpthread - but I don't know how to do that.
One significant case is where atomic operations are available with kernel
help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed
patch to do the same for ARM GNU/Linux; both use kernel help in those
implementations, and more targets may do this in future. (It's been
proposed for HPPA. The ColdFire NPTL specification doesn't include
exporting such helpers from libgcc but they could easily be exported from
libc; the use of a vDSO may make exporting from libgcc harder.) The
GLIBCXX_ENABLE_ATOMIC_BUILTINS configure test looks like it's incorrect
for such cases, because it greps for __sync in a .s file and these targets
will have such __sync_* references resolved in libgcc. So on GNU/Linux
that configure test ought to be a link test.
If someone cares about -march=i386 GNU/Linux, they should provide
appropriate kernel helpers for atomic operations and make libgcc provide
the relevant functions, calling the helpers for i386 and written in
assembly for i486 and later (present for i486 and later only so the
interfaces provided by libgcc don't depend on the target). One form of
helpers would be emulation for the relevant instructions, in which case a
single assembly implementation could be used. Similarly, any other case
where there are threads but no native atomic operations can have helpers
provided in libgcc or libc using kernel support, and the libstdc++
configure test can be made to allow for this case.
--
Joseph S. Myers
joseph@codesourcery.com