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

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

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 5403 bytes --]

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 #2: glibc-frv-20050206.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 15264 bytes --]

[-- Attachment #3: glibc-frv-20050206-port.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 44941 bytes --]

[-- Attachment #4: Type: text/plain, Size: 188 bytes --]


-- 
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}

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

[Roland McGrath]

> 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?

For additions of new port-specific files to the ports repository, we don't
really have hard approval rules beyond the copyright assignment status.
You are on the ACL for the whole ports repository.  But, my opinion is that
we shouldn't put a port in there when there is no branch in the main
repository against which you can build it.  i.e., let's get any generic
changes worked out first.

elf.h changes for FR-V FDPIC and TLS

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 128 bytes --]

Roland asked me to break the patch up into smaller pieces.  Here goes
the first one, that doesn't depend on any other patches.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: glibc-frv-elf-h.patch --]
[-- Type: text/x-patch, Size: 1565 bytes --]

Index: ChangeLog
2004-11-10  Alexandre Oliva  <aoliva@redhat.com>

	* elf/elf.h (R_FRV_TLSDESC_VALUE, R_FRV_TLSOFF): New.

2004-02-27  Alexandre Oliva  <aoliva@redhat.com>

	* elf/elf.h (EM_CYGNUS_FRV, R_FRV_NONE, R_FRV_32, R_FRV_FUNCDESC,
	R_FRV_FUNCDESC_VALUE, EF_FRV_PIC, EF_FRV_FDPIC): New.

Index: elf/elf.h
--- elf/elf.h	2004-12-05 00:18:32.000000000 -0200
+++ elf/elf.h	2005-01-31 04:07:08.000000000 -0200
@@ -254,6 +254,9 @@
    pick large random numbers (0x8523, 0xa7f2, etc.) to minimize the
    chances of collision with official or non-GNU unofficial values.  */
 
+/* Fujitsu FR-V.  */
+#define EM_CYGNUS_FRV	0x5441
+
 #define EM_ALPHA	0x9026
 
 /* Legal values for e_version (version).  */
@@ -1137,6 +1140,24 @@
 /* Keep this the last entry.  */
 #define R_386_NUM	   38
 
+/* FR-V specific definitions.  */
+#define R_FRV_NONE		0	/* No reloc.  */
+#define R_FRV_32		1	/* Direct 32 bit.  */
+/* Canonical function descriptor address.  */
+#define R_FRV_FUNCDESC		14
+/* Private function descriptor initialization.  */
+#define R_FRV_FUNCDESC_VALUE	18
+/* TLS descriptor initialization.  First word points to an entry
+   point; second words holds an argument that can either be a
+   Thread-Pointer offset, for Static TLS, or a full TLS descriptor,
+   for Dynamic TLS.  */
+#define R_FRV_TLSDESC_VALUE	26
+/* Biased Thread-Pointer offset.  */
+#define R_FRV_TLSOFF		36
+
+#define EF_FRV_PIC   0x00000100
+#define EF_FRV_FDPIC 0x00008000
+
 /* SUN SPARC specific definitions.  */
 
 /* Legal values for ST_TYPE subfield of st_info (symbol type).  */

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
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}

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

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Since GCC 3.4 is the first release to support shared libs for FR-V,
the symbols exported by libgcc are marked as GCC_3.4.  Since glibc
brings them into libc.so, we have to export them.

It might be worth noting that the FR-V ABI specifies different names
for the functions traditionally exported by libgcc, and GCC actually
emits references to these alternate names, that are thus brought into
libc.so from libgcc.a.

I couldn't find any way to introduce this as part of the ports
infrastructure, unfortunately.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: glibc-frv-versions-def.patch --]
[-- Type: text/x-patch, Size: 343 bytes --]

Index: ChangeLog
2004-02-27  Alexandre Oliva  <aoliva@redhat.com>

	* Versions.def: Add GCC_3.4 to libc.

Index: Versions.def
--- Versions.def	2004-04-10 02:54:01.000000000 -0300
+++ Versions.def	2004-03-19 17:01:27.000000000 -0300
@@ -26,6 +26,7 @@
 %ifdef EXPORT_UNWIND_FIND_FDE
   GCC_3.0
 %endif
+  GCC_3.4
   GLIBC_PRIVATE
 }
 libcrypt {

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
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}

Introduce TRY_STATIC_TLS macro, used in FR-V

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

This patch introduces TRY_STATIC_TLS, a macro that can be used to test
whether a module's TLS block is in the static TLS block, or can be
assigned there.

If you use a sufficiently-recent version of GCC and never call
TRY_STATIC_TLS, the new static intermediate function will be fully
inlined into the single caller, without any performance hit
whatsoever.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: glibc-try-allocate-static-tls.patch --]
[-- Type: text/x-patch, Size: 1746 bytes --]

Index: ChangeLog
2004-11-10  Alexandre Oliva  <aoliva@redhat.com>

	* elf/dl-reloc.c (_dl_try_allocate_static_tls): Move out of...
	(_dl_allocate_static_tls): ... this.
	(TRY_STATIC_TLS): New.

