RE: dynamically loading libgcj (still) SEGFAULTS

["Boehm, Hans" <hans_boehm at hp dot com>]

I am told that the current code in the gc library to find dynamic library
data segments is not always correct, which may also have an impact here in
the case of preloaded libraries.  Jakub Jelinek supplied a patch, but it
relies on functionality which I believe is only in glibc 2.2.4+.  I included
a modified version of the patch in gc6.1alpha1 (see dyn_load.c), which I
just made available.  It should continue to work with old versions of glibc,
by making th reference to dl_iterate_phdr weak, and running the old code if
it's not there.  (With the possible exception of this patch, and some new
ports, I don't think 6.1alpha1 fixes anything terribly important to gcj.
There was some moderately high risk code cleanup, however.)  I'm certainly
willing to check the modified version of the patch into the trunk, if there
is a consensus that this matters.

I appended a message from Jakub Jelinek on the subject, since it might help
here.  (Hopefully he doesn't mind.)  Unfortunately, I'm still not sure that
I fully understand all the issues.  In particular, I understand that there
is no really clean way to fix this without relying on dl_iterate_phdr().
But is there a way to fix the old code so that it works more of the time?
Since the test for dl_iterate_phdr is already there, compatibility with
future glibc versions hopefully wouldn't be an issue.

If I understand correctly (a dubious assumption), none of this affects the
main failure; it seems to be related only to the preload case.

Hans

> From: Johannes Zellner [mailto:johannes@zellner.org]
> ...
> btw.:
> 
> export LD_PRELOAD="libgcj.so libgcjgc.so libz.so"
> 
> and ordinary system programs like 'rm' are segfaulting.
> 
> really weird.
> 
> -- 
>    Johannes
> 

Jakub's message:

> At what point does the old code start breaking?

When any library has first PT_LOAD's segment p_vaddr non-zero, e.g. as done
with prelinking:

Program Headers of libc.so which will work even with the old code:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00000034 0x00000034 0x000c0 0x000c0 R E 0x4
  INTERP         0x1339f3 0x001339f3 0x001339f3 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x00000000 0x00000000 0x133a06 0x133a06 R E 0x1000
  LOAD           0x133a20 0x00134a20 0x00134a20 0x04724 0x08928 RW  0x1000
  DYNAMIC        0x13806c 0x0013906c 0x0013906c 0x000d8 0x000d8 RW  0x4
  NOTE           0x0000f4 0x000000f4 0x000000f4 0x00020 0x00020 R   0x4

Program Headers of prelinked libc.so which will GC without the patch
segfault on:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x4101e034 0x4101e034 0x000c0 0x000c0 R E 0x4
  INTERP         0x133393 0x41151393 0x41151393 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x4101e000 0x4101e000 0x1333a6 0x1333a6 R E 0x1000
  LOAD           0x1333c0 0x411523c0 0x411523c0 0x04708 0x088e8 RW  0x1000
  DYNAMIC        0x1379f0 0x411569f0 0x411569f0 0x000d8 0x000d8 RW  0x4
  NOTE           0x0000f4 0x4101e0f4 0x4101e0f4 0x00020 0x00020 R   0x4

In the latter case, link_map's l_addr will point 0x4101e000 bytes away from
ElfW(Ehdr) headers (usually l_addr will be 0 and the library mapped at
0x4101e000).

> I'm concerned about turning
> this on by default, since it's common to statically link the collector
into
> an executable which is dynamically linked against glibc.  If I read this
> correctly any executable built this way under glibc 2.2.4 would break on
> earlier systems, which is a significant problem.

You can surely use dl_iterate_phdr as extern weak and test that (but you
need the #if ........ defined(DT_CONFIG) test anyway since otherwise
<link.h> won't declare structure the code needs), though I'm not sure if it
is right to put it into boehm-gc shared lib too (the less weak symbol tests
for non-zero there are in libraries, the better for prelinking; worst case
I'll patch it out from Red Hat libgcjgc.so).

	Jakub