Obtaining archive(static library) information from an elf file

[oguzcanoguz]

Hi all,

I wonder, using pyelftools or in general with elf files, if we can extract the archive information for a symbol?

For instance in a gcc map file we have:

 .text._ZN11application26Binary19SendStreamE
               0x200061d8   0x8 path/library.a(Init.cpp.obj)

I would like to obtain the library information: library.a from the associated elf file.
End goal is to calculate the size contribution of a particular library that is linked.

Thanks.

[sevaa]

Not always. In general, the linker is allowed to shuffle code around a lot. The biggest options to watch are function level linking and link-time code generation.

If both are off though (aka the classical linking scenario), it would be possible to chart the boundaries of object files' contributions in the executable, and trace those to libraries they originate in. It would require having a copy of the library it was linked against. Note that that's just code; the library also contributes data to the statically initialized global data sections. If the library contains the debug symbols and so does the executable, that's also a contribution to the executable size. The size estimation won't be and can't be exact, since the process of linking involves more than just concatenating pieces of files together even in the classical model.

What is this for to begin with, by the way?

[oguzcanoguz]

The aim is to see, approximately, the size contribution of a static library when it is linked.
This way the user of the library can have an idea of the library size. The user will be linking to user application:
ld user_main.o library.a

Similary the developer of the library can trend the size of the library. The developer will be linking to, for instance, a test application:
ld test_main.o library.a

If i understand correctly, easiest way to obtain this would be to parse map file instead of the elf file.
And the size contribution of the library would the total size of the symbols coming from it.
Do you agree?

[sevaa]

I don't know about your toolchain - does the map file contain the length of functions and data items? Map file format are not standardized AFAIK. Symbol offsets are a given, but for size estimation you need offset and length, or start offset and end offset. You can sort of guess the latter from the offset of the next item though.

[oguzcanoguz]

Our map file has entries like this, where 0x08 is the length of the symbol.

 .text._ZN11application26Binary19SendStreamE
               0x200061d8   0x8 path/library.a(Init.cpp.obj)

There are some libraries (e.g. https://github.com/ebs-universe/fpv-gcc) that can parse our map files and report out size of a library.
But we are already parsing elf files in our CI and my intention was to extract this info also from the elf file.
I thought that everything in the map file must be coming from and present also in the elf file, but looking at your response this might not be the case.

[sevaa]

The map file style information is mostly present in the debugging information in the ELF file. It's not a part of the ELF format proper. The debug info (aka "DWARF info") encodes so much more than just function offsets and lengths - parsing those out is possible but way more involved than parsing a map file. And there is no direct reference in DWARF as to which static library the function came from, since that's irrelevant to the debugger.

Depending on your compiler/linker options, the debug info may or may not be there in the built files.

Check length on other lines in your map file. 8 is suspiciously small for a function size; could be that it's just pointer size.