Index: elf/dl-reloc.c
--- elf/dl-reloc.c	2005-01-22 16:18:28.000000000 -0200
+++ elf/dl-reloc.c	2005-01-31 04:37:42.000000000 -0200
@@ -44,16 +44,14 @@
    This function intentionally does not return any value but signals error
    directly, as static TLS should be rare and code handling it should
    not be inlined as much as possible.  */
-void
-internal_function __attribute_noinline__
-_dl_allocate_static_tls (struct link_map *map)
+static int
+_dl_try_allocate_static_tls (struct link_map *map)
 {
   /* If the alignment requirements are too high fail.  */
   if (map->l_tls_align > GL(dl_tls_static_align))
     {
     fail:
-      _dl_signal_error (0, map->l_name, NULL, N_("\
-cannot allocate memory in static TLS block"));
+      return -1;
     }
 
 # if TLS_TCB_AT_TP
@@ -107,6 +105,19 @@
     }
   else
     map->l_need_tls_init = 1;
+
+  return 0;
+}
+
+void
+internal_function __attribute_noinline__
+_dl_allocate_static_tls (struct link_map *map)
+{
+  if (_dl_try_allocate_static_tls (map))
+    {
+      _dl_signal_error (0, map->l_name, NULL, N_("\
+cannot allocate memory in static TLS block"));
+    }
 }
 
 /* Initialize static TLS area and DTV for current (only) thread.
@@ -258,6 +269,10 @@
 	_dl_allocate_static_tls (sym_map);				      \
     } while (0)
 
+#define TRY_STATIC_TLS(map, sym_map)					      \
+    (__builtin_expect ((sym_map)->l_tls_offset != NO_TLS_OFFSET, 1)	      \
+     || _dl_try_allocate_static_tls (sym_map) == 0)
+
 #include "dynamic-link.h"
 
     ELF_DYNAMIC_RELOCATE (l, lazy, consider_profiling);

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
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}

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

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

No way.  I'm not willing to be the slave of these embedded idiots with
their gazillion ports.  This data must be part of the add-ons.  If the
support does not exist, write it.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

FR-V TLS macros

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 39 bytes --]

No need to explain this one, I think.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: glibc-frv-tls-macros.patch --]
[-- Type: text/x-patch, Size: 2217 bytes --]

Index: ChangeLog
2004-11-10  Alexandre Oliva  <aoliva@redhat.com>

	* elf/tls-macros.h: Add FR-V section.

Index: elf/tls-macros.h
--- elf/tls-macros.h	2004-07-08 01:46:11.000000000 -0300
+++ elf/tls-macros.h	2005-01-31 04:07:09.000000000 -0200
@@ -731,6 +731,61 @@
       __result;  \
   })
 
+#elif defined __FRV_FDPIC__
+
+/* gr15 isn't a fixed register.  We could code an asm function that
+   copied the incoming gr15 to gr8 and be done with it, instead of
+   loading it from the function's own function descriptor, but this is
+   so easy to code in C that it will do.  */
+static long __get_gr15(void) {
+  static struct funcdesc {
+    long ip, gp;
+  } const *fd = (const struct funcdesc *)__get_gr15;
+  return fd->gp;
+}
+
+/* FR-V Local Executable TLS access.  */
+#  define TLS_LE(x) \
+  ({  char * __result;  \
+      register long __tp asm ("gr29"); \
+      asm ("sethi.p #tlsmoffhi(" #x "), %0\n\t" \
+	   "setlo #tlsmofflo(" #x "), %0" : "=r" (__result)); \
+      (int *)(__result + __tp); \
+   })
+
+/* FR-V Initial Executable TLS access.  */
+#  define TLS_IE(x) \
+  ({  char * __result;  \
+      register long __tp asm ("gr29"); \
+      register long __pic asm ("gr15") = __get_gr15(); \
+      asm ("ldi @(%1, #gottlsoff12(" #x ")), %0" : "=r" (__result) \
+	   : "r" (__pic)); \
+      (int *)(__result + __tp); \
+   })
+
+/* FR-V Local Dynamic TLS access.  */
+#  define TLS_LD(x) \
+  ({  char * __result;  \
+      register long __tp asm ("gr29"); \
+      register long __pic asm ("gr15") = __get_gr15(); \
+      long __modbase;  \
+      asm ("call #gettlsoff(0)" : "=D09" (__modbase)) \
+	   : "r" (__pic) : "gr8"); \
+      asm ("sethi.p #tlsmoffhi(" #x "), %0\n\t" \
+	   "setlo #tlsmofflo(" #x "), %0" : "=r" (__result)); \
+      (int *)(__result + __modbase + __tp); \
+   })
+
+/* FR-V General Dynamic TLS access.  */
+#  define TLS_GD(x) \
+  ({  char * __result;  \
+      register long __tp asm ("gr29"); \
+      register long __pic asm ("gr15") = __get_gr15(); \
+      asm ("call #gettlsoff(" #x ")" : "=D09" (__result) \
+	   : "r" (__pic) : "gr8"); \
+      (int *)(__result + __tp); \
+  })
+    
 #else
 # error "No support for this architecture so far."
 #endif

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
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}

