This is the mail archive of the
mailing list for the binutils project.
RE: Listing source files with objdump
- From: John Kearney <jokearney at qnx dot com>
- To: Bruce Dawson <bruced at valvesoftware dot com>, "'binutils at sourceware dot org'" <binutils at sourceware dot org>
- Date: Wed, 5 Jun 2013 01:19:42 +0000
- Subject: RE: Listing source files with objdump
- References: <2AC155A009400B4C8B05D518E4819AEF07205A43 at exchange10 dot valvesoftware dot com>
I did something similar a while back but never got around to posting it.
I didn't print the tables separately but rather the full paths.
So I for one would be interested in this functionality.
Mit freundlichen Grüßen / Yours Sincerly
QNX Software Systems
Mobile +49 151 1464 8298
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Bruce Dawson
Sent: Mittwoch, 5. Juni 2013 01:45
Subject: Listing source files with objdump
I want to get a list of all of the source files and header files used to create a particular shared object. I can do this with "objdump -Wl" in order to get the Directory Table and the File Name Table, but this also emits an enormous volume of other data. The volume of data is large enough that filtering through it (some combination of the time that objdump spends printing it and the time that I spend parsing it) is inconveniently long -- it noticeably increases our build time.
I found the display_debug_lines_raw() function in dwarf.c and I modified it to just print the Directory Table and File Name Table arrays, and that works quite nicely for my purposes. There is still a lot of redundancy (the same files listed many times) but the volume of data is 15-20x smaller so the printing and parsing is no longer a problem.
Does it seem worthwhile to add a new objdump command line option to just dump this information? I could see it being useful for others. Perhaps -WS for Source.
The actual change would be simple (an extra flag to display_debug_lines_raw), but I don't know if it is desirable for the population at large. If not then I'll continue using our custom version.