[PATCH v2 00/21] Refactor (k)symtab reader

[Dodji Seketeli]

Hello,

Matthias Maennich <maennich@google.com> a écrit:

> The current implementation that reads the symtab and the ksymtab has grown
> over time from simple symtab reading to way more complex ksymtab reading
> including taking care of little details like position relative relocations,
> symbol namespaces, etc. Yet, more features are coming to the Linux kernels that
> make this parsing even more tricky: Further changes to the ksymtab layout and
> different needs to lookup symbols caused by features like LTO (causing RELA
> relocations in the ksymtab entries) and CFI (causing additional jump table
> symbols) that are highly confusing the meaning of ksymtab entries and make it
> increasingly challenging for a static analysis tool like libabigail to properly
> process the ksymtab values.
>
> This added complexity also adds more and more responsibilities to the
> read_context that already has a lot of different tasks to juggle. It gets
> increasingly difficult to ensure, further development in the dwarf reader can
> be done without subtly regressing existing functionality.

Agreed.

>From my point of view, even independently from the kernel symbol table
reading requirement, I think we need to separate the ELF
reading/handling and the DWARF handling to make the code base more
future-proof and capable of handling things that we may face in the
future like supporting of other debuginfo formats or, who knows, other
binary formats.

I thus welcome changes that move us into that direction.  Thank you for
looking into this.

This is a big code drop so if you don't mind, I'll be reviewing this in
"rounds", going over a subset of patches multiple times, discussing
different aspects at once.

[...]

Cheers,

-- 
		Dodji