Re: Introduce TRY_STATIC_TLS macro, used in FR-V

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

No.  No changes like this to generic code.  There is no need whatsoever.
  If some moron "designed" TLS on an arch incorrectly, add an
_dl_catch_error block to catch the _dl_signal_error call and handle it.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: FR-V TLS macros

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

And once again, no.  We are not going to add endless streams of #if
blocks.  Develop a generic method for add-ons and use it.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

FR-V PLT audit

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

The FR-V port doesn't support profiling (yet?), and so we never
actually lay out the structure that pltenter/exit functions rely on,
but it looks like we must define them anyway.  Here are the
definitions.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: glibc-frv-plt-audit.patch --]
[-- Type: text/x-patch, Size: 1754 bytes --]

Index: ChangeLog
2005-01-26  Alexandre Oliva  <aoliva@redhat.com>

	* sysdeps/generic/ldsodefs.h (struct audit_ifaces): Add frv
	members.
	* elf/tst-auditmod1.c: Add frv macros.

Index: sysdeps/generic/ldsodefs.h
--- sysdeps/generic/ldsodefs.h	2005-02-01 02:58:10.000000000 -0200
+++ sysdeps/generic/ldsodefs.h	2005-01-31 05:03:10.000000000 -0200
@@ -195,6 +195,8 @@
 struct La_s390_64_retval;
 struct La_ia64_regs;
 struct La_ia64_retval;
+struct La_frv_regs;
+struct La_frv_retval;
 
 struct audit_ifaces
 {
@@ -251,6 +253,10 @@
 				     uintptr_t *, struct La_ia64_regs *,
 				     unsigned int *, const char *name,
 				     long int *framesizep);
+    Elf32_Addr (*frv_gnu_pltenter) (Elf32_Sym *, unsigned int, uintptr_t *,
+				    uintptr_t *, struct La_frv_regs *,
+				    unsigned int *, const char *name,
+				    long int *framesizep);
   };
   union
   {
@@ -294,6 +300,9 @@
 				      uintptr_t *,
 				      const struct La_ia64_regs *,
 				      struct La_ia64_retval *, const char *);
+    unsigned int (*frv_gnu_pltexit) (Elf32_Sym *, unsigned int, uintptr_t *,
+				     uintptr_t *, const struct La_frv_regs *,
+				     struct La_frv_retval *, const char *);
   };
   unsigned int (*objclose) (uintptr_t *);
 
Index: elf/tst-auditmod1.c
--- elf/tst-auditmod1.c	2005-02-01 02:58:04.000000000 -0200
+++ elf/tst-auditmod1.c	2005-01-31 05:01:50.000000000 -0200
@@ -162,6 +162,12 @@
 # define La_regs La_ia64_regs
 # define La_retval La_ia64_retval
 # define int_retval lrv_r8
+#elif defined __FRV_FDPIC__
+# define pltenter la_frv_gnu_pltenter
+# define pltexit la_frv_gnu_pltexit
+# define La_regs La_frv_regs
+# define La_retval La_frv_retval
+# define int_retval lrv_gr8
 #else
 # error "architecture specific code needed"
 #endif

[-- Attachment #3: Type: text/plain, Size: 189 bytes --]



-- 
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}

FR-V set_tid_address syscall number

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 96 bytes --]

This is defined in kernel headers, but since other ports define this,
I thought I would too...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: glibc-frv-set-tid-address.patch --]
[-- Type: text/x-patch, Size: 480 bytes --]

Index: ChangeLog
2004-11-10  Alexandre Oliva  <aoliva@redhat.com>

	* init.c (__NR_set_tid_address) <__FRV_FDPIC__>: Define.

Index: nptl/init.c
--- nptl/init.c	2005-01-06 16:39:24.000000000 -0200
+++ nptl/init.c	2005-01-31 04:47:41.000000000 -0200
@@ -50,6 +50,8 @@
 # define __NR_set_tid_address	232
 #elif defined __sparc__
 # define __NR_set_tid_address	166
+#elif defined __FRV_FDPIC__
+# define __NR_set_tid_address	258
 #else
 # error "define __NR_set_tid_address"
 #endif

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
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}

using pre-TCB padding for static TLS

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

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

>> 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?

This patch has the changes described above.  It introduces two new
macros to control the behavior of dl-tls: TLS_PRE_TCB_ALIGN (that
should probably be set for all DTV_AT_TP ports) and
TLS_FIXED_EXEC_TCB_OFFSET_P (that is only used on FR-V).  I could
probably split these out into a separate patch, but they're so small
and entangled with the current patch that I didn't think it was worth
the trouble.

