On 26/2/20 11:00 am, Austin Lund wrote: > On Mon, Feb 24, 2020 at 03:56:58PM +1000, Allan McRae wrote: >> On 20/2/20 11:51 am, Austin Lund wrote: >>> Currently only the file pointed to by the DW_AT_name is included as a source >>> file in debug packages. This means many files that are useful for >>> debugging are >>> not included. For example, no header files are included but yet these may >>> by >>> referenced in the .debug_line section. >>> >>> This sed script converts into shell variables the debug dump information >>> from >>> readelf about compilation units, directory tables and file tables. This >>> can be >>> used to get the full path of all the source files from within the package >>> being >>> compiled that are referenced in the debugging information. Also, >>> placeholder >>> symbols (e.g. <builtin>) and paths outside the current source (e.g. linked >>> libraries) will be more consistently ignored from inclusion in the debug >>> packages. >>> >>> Signed-off-by: Austin Lund <[email protected]> >>> --- >> >> >> So... that sed script is horrendous! But let me see if I understand >> this correctly. >> >> >> We currently only look at the .debug_info section, finding >> DW_AT_name/DW_AT_comp_dir pair to grab file names. That appears to get >> the main compilation units, but misses header files. It looks like your >> sed does something slightly different to get that info, although I can't >> tell if there is a functional difference. >> >> Your patch additionally looks at the .debug_line section. This section >> has a table of directories that source files come from (which can be >> filtered to remove system directories), and a file name table with files >> from each directory. This does not include the files we currently grab. >> >> But there must be something I am missing... For the example of "ls" I >> see "selinux.h" in from directory "./lib/selinux" in that .debug_line >> output. Your script does not include this file. Using the rpmtool >> "debugedit -l" does include that file in its file list. There are quite >> a few other examples. >> >> Am I on the right track? Can you clarify what I am missing here? > > It would seem I made a bad assmption about what was in and not in the current > source tree. There will be references to libc files that appear in the output > as a relative path. My thought was that if there wasn't a preceeding './' > then > it must refer to another directory. > > Anyway, yes. You are on the right track. My hope was that you can install > the > debug package and get all available source listings. Without these functions > within the header files, that isn't possible. > > What's a better approach to parsing the readelf output? Awk?
Short answer... I'm not sure of the best approach. I'd just like it to be readable. I have file a bug: https://bugs.archlinux.org/task/65677
