[Bug dynamic-link/16262] New: Semantics of dladdr don't quite match documentation

[Bug dynamic-link/16262] New: Semantics of dladdr don't quite match documentation

[srk31 at srcf dot ucam.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16262

            Bug ID: 16262
           Summary: Semantics of dladdr don't quite match documentation
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: srk31 at srcf dot ucam.org

Created attachment 7307
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7307&action=edit
Program illustrating the behaviour I'm querying

The man page of dladdr(3) states that dladdr(addr, &info) populates 
info such that info.dli_sname is "the name of the nearest symbol with
address lower than addr". 

In fact, on ELF platforms, it seems only to do so if a symbol *overlaps*
addr, i.e. using the symbol's length information. I've attached a very
small test case. If the documented semantics held, the decrement-by-one
logic would never be hit (client.c:72).

I'm not sure whether this is a bug with the documentation or with
dladdr(), but I'd argue that the documented behaviour would be useful to
have, perhaps as an alternative to the actual behaviour.

Background: I was hoping to use dladdr() as a portable interface for
walking (backwards) through all dynamic symbols defined in a text
segment. Owing to this quirk, though, I get stuck the moment I hit an
address that is not overlapped by a dynamic symbol. If it had the
documented semantics, I'd always get the next lowest symbol. 

The documented semantics are also what any implementation for object
formats *without* length information would give. So, this is perhaps a
portability issue (I can do something on those platforms that then
doesn't work on ELF).

I realise the "right way" to do this is to use libelf or bfd, but it's
frustrating to come so close to not needing the big hammer, especially
when the documentation makes it look like I don't need it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=16262

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtk.manpages at gmail dot com,
                   |                            |neleai at seznam dot cz,
                   |                            |roland at gnu dot org
          Component|dynamic-link                |manual

--- Comment #1 from Ondrej Bilka <neleai at seznam dot cz> ---
That is a documentation bug, manpage is bit clearer by saying that 

If no symbol matching addr could be found, then dli_sname and dli_saddr are set
to NULL.

Could you provide patch with clarification?

Also did you try to use dl_iterate_phdr?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[srk31 at srcf dot ucam.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16262

--- Comment #2 from Stephen Kell <srk31 at srcf dot ucam.org> ---
Thanks for this.

The man page is a fraction better, but still problematic because it doesn't say
what it means for an address to be "matching", and this still differs quite a
bit between ELF and non-ELF cases.

I've just discovered that the dlsym(3) man page is maintained in the Linux
man-pages project, so I will contribute a patch there.

I would also be interested in contributing a patch to glibc which adds a flag
to dladdr1() for requesting the behaviour I was hoping for, if you think it has
a chance of being applied.

I am familiar with dl_iterate_phdr, but it doesn't do what I want. It iterates
over program headers, whereas I want to iterate over (defined, dynamic)
symbols.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[neleai at seznam dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=16262

--- Comment #3 from Ondrej Bilka <neleai at seznam dot cz> ---
On Mon, Dec 09, 2013 at 04:32:52PM +0000, srk31 at srcf dot ucam.org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16262
> 
> --- Comment #2 from Stephen Kell <srk31 at srcf dot ucam.org> ---
> Thanks for this.
> 
> The man page is a fraction better, but still problematic because it doesn't say
> what it means for an address to be "matching", and this still differs quite a
> bit between ELF and non-ELF cases.
> 
> I've just discovered that the dlsym(3) man page is maintained in the Linux
> man-pages project, so I will contribute a patch there.
> 
> I would also be interested in contributing a patch to glibc which adds a flag
> to dladdr1() for requesting the behaviour I was hoping for, if you think it has
> a chance of being applied.
>
Adding flag is not very likely, it would be simpler to directly write a
function
that iterates symbols for given object.

> I am familiar with dl_iterate_phdr, but it doesn't do what I want. It iterates
> over program headers, whereas I want to iterate over (defined, dynamic)
> symbols.
> 
I meant if its feasible to iterate over headers, for each get size and
call dlsym on each of its bytes backwards.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[mtk.manpages at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16262

--- Comment #5 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
(In reply to Ondrej Bilka from comment #1)
> That is a documentation bug, manpage is bit clearer by saying that 
> 
> If no symbol matching addr could be found, then dli_sname and dli_saddr are
> set to NULL.

I've changed the text in the man page to 

    const char *dli_sname;  /* Name of symbol whose definition
                               overlaps addr */

Better, I hope(?).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Bug manual/16262] Semantics of dladdr don't quite match documentation

[Ondřej Bílka]

On Wed, Jan 08, 2014 at 01:08:07AM +0000, mtk.manpages at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16262
> 
> --- Comment #5 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
> (In reply to Ondrej Bilka from comment #1)
> > That is a documentation bug, manpage is bit clearer by saying that 
> > 
> > If no symbol matching addr could be found, then dli_sname and dli_saddr are
> > set to NULL.
> 
> I've changed the text in the man page to 
> 
>     const char *dli_sname;  /* Name of symbol whose definition
>                                overlaps addr */
> 
> Better, I hope(?).
> 
Yes, thats better.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[neleai at seznam dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=16262

--- Comment #6 from Ondrej Bilka <neleai at seznam dot cz> ---
On Wed, Jan 08, 2014 at 01:08:07AM +0000, mtk.manpages at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16262
> 
> --- Comment #5 from Michael Kerrisk <mtk.manpages at gmail dot com> ---
> (In reply to Ondrej Bilka from comment #1)
> > That is a documentation bug, manpage is bit clearer by saying that 
> > 
> > If no symbol matching addr could be found, then dli_sname and dli_saddr are
> > set to NULL.
> 
> I've changed the text in the man page to 
> 
>     const char *dli_sname;  /* Name of symbol whose definition
>                                overlaps addr */
> 
> Better, I hope(?).
> 
Yes, thats better.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[srk31 at srcf dot ucam.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16262

--- Comment #7 from Stephen Kell <srk31 at srcf dot ucam.org> ---
Created attachment 7590
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7590&action=edit
Patch adding alternative behaviour to dladdr1()

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[srk31 at srcf dot ucam.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16262

--- Comment #8 from Stephen Kell <srk31 at srcf dot ucam.org> ---
Thanks very much to Michael Kerrisk for noticing and fixing this (before I even
got around to reporting it to man-pages :-).

I've also produced a (lightly tested) patch to glibc which optionally enables
the alternative behaviour. It is requested using the flags argument to
dladdr1(). 

I realise there mightn't be much enthusiasm for the use cases of this patch --
my symbol-iteration case, or for porting glibc to non-ELF platforms (where this
behaviour is the only one that's portable). But I thought I'd post it anyway.
The patch attached applies to git as of commit
d359bcc2adc063bae511b1a42a01a301b53c4d39 (15th Jan 2014).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug manual/16262] Semantics of dladdr don't quite match documentation

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16262

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.