It also introduces TLS_STATIC_RESERVED_SIZE, defined as an alias to
TLS_PRE_TCB_SIZE unless TLS_FIXED_EXEC_TCB_OFFSET_P, in which case the
offset may have to vary, and is thus defined as a macro.

_dl_get_tls_static_info() gets a new argument that libc uses to
communicate the amount of space reserved for the pre-tcb block, such
that nptl can take it into account when allocating space for the TLS
block.  I have a few backward-compatibility concerns regarding this
change, but since it's an internal function, I thought this might be
ok.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: glibc-use-pre-tcb-padding.patch --]
[-- Type: text/x-patch, Size: 11004 bytes --]

Index: ChangeLog
2005-02-03  Alexandre Oliva  <aoliva@redhat.com>

	* sysdeps/generic/dl-tls.c (_dl_determine_tlsoffset): Update
	executable sanity check in fixed exec tcb offset mode.

2004-11-22  Alexandre Oliva  <aoliva@redhat.com>

	* sysdeps/generic/dl-tls.c (_dl_determine_tlsoffset): Handle
	executables with stricter alignment requirements than the TCB.
	(_dl_get_tls_static_info): Add reservedp argument.
	(_dl_allocate_tls_storage): Add total reserved space to the size.
	(_dl_deallocate_tls): Subtract it to get the original pointer.
	* sysdeps/generic/ldsodefs.h (_dl_tls_static_tcb_offset): New.
	(TLS_STATIC_RESERVED_SIZE): Define.
	(_dl_get_tls_static_info): Adjust prototype.
	* sysdeps/generic/libc-tls.c (_dl_tls_static_tcb_offset): Define.
	(__libc_setup_tls): Set it and use it.

2004-11-20  Alexandre Oliva  <aoliva@redhat.com>

	* sysdeps/generic/dl-tls.c (_dl_determine_tlsoffset): Fix typo and
	thinko in executable's TLS alignment check.

2004-11-10  Alexandre Oliva  <aoliva@redhat.com>

	* sysdeps/generic/dl-tls.c (_dl_determine_tlsoffset): Honor
	TLS_FIXED_EXEC_TCB_OFFSET.  Take TLS_PRE_TCB_SIZE into account for
	alignment.
	(_dl_allocate_tls_storage): Assume _dl_determine_tlsoffset took
	TLS_PRE_TCB_SIZE's alignment requirements into account.
	(_dl_deallocate_tls): Likewise.
	(_dl_allocate_tls_init): Fix typo in comment.

Index: nptl/ChangeLog
2004-11-22  Alexandre Oliva  <aoliva@redhat.com>

	* allocatestack.c: Assume __static_tls_size is sufficiently
	aligned.
	* init.c (__pthread_initialize_minimal_internal): Make it so,
	taking reserved space into account.

Index: sysdeps/generic/dl-tls.c
--- sysdeps/generic/dl-tls.c	2005-01-22 16:18:32.000000000 -0200
+++ sysdeps/generic/dl-tls.c	2005-02-03 11:14:16.000000000 -0200
@@ -124,6 +124,8 @@
   size_t max_align = TLS_TCB_ALIGN;
   size_t freetop = 0;
   size_t freebottom = 0;
+  size_t offset;
+  size_t reserved __attribute__ ((unused)) = 0;
 
   /* The first element of the dtv slot info list is allocated.  */
   assert (GL(dl_tls_dtv_slotinfo_list) != NULL);
@@ -163,7 +165,7 @@
 
 # if TLS_TCB_AT_TP
   /* We simply start with zero.  */
