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 *.debug files.
Created attachment 285871 [details] cpufreq.o
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.