Re: How to drop all non-global/defined function declarations?

[Mark Wielaard <mark@klomp.org>]

Hi Dodji,

On Tue, 2020-04-07 at 11:38 +0200, Dodji Seketeli wrote:
> From what I see, just invoking abidw on libfoo.so (without any
> suppression specification) captures only the exported functions (which
> have global function symbol in the binary) of the binary, that is:
> create_foo, destroy_foo, get_foo and set_foo as well as free and malloc.

Why are free and malloc included? They are explicitly marked as
undefined in the symbol table and the xml abi definition doesn't
include an elf-function-symbol for them?

> The libfoo_frob function which is not exported (doesn't have a global
> ELF symbol) is not captured.

You are right, for my example, but I see internal, not exported,
symbols in my actual library libelf, an example being __libelf_seterrno
which is definitely LOCAL. Will try to come up with a smaller
reproducer. But you can simply try by running libdw on libelf.so.
__libelf_seterrno will be included if you have debuginfo installed (but
not without debuginfo).

> > But for some reason that doesn't drop the malloc and free function
> > declarations.
> 
> Right.  At the moment, there is no way to filter out a function that is
> actually exported by the binary like this.  I guess the original idea
> was to prevent users from accidentally missing a potential ABI
> incomptable change due to the toolchain or something like that.  Also,
> because those toolchain-generated functions usually don't come with
> debug info, including them in the abixml file doesn't take much space.
> 
> But as usual, if you argue that this is would be a useful feature, then
> we can add an option to handle this usecase.  We just need to discuss
> the details of that option, I guess.

I think them being undefined in the symbol table make them unexported.
They are just there to show the library consumes that symbol. That is
also an abi issue, but not one I am interested in. Users of my library
should assume that my library makes sure such symbols will be resolved
(by having the correct DT_NEEDED entries), but they cannot use that
information themselves to rely on those symbols being there.

The main issue is that they are really noise. They don't come with an
argument list or a real return type. And they make the xml abi file
harder to compare (visually).

My goal here is to have an xml abi file checked into git. Then when we
update the abi, it should be accompanied by a change in the xml abi
file. The smaller and more concise we can make the xml abi file the
clearer it is what we are exactly changing that impacts the abi.

Thanks,

Mark