-  size_t offset = 0;
+  offset = 0;
 
   for (size_t cnt = 0; slotinfo[cnt].map != NULL; ++cnt)
     {
@@ -209,8 +211,15 @@
   GL(dl_tls_static_size) = (roundup (offset + TLS_STATIC_SURPLUS, max_align)
 			    + TLS_TCB_SIZE);
 # elif TLS_DTV_AT_TP
+  reserved = TLS_PRE_TCB_SIZE;
+
   /* The TLS blocks start right after the TCB.  */
-  size_t offset = TLS_TCB_SIZE;
+#  ifdef TLS_PRE_TCB_ALIGN
+  max_align = MAX (max_align, TLS_PRE_TCB_ALIGN);
+#  endif
+  offset = reserved + TLS_TCB_SIZE;
+  assert ((TLS_PRE_TCB_SIZE & (TLS_TCB_ALIGN - 1)) == 0);
+  assert ((offset & (max_align - 1)) == 0);
 
   for (size_t cnt = 0; slotinfo[cnt].map != NULL; ++cnt)
     {
@@ -218,9 +227,19 @@
 
       size_t firstbyte = (-slotinfo[cnt].map->l_tls_firstbyte_offset
 			  & (slotinfo[cnt].map->l_tls_align - 1));
+
       size_t off;
       max_align = MAX (max_align, slotinfo[cnt].map->l_tls_align);
 
+#  if TLS_FIXED_EXEC_TCB_OFFSET_P
+      if (slotinfo[cnt].map->l_type == lt_executable)
+	{
+	  assert (cnt == 0 && firstbyte == 0);
+	  reserved = roundup (offset, slotinfo[cnt].map->l_tls_align)
+	    - TLS_TCB_SIZE;
+	}
+#  endif
+
       if (slotinfo[cnt].map->l_tls_blocksize <= freetop - freebottom)
 	{
 	  off = roundup (freebottom, slotinfo[cnt].map->l_tls_align);
@@ -228,7 +247,8 @@
 	    off += slotinfo[cnt].map->l_tls_align;
 	  if (off + slotinfo[cnt].map->l_tls_blocksize - firstbyte <= freetop)
 	    {
-	      slotinfo[cnt].map->l_tls_offset = off - firstbyte;
+	      slotinfo[cnt].map->l_tls_offset = off - firstbyte
+		- reserved;
 	      freebottom = (off + slotinfo[cnt].map->l_tls_blocksize
 			    - firstbyte);
 	      continue;
@@ -239,7 +259,7 @@
       if (off - offset < firstbyte)
 	off += slotinfo[cnt].map->l_tls_align;
 
-      slotinfo[cnt].map->l_tls_offset = off - firstbyte;
+      slotinfo[cnt].map->l_tls_offset = off - firstbyte - reserved;
       if (off - firstbyte - offset > freetop - freebottom)
 	{
 	  freebottom = offset;
@@ -249,13 +269,17 @@
       offset = off + slotinfo[cnt].map->l_tls_blocksize - firstbyte;
     }
 
-  GL(dl_tls_static_used) = offset;
+  GL(dl_tls_static_used) = offset - reserved;
   GL(dl_tls_static_size) = roundup (offset + TLS_STATIC_SURPLUS,
-				    TLS_TCB_ALIGN);
+				    TLS_TCB_ALIGN) - reserved;
 # else
 #  error "Either TLS_TCB_AT_TP or TLS_DTV_AT_TP must be defined"
 # endif
 
+#  if TLS_FIXED_EXEC_TCB_OFFSET_P
+  GL(dl_tls_static_tcb_offset) = reserved;
+#  endif
+
   /* The alignment requirement for the static TLS block.  */
   GL(dl_tls_static_align) = max_align;
 }
@@ -326,10 +350,15 @@
 /* Get size and alignment requirements of the static TLS block.  */
 void
 internal_function
-_dl_get_tls_static_info (size_t *sizep, size_t *alignp)
+_dl_get_tls_static_info (size_t *sizep, size_t *alignp, size_t *reservedp)
 {
   *sizep = GL(dl_tls_static_size);
   *alignp = GL(dl_tls_static_align);
+#if TLS_DTV_AT_TP
+  *reservedp = TLS_STATIC_RESERVED_SIZE;
+#else
+  *reservedp = 0;
+#endif
 }
 
 
@@ -343,9 +372,10 @@
 # if TLS_DTV_AT_TP
   /* Memory layout is:
      [ TLS_PRE_TCB_SIZE ] [ TLS_TCB_SIZE ] [ TLS blocks ]
-			  ^ This should be returned.  */
-  size += (TLS_PRE_TCB_SIZE + GL(dl_tls_static_align) - 1)
-	  & ~(GL(dl_tls_static_align) - 1);
+			  ^ This should be returned.
+     size and alignment are already set up such that alignment is
+     satisfied if we just add TLS_PRE_TCB_SIZE.  */
+  size += TLS_STATIC_RESERVED_SIZE;
 # endif
 
   /* Allocate a correctly aligned chunk of memory.  */
@@ -499,8 +529,7 @@
       tcb -= GL(dl_tls_static_size) - TLS_TCB_SIZE;
 # elif TLS_DTV_AT_TP
       /* Back up the TLS_PRE_TCB_SIZE bytes.  */
-      tcb -= (TLS_PRE_TCB_SIZE + GL(dl_tls_static_align) - 1)
-	     & ~(GL(dl_tls_static_align) - 1);
+      tcb -= TLS_STATIC_RESERVED_SIZE;
 # endif
       free (tcb);
     }
@@ -670,7 +699,7 @@
 		 pool.  */
 	      if (! dtv[modid].pointer.is_static
 		  && dtv[modid].pointer.val != TLS_DTV_UNALLOCATED)
-		/* Note that free is called for NULL is well.  We
+		/* Note that free is called for NULL as well.  We
 		   deallocate even if it is this dtv entry we are
 		   supposed to load.  The reason is that we call
 		   memalign and not malloc.  */
Index: sysdeps/generic/ldsodefs.h
--- sysdeps/generic/ldsodefs.h	2005-02-01 02:58:10.000000000 -0200
+++ sysdeps/generic/ldsodefs.h	2005-01-31 05:03:10.000000000 -0200
@@ -448,6 +448,15 @@
   EXTERN size_t _dl_tls_static_used;
   /* Alignment requirement of the static TLS block.  */
   EXTERN size_t _dl_tls_static_align;
+#if TLS_FIXED_EXEC_TCB_OFFSET_P
+  /* The location of the TCB past a static_align-aligned address in
+     order for the TLS block of the executable to satisfy its
+     alignment requirements and be at a fixed offset from the TCB.  */
+  EXTERN size_t _dl_tls_static_tcb_offset;
+# define TLS_STATIC_RESERVED_SIZE GL(dl_tls_static_tcb_offset)
+#else
+# define TLS_STATIC_RESERVED_SIZE TLS_PRE_TCB_SIZE
+#endif
 
 /* Number of additional entries in the slotinfo array of each slotinfo
    list element.  A large number makes it almost certain take we never
@@ -988,7 +997,8 @@
 rtld_hidden_proto (_dl_allocate_tls)
 
 /* Get size and alignment requirements of the static TLS block.  */
-extern void _dl_get_tls_static_info (size_t *sizep, size_t *alignp)
+extern void _dl_get_tls_static_info (size_t *sizep, size_t *alignp,
+				     size_t *reservedp)
      internal_function;
 
 extern void _dl_allocate_static_tls (struct link_map *map)
Index: sysdeps/generic/libc-tls.c
--- sysdeps/generic/libc-tls.c	2005-01-22 16:18:32.000000000 -0200
+++ sysdeps/generic/libc-tls.c	2005-01-31 04:48:46.000000000 -0200
@@ -67,6 +67,12 @@
 size_t _dl_tls_static_used;
 /* Alignment requirement of the static TLS block.  */
 size_t _dl_tls_static_align;
+#if TLS_FIXED_EXEC_TCB_OFFSET_P
+/* Space reserved in a TLS block before the TCB.  Used for
+   TLS_PRE_TCB_SIZE plus any padding required to align the
+   executable's TLS block.  */
+size_t _dl_tls_static_tcb_offset;
+#endif
 
 /* Generation counter for the dtv.  */
 size_t _dl_tls_generation;
@@ -161,7 +167,11 @@
   tcb_offset = roundup (tcbsize, align ?: 1);
   tlsblock = __sbrk (tcb_offset + memsz + max_align
 		     + TLS_PRE_TCB_SIZE + GL(dl_tls_static_size));
-  tlsblock += TLS_PRE_TCB_SIZE;
+#  if TLS_FIXED_EXEC_TCB_OFFSET_P
+  GL(dl_tls_static_tcb_offset) = roundup (TLS_PRE_TCB_SIZE + TLS_TCB_SIZE,
+					  max_align) - TLS_TCB_SIZE;
+#  endif
+  tlsblock += TLS_STATIC_RESERVED_SIZE + TLS_TCB_SIZE;
 # else
   /* In case a model with a different layout for the TCB and DTV
      is defined add another #elif here and in the following #ifs.  */
@@ -182,8 +192,9 @@
 			       - roundup (memsz, align ?: 1));
   static_map.l_tls_offset = roundup (memsz, align ?: 1);
 # elif TLS_DTV_AT_TP
