This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] Restore dlsym(RTLD_NEXT, ...) behaviour


Jakub Jelinek <jakub@redhat.com> writes:

> Hi!
> 
> Informix uses dlsym(RTLD_NEXT, "foo") in the main program, which used to
> work but does not work any longer.
> IMHO dlsym(RTLD_NEXT, "foo") in the main program makes sense, consider
> something like:
> #define _GNU_SOURCE
> #include <dlfcn.h>
> int getpid()
> {
>   return 32;
> }
> int main(void)
> {
>   void *p = (void *)getpid;
>   void *q = dlsym (RTLD_DEFAULT, "getpid");
>   void *r = dlsym (RTLD_NEXT, "getpid");
>   printf ("%p %p %p\n", p, q, r);
> }

Can you reformat this example suitable for the testsuite together with
a patch for the Makefile, please?

> It looks like this was changed when strict map range checking was added to
> dl-sym.c. The patch below does not catch all cases where the error could be
> signalled, but I think it is better if it works in the main program than to
> catch them all (alternatively, the code could e.g. find at least smallest
> l_map_start above _dl_loaded->l_map_start and check if caller is less than
> that; BTW: why isn't l_map_end for the main program deducted from
> Elf_Phdr?).
> What is also needed is some variant of either H.J.'s _dl_signal_error or
> e.g. the attached one (so that signalling error in real statically linked
> application works).

The patch looks fine but I'll leave those for Ulrich to check,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]