dynlib_addr and stripped dynamic modules

dynlib_addr and stripped dynamic modules

[Eli Zaretskii]

Does dynlib_laddr (and its underlying library function dladdr) work on
Posix hosts when the module was stripped of any unneeded symbols?

Well written Emacs modules will have all but one of its functions
static and un-exported, so the only way to access the name of a
function by its address is to read a symbol table of some kind.  Does
that work with *.so files that were run through "strip --strip-unneeded"?

Re: dynlib_addr and stripped dynamic modules

[Philipp Stephani]

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

Eli Zaretskii <eliz@gnu.org> schrieb am So., 22. Nov. 2015 um 19:25 Uhr:

> Does dynlib_laddr (and its underlying library function dladdr) work on
> Posix hosts when the module was stripped of any unneeded symbols?
>
> Well written Emacs modules will have all but one of its functions
> static and un-exported, so the only way to access the name of a
> function by its address is to read a symbol table of some kind.  Does
> that work with *.so files that were run through "strip --strip-unneeded"?
>
>
Probably not, but I haven't tested it. I've added dladdr because I found it
useful for debugging myself and it's easy to implement, and I guess during
debugging people will often work with unstripped libraries.

[-- Attachment #2: Type: text/html, Size: 1027 bytes --]

Re: dynlib_addr and stripped dynamic modules

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 07 Dec 2015 18:37:55 +0000
> 
> Eli Zaretskii <eliz@gnu.org> schrieb am So., 22. Nov. 2015 um 19:25 Uhr:
> 
>     Does dynlib_laddr (and its underlying library function dladdr) work on
>     Posix hosts when the module was stripped of any unneeded symbols?
>     
>     Well written Emacs modules will have all but one of its functions
>     static and un-exported, so the only way to access the name of a
>     function by its address is to read a symbol table of some kind. Does
>     that work with *.so files that were run through "strip --strip-unneeded"?
>     
> Probably not, but I haven't tested it. I've added dladdr because I found it
> useful for debugging myself and it's easy to implement, and I guess during
> debugging people will often work with unstripped libraries. 

The information from dynlib_addr is used every time there's a fatal
error in a module, so it's not just for debugging the module by its
author, it's also for users to report when they encounter errors while
using the module.

Re: dynlib_addr and stripped dynamic modules

[Philipp Stephani]

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

Eli Zaretskii <eliz@gnu.org> schrieb am Mo., 7. Dez. 2015 um 19:48 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Mon, 07 Dec 2015 18:37:55 +0000
> >
> > Eli Zaretskii <eliz@gnu.org> schrieb am So., 22. Nov. 2015 um 19:25 Uhr:
> >
> >     Does dynlib_laddr (and its underlying library function dladdr) work
> on
> >     Posix hosts when the module was stripped of any unneeded symbols?
> >
> >     Well written Emacs modules will have all but one of its functions
> >     static and un-exported, so the only way to access the name of a
> >     function by its address is to read a symbol table of some kind. Does
> >     that work with *.so files that were run through "strip
> --strip-unneeded"?
> >
> > Probably not, but I haven't tested it. I've added dladdr because I found
> it
> > useful for debugging myself and it's easy to implement, and I guess
> during
> > debugging people will often work with unstripped libraries.
>
> The information from dynlib_addr is used every time there's a fatal
> error in a module, so it's not just for debugging the module by its
> author, it's also for users to report when they encounter errors while
> using the module.
>

Sure, but having that info in debug mode is better than nothing.

To have reliable function name information, we need to change the interface
of make_function to accept a symbol name parameter and have make_function
assign the new function to the symbol. That would be fine with me: it makes
the interface of make_function even more complex, but it would
automatically cover the most common case.

[-- Attachment #2: Type: text/html, Size: 2147 bytes --]