-  static_dtv[2].pointer.val = (char *) tlsblock + tcb_offset;
+  static_dtv[2].pointer.val = (char *) tlsblock;
   static_map.l_tls_offset = tcb_offset;
+  tlsblock -= tcb_offset;
 # else
 #  error "Either TLS_TCB_AT_TP or TLS_DTV_AT_TP must be defined"
 # endif
Index: nptl/allocatestack.c
--- nptl/allocatestack.c	2005-01-22 16:18:31.000000000 -0200
+++ nptl/allocatestack.c	2005-01-31 04:47:41.000000000 -0200
@@ -319,8 +319,8 @@
 	    & __static_tls_align_m1;
       assert (size > adj + TLS_TCB_SIZE);
 #elif TLS_DTV_AT_TP
-      adj = ((uintptr_t) attr->stackaddr - __static_tls_size)
-	    & __static_tls_align_m1;
+      adj = ((uintptr_t) attr->stackaddr
+	    & __static_tls_align_m1);
       assert (size > adj);
 #endif
 
@@ -469,9 +469,9 @@
 #if TLS_TCB_AT_TP
 	  pd = (struct pthread *) ((char *) mem + size - coloring) - 1;
 #elif TLS_DTV_AT_TP
-	  pd = (struct pthread *) ((((uintptr_t) mem + size - coloring
-				    - __static_tls_size)
+	  pd = (struct pthread *) ((((uintptr_t) mem + size - coloring)
 				    & ~__static_tls_align_m1)
+				   - __static_tls_size
 				   - TLS_PRE_TCB_SIZE);
 #endif
 
Index: nptl/init.c
--- nptl/init.c	2005-01-06 16:39:24.000000000 -0200
+++ nptl/init.c	2005-01-31 04:47:41.000000000 -0200
@@ -304,15 +304,17 @@
 
   /* Get the size of the static and alignment requirements for the TLS
      block.  */
-  size_t static_tls_align;
-  _dl_get_tls_static_info (&__static_tls_size, &static_tls_align);
+  size_t static_tls_align, static_tls_reserve = 0;
+  _dl_get_tls_static_info (&__static_tls_size, &static_tls_align,
+			   &static_tls_reserve);
 
   /* Make sure the size takes all the alignments into account.  */
   if (STACK_ALIGN > static_tls_align)
     static_tls_align = STACK_ALIGN;
   __static_tls_align_m1 = static_tls_align - 1;
 
-  __static_tls_size = roundup (__static_tls_size, static_tls_align);
+  __static_tls_size = roundup (__static_tls_size + static_tls_reserve,
+			       static_tls_align) - static_tls_reserve;
 
 #ifdef SHARED
   /* Transfer the old value from the dynamic linker's internal location.  */

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
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}

Re: Introduce TRY_STATIC_TLS macro, used in FR-V

[Alexandre Oliva]

On Feb  9, 2005, Ulrich Drepper <drepper@redhat.com> wrote:

> No.  No changes like this to generic code.  There is no need whatsoever.
>   If some moron "designed" TLS on an arch incorrectly, add an
> _dl_catch_error block to catch the _dl_signal_error call and handle it.

Just because another moron couldn't think of a better way to design
it?  How stupid is this going to get?

-- 
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}

