[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#882874: glibc 2.25 FTBFS on ia64

On 2017-11-28 9:47 AM, James Clarke wrote:
[Cc'ing hppa people for reasons which will become clear]

On Tue, Nov 28, 2017 at 08:22:56AM -0500, Jason Duerstock wrote:
Source: glibc
Followup-For: Bug #882874

This patch appears to correct the problem.

-- System Information:
Debian Release: buster/sid
Architecture: ia64

Kernel: Linux 3.2.0-4-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- sysdeps/ia64/dl-machine.h
+++ sysdeps/ia64/dl-machine.h
@@ -45,7 +45,8 @@

  #define ELF_MACHINE_BEFORE_RTLD_RELOC(dynamic_info)		\
-	__ia64_init_bootstrap_fdesc_table (&bootstrap_map);
+	__ia64_init_bootstrap_fdesc_table (&bootstrap_map);	\
+	_dl_fptr_init();

  /* Return nonzero iff ELF header is compatible with the running host.  */
  static inline int __attribute__ ((unused))
As discussed on IRC with Jason, here are my findings for what on earth
is going on here.

This change is required due to the any/local-dlfptr.diff patch in
Debian, which modifies elf/dl-fptr.c to introduce a _dl_fptr_init to
assign local.root to &local.boot_table, with hppa calling this function
early before it might have to process any relocations needing function
pointers. Now, ignoring one important fact, this is needed on hppa for a
very specific reason: it doesn't have special relative relocation types,
instead reusing R_PARISC_DIR32 and others with symbol index 0, and
doesn't set DT_RELACOUNT in its dynamic section (I assume because
nobody bothered to implement it for bfd), so ld.so cannot perform any
early relative relocations, despite having an implementation for
elf_machine_rela_relative in sysdeps/hppa/dl-machine.h. This means that,
depending on whether any function pointer-needing relocations appear
before the R_hppa_DIR32 for local.root, local.root may not have been
relocated, and thus cannot be used. Instead, the assignment is done
manually in _dl_fptr_init using ELF_MACHINE_LOAD_ADDRESS to do this
without needing any dynamic relocations to have been applied.

However, hppa, at least currently, has its own sysdeps/hppa/dl-fptr.c,
and does not compile elf/dl-fptr.c. This platform-specific dl-fptr.c
also has the same workaround in it, so at least in the context of hppa,
I don't see why this patch is needed any more (perhaps at one point
elf/dl-fptr.c was being used for hppa on Debian, but it isn't now).

Now, the only architecture actually using elf/dl-fptr.c currently is
ia64. This patch therefore presents a problem, as its
ELF_MACHINE_BEFORE_RTLD_RELOC does not call _dl_fptr_init (as pointed
out by Jason's patch above). Thus, applying Jason's patch does in fact
fix the issue on ia64. However, on ia64, there are specific relative
relocations, and DT_RELACOUNT *does* get set to something sensible, so
local.root gets relocated early, and this is why upstream glibc has not
seen an issue with elf/dl-fptr.c on ia64. Therefore, this patch is
*also* not needed on ia64 (albeit for different reasons), and so my
suggested fix would be instead to simply drop this local patch, as its
sole effect is to break ia64.

Thoughts (especially from hppa people)?

I'm not sure about calling  _dl_fptr_init.  I recall there were issues with backtraces
on hppa and some backtrace tests fail on hppa.

From your comments, it may be possible to switch hppa to elf/dl-fptr.c.

First, hppa does have special relative relocations.  For example, we have:

#define ELF_MACHINE_LOAD_ADDRESS(var, symbol) \
  asm (                                                         \
"       b,l     1f,%0\n"                                        \
"       depi    0,31,2,%0\n"                                    \
"1:     addil   L'" #symbol " - ($PIC_pcrel$0 - 8),%0\n"        \
"       ldo     R'" #symbol " - ($PIC_pcrel$0 - 12)(%%r1),%0\n" \
   : "=&r" (var) : : "r1");

I have learned recently that the depi instruction isn't needed.  The above can become:

#define ELF_MACHINE_LOAD_ADDRESS(var, symbol) \
  asm (                                                         \
"       b,l     1f,%0\n"                                        \
"       addil   L'" #symbol " - ($PIC_pcrel$0 - 1),%0\n"        \
"1:   ldo      R'" #symbol " - ($PIC_pcrel$0 - 5)(%%r1),%0\n" \
   : "=&r" (var) : : "r1");

The offsets are adjusted to account for the priority level bits in the program counter.

The use of pc-relative relocation is something I added fairly recently.

Second, Alan Modra recently fixed the relocation handling for R_PARISC_DIR32
so that it now works in dynamic applications.


John David Anglin  dave.anglin@bell.net

Reply to: