I noticed whilst objdumping drivers/cpufreq/cpufreq.o that there was dwarf info
for various things that I know the cpufreq subsystem doesn't use (VM internals
and ELF definitions for example). I suspect these are being pulled into the
build through some dependancy chain of #includes. But as the object code
doesn't ever refer to those definitions, is there a reason why gcc still emits
them into the debuginfo ?
For an example, objdump -W drivers/cpufreq/cpufreq.o and search for 'vma' or 'Elf'
(and a whole host of other never used symbols).
GCC has -feliminate-unused-debug-symbols and -feliminate-unused-debug-types
options to give users better control over this (the latter is on by default).
You'd need to attach your cpufreq.o + cpufreq.i, say some examples of
types/symbols and then we can talk over readelf -wi dump whether something is
really unused or not. But always some people want less info in the debuginfo,
while others want more, we can't make everyone happy. The real solution is the
dwarf compacter, especially if it can for kernel compat accross all module
Created attachment 285871 [details]
So, if you want to know e.g. why Elf64_Addr type is in there, then it is one of
the many types reachable from struct task_struct (by reachable I mean types of
an aggregate and anything pointers in there point to transitively) and you can
get to struct task_struct from _cpu_pda or _proxy_pda extern variables. If you
don't -feliminate-unused-debug-symbols, then all extern decls seen will be in there,
just (unless -fno-eliminate-unused-debug-types) types that have never been
referenced won't be output.
Actually, _cpu_pda is used all around the code as objdump -dr cpufreq.o shows.