Re: FR-V set_tid_address syscall number

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

No.  These were added just for the time when the kernel feature was too
new.  The #ifs must simply go.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: using pre-TCB padding for static TLS

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

>
> 	* sysdeps/generic/dl-tls.c (_dl_determine_tlsoffset): Update
> 	executable sanity check in fixed exec tcb offset mode.

What part of "ports use their own sysdeps tree" don't you understand?
Define your own dl-tls.c file for this moronic port which cannot follow
common practice.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: FR-V PLT audit

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 156 bytes --]

And again, define something to move this into the port.

--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: FR-V TLS macros

[Alexandre Oliva]

On Feb  9, 2005, Ulrich Drepper <drepper@redhat.com> wrote:

> And once again, no.  We are not going to add endless streams of #if
> blocks.

Then why did you add them in the first place?

> Develop a generic method for add-ons and use it.

It looks like you're going to reject anything I come up with on
grounds of prejudice.  I don't feel like wasting my time trying to
figure out some way to fix stuff you broke just to have you reject it
with a stupid reason.

Here's my design suggestion: include a sysdeps header file any time
you find yourself adding streams of machine-specific defines.  Then
port maintainers will even get saner build errors.

If I make such a change to this file and to that oh-so-beautiful
stream of multiple ifdefs you ``designed´´ to introduce plt audit,
what reason are you going to use to reject it?

-- 
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}

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

[Alexandre Oliva]

On Feb  9, 2005, Ulrich Drepper <drepper@redhat.com> wrote:

> No way.  I'm not willing to be the slave of these embedded idiots with
> their gazillion ports.  This data must be part of the add-ons.  If the
> support does not exist, write it.

So, I can add an entry to ports/Versions.def and it will just work.
However, I'd like to make it specific to the FR-V port if possible.
Unfortunately, Versions.v is preprocessed with -undef, so
__FRV_FDPIC__ isn't defined.  Any chance we could take out this
-undef, or must I come up with some more convoluted solution?

Or can I just keep GCC_3.4 unconditional in ports/Versions.def, such
that any other ports willing to use them can without further hassle
can, and those that don't won't be affected in any way AFAICT?

I.e., does this patch actually impact negatively any other port, or
are you just going on your crusade against new ports and being a pain
as usual?

-- 
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}

Re: using pre-TCB padding for static TLS

[Alexandre Oliva]

On Feb  9, 2005, Ulrich Drepper <drepper@redhat.com> wrote:

>> 
>> * sysdeps/generic/dl-tls.c (_dl_determine_tlsoffset): Update
>> executable sanity check in fixed exec tcb offset mode.

> What part of "ports use their own sysdeps tree" don't you understand?

