Bug 420981

Summary: unnecessary dwarf info in object files.
Product: [Fedora] Fedora Reporter: Dave Jones <davej>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: pfrields
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-12 16:54:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
cpufreq.o none

Description Dave Jones 2007-12-12 06:33:52 UTC
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).

Comment 1 Jakub Jelinek 2007-12-12 10:14:25 UTC
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.

Comment 2 Dave Jones 2007-12-12 16:21:06 UTC
Created attachment 285871 [details]
cpufreq.o

Comment 3 Jakub Jelinek 2007-12-12 16:41:46 UTC
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.

Comment 4 Jakub Jelinek 2007-12-12 16:54:58 UTC
Actually, _cpu_pda is used all around the code as objdump -dr cpufreq.o shows.