Re: Fujitsu FR-V port (linuxthreads and nptl included)

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb  3, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:

> This patch is a first cut at contributing the glibc port to the
> Fujitsu FR-V architecture.  Support has been recently contributed to
> GCC, binutils and Linux.

> One of the distinguishing features of this port is that different
> sections of executables (and shared libraries) can be loaded anywhere
> in the address space.  The ABI was originally designed for uCLinux,
> where being able to relocate text and data segments by different
> amounts was essential to enable sharing of text segments among
> multiple processes.  The kernel passes to the executable's entry point
> a load map that maps vaddrs from the executable to memory addresses
> where they were mapped.  Ditto for an interpreter, if there is one.
> As a result, the concept of a base load address doesn't make sense,
> and an operation more complex than a simple addition is necessary to
> map a vaddr to a memory address.

> Although MMU Linux doesn't need the ability to relocate segments by
> different amounts to enable sharing of read-only segments, we figured
> FR-V already had a sufficient number of ABIs, and it made little sense
> to design yet another ABI for the Linux port, and being able to share
> some object code between frv-uclinux and frv-linux-gnu was certainly a
> plus.  Unfortunately, this means we had to turn a number of cases that
> relied on the existence of a single base load address per module into
> use of macros that, on all other ports, would still perform just an
> addition, but on frv-linux-gnu, would perform the more complex
> operation, even though all ld.so-loaded modules are guaranteed to be
> laid out in such a way that a regular base load address would do, and
> even kernel-loaded binaries are also very likely to be laid out in the
> traditional way.  We went for ABI compliance over efficiency in this
> case.  Too bad.

> The TLS ABI extension also has some novelties that required a bit of
> changes in common code.  One of the novelties is that __tls_get_addr()
> needs not be exported: instead of calling this function directly, code
> that may require dynamic TLS resolution loads the address of the
> function to call directly from the TLS descriptor.  This in turn
> enables load-time short-circuiting of potentially-expensive calls to
> __tls_get_addr() for variables that turn out to be in static TLS,
> enabling run-time optimization of the General Dynamic model to
> something pretty close to Initial Exec.  It also enables lazy handling
> of General Dynamic relocations referencing TLS variables, but this was
> not implemented yet.

> The other novelty is that the offset from the (biased) TLS pointer to
> the TLS block for the main executable, if there is one, is fixed by
> the ABI, which makes the Local Exec model extremely efficient.

This last bit, in turn, required a change to the TLS offset assignment
that can benefit other ports.  The existing TLS offset assignment code
assigns all offsets starting at zero, with the maximum alignment
required by the static TLS blocks.  Only then does it take
TLS_PRE_TCB_SIZE into account, rounding it up to the alignment of the
static TLS block, leaving whatever padding required by this operation
unused.

The change introduced to enable the offset from the TCB to the
executable TLS block to be constant enabled the pre-tcb size and
alignment requirements to be taken into account early, such that we
can use whatever padding they might require for TLS blocks.  This is
particularly useful in case some TLS segment has a very large
alignment requirement.

Also, if a TLS segment has alignment requirements no stricter than
those of the TCB, and the pre-TCB block has wider alignment
requirements than the TCB, the current code will not obtain the
correct alignment for the pre-TCB block.  This actually hits in
current code, because the TCB often has 16-byte alignment, and the
pre-TCB block is declared as requiring 32-byte alignment.

The change to implement this fix was implemented by adding an argument
to a function exported by ld.so to libpthread.so.  I'm not sure this
is regarded as an ABI break, since it's an internal function.  It
would be simple enough to introduce a separate entry point to obtain
the same information, or version the function so as to make
incompatibilities explicit.  Opinions?


The first patch below contains only the changes to generic code
required by the FR-V port.  Unfortunately a lot of recent code was
added without thought regarding ports maintained in the ports tree.
The pltenter/pltexit changes were particularly unfortunate in this
regard, and it would surely be possible to have introduced them in
such a way that a port would have to introduce a single header file
containing a few more macro definitions.  Oh, well...

The second patch below is for the ports/ tree, containing all the
changes to support frv-linux-gnu that didn't have to be made to
generic code.  Roland, may I check it in?

I'm a bit concerned that some of the changes to generic code (e.g.,
link.h, DL_RELOC_ADDR and the other macros required by the aggregate
type for l_addr) may face significant resistance to get in the tree,
so I'm trying to think of some way to include the patches for the
generic code required by FR-V in the ports/ tree, such that someone
who got ports/ could apply teh patch and then build the port.
Thoughts?

Attachment: glibc-frv-20050206.patch.bz2
Description: BZip2 compressed data

Attachment: glibc-frv-20050206-port.patch.bz2
Description: BZip2 compressed data

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}