What part of `all DTV_AT_TP ports are broken, and could also reduce
static TLS wastage' don't you understand?

The machine-specific portion of this change is just a few lines, that
other ports could and should take advantage of.  Keeping them hidden
elsewhere will do nobody any good.

> Define your own dl-tls.c file for this moronic port which cannot follow
> common practice.

How painful can it be to watch someone else improve on a poor design
of yours and regret not having thought of it?

It's almost funny to watch you promoting new and better ways to do
things when you come up with them, and then classify as moronic the
better ways to do things that you didn't think of.  You should be
ashamed.

-- 
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}

Re: FR-V set_tid_address syscall number

[Alexandre Oliva]

On Feb  9, 2005, Ulrich Drepper <drepper@redhat.com> wrote:

> No.  These were added just for the time when the kernel feature was too
> new.  The #ifs must simply go.

Sounds good to me, patch withdrawn.  Should I even bother to post a
patch to remove the others?

-- 
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}

Re: FR-V PLT audit

[Richard Henderson]

On Wed, Feb 09, 2005 at 03:12:02AM -0800, Ulrich Drepper wrote:
> And again, define something to move this into the port.

You must admit that this part is exceedingly ugly to begin with.
I think you're being unfair to Alex making him cleanup your mess.


r~

Re: FR-V PLT audit

[Roland McGrath]

Indeed, what is the motivation for using an anonymous union rather than
each sysdeps/CPU/ldsodefs.h defining a macro for the appropriate thing?

Re: FR-V PLT audit

[Richard Henderson]

On Wed, Feb 09, 2005 at 10:43:48PM -0800, Roland McGrath wrote:
> Indeed, what is the motivation for using an anonymous union rather than
> each sysdeps/CPU/ldsodefs.h defining a macro for the appropriate thing?

Or any macros at all?  What's so special about the argument and result
registers that require structure names to differ by target?  We don't
do that for sigcontext, or jmp_buf.


r~

Re: FR-V PLT audit

[Roland McGrath]

> On Wed, Feb 09, 2005 at 10:43:48PM -0800, Roland McGrath wrote:
> > Indeed, what is the motivation for using an anonymous union rather than
> > each sysdeps/CPU/ldsodefs.h defining a macro for the appropriate thing?
> 
> Or any macros at all?  What's so special about the argument and result
> registers that require structure names to differ by target?  We don't
> do that for sigcontext, or jmp_buf.

I think the intent there was just that the structure member names match the
names of the entry point symbols in the audit library.  The reason the API
for those functions uses a different name for each CPU is that the
signature and what you need to know to implement it also differ for each
CPU.  It is not something that is ever used generically like sigcontext and
jmp_buf are.  

Re: FR-V PLT audit

[Richard Henderson]

On Wed, Feb 09, 2005 at 11:19:26PM -0800, Roland McGrath wrote:
> I think the intent there was just that the structure member names match the
> names of the entry point symbols in the audit library.  The reason the API
> for those functions uses a different name for each CPU is that the
> signature and what you need to know to implement it also differ for each
> CPU.  It is not something that is ever used generically like sigcontext and
> jmp_buf are.  

Possibly, but in practice it seems like you'll wind up with a lot
of commonality in the actual implementations, and thence a lot of
macro hackery to try to cope with the gratuitous name changes.

It's not like you'll have mips and i386 versions in the same binary
in the first place, and therefore no need to make sure that the two
are in separate namespaces.


r~

Re: FR-V PLT audit

[Roland McGrath]

> It's not like you'll have mips and i386 versions in the same binary
> in the first place, and therefore no need to make sure that the two
> are in separate namespaces.

That's not the concern.  The concern is that one could try to compile an
audit library on a different platform and have it seem like it's ok because
the signature happens to match, but in fact the audit library's
pltenter/pltexit functions have not been ported properly to the machine you
are compiling for.  Since those implementations are always
machine-specific, having the API distinguish the machine in the names makes
sure you have considered the target machine specifically.

Re: FR-V PLT audit

[Richard Henderson]

On Thu, Feb 10, 2005 at 01:03:22AM -0800, Roland McGrath wrote:
> That's not the concern.  The concern is that one could try to compile an
> audit library on a different platform and have it seem like it's ok because
> the signature happens to match, but in fact the audit library's
> pltenter/pltexit functions have not been ported properly to the machine you
> are compiling for.  Since those implementations are always
> machine-specific, having the API distinguish the machine in the names makes
> sure you have considered the target machine specifically.

Given that any non-trivial audit library will be looking at the 
arguments, and the structure member names are different for each
platform, what do you think the odds are that the library will
compile when configured incorrectly?

I'm thinking pretty low, myself.


r~

Re: FR-V TLS macros

[Roland McGrath]

> No need to explain this one, I think.

I've tweaked it so you can provide a sysdeps/cpu/tls-macros.h file.
Please update your add-on ports.


Thanks,
Roland

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

[Roland McGrath]

> So, I can add an entry to ports/Versions.def and it will just work.

No top-level ports/ file should contain anything specific like this.  
Not just not anything cpu-specific, but really anything but the build
boilerplate of being an add-on.  Any real part of the port sources should
be in a sysdeps directory.  As we've already seen, this hasn't been
possible before for all things, and making it so requires some changes.
As I've said, I'll help when such changes are necessary, but it'll start
when you propose something that solves your problem while meeting the
constraints I've set.

> Unfortunately, Versions.v is preprocessed with -undef, so
> __FRV_FDPIC__ isn't defined.  Any chance we could take out this
> -undef, or must I come up with some more convoluted solution?

I think that's to counteract predefined -Di686 and the like making trouble.
So, probably not.  


Thanks,
Roland

Re: elf.h changes for FR-V FDPIC and TLS

[Roland McGrath]

> +#define EF_FRV_PIC   0x00000100
> +#define EF_FRV_FDPIC 0x00008000

Again but with comments on these two as well, please.