working with split debug files and sectionless ELFs

working with split debug files and sectionless ELFs

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

i've been playing around with super stripping ELFs to the point where they no 
longer have ELF sections (since they're not used at runtime).  all of this 
info has been preserved though in the split debug file.  eu-strip makes this 
very easy to pull off:
	eu-strip /usr/bin/prog --strip-sections \
		-f /usr/lib/debug/usr/bin/prog.debug

first, it seems that --symbols silently conflicts with specifying binaries on 
the command line.  so if i do:
	gdb prog --symbols=/usr/lib/debug/usr/bin/prog.debug
the --symbols argument is silently ignored and gdb complains about no 
debugging information found.  if however i do:
	gdb --symbols=/usr/lib/debug/usr/bin/prog.debug --exec=/usr/bin/prog
then everything works nicely.  i can imagine that people aren't keen on 
changing this behavior so it works (imo) a bit more naturally, but should we 
at least have gdb warn that --symbols is ignored when given an executable on 
the command line ?  the --help output doesn't seem to mention this that i can 
see.

second, i wonder if we can't have this work more intelligently out of the box.  
is it unreasonable to have gdb automatically search /usr/lib/debug/ for split 
debuf files if the .gnu_debuglink section does not exist ?  or at least do it 
if the ELF has no sections at all ?  it'd be nice if we could do `gdb prog` 
and gdb is smart enough to at least check /usr/lib/debug/usr/bin/prog.debug.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: working with split debug files and sectionless ELFs

[Aleksandar Ristovski]

On 11-10-12 01:35 PM, Mike Frysinger wrote:
...
>
> second, i wonder if we can't have this work more intelligently out of the box.
> is it unreasonable to have gdb automatically search /usr/lib/debug/ for split
> debuf files if the .gnu_debuglink section does not exist ?  or at least do it
> if the ELF has no sections at all ?  it'd be nice if we could do `gdb prog`
> and gdb is smart enough to at least check /usr/lib/debug/usr/bin/prog.debug.
> -mike


Can this be used for what you want:

(gdb) help set debug-file-directory
Set the directories where separate debug symbols are searched for.
Separate debug symbols are first searched for in the same
directory as the binary, then in the `.debug' subdirectory,
and lastly at the path of the directory of the binary with
each global debug-file-directory component prepended.

Re: working with split debug files and sectionless ELFs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1249 bytes --]

On Friday 14 October 2011 10:23:04 Aleksandar Ristovski wrote:
> On 11-10-12 01:35 PM, Mike Frysinger wrote:
> > second, i wonder if we can't have this work more intelligently out of the
> > box. is it unreasonable to have gdb automatically search /usr/lib/debug/
> > for split debuf files if the .gnu_debuglink section does not exist ?  or
> > at least do it if the ELF has no sections at all ?  it'd be nice if we
> > could do `gdb prog` and gdb is smart enough to at least check
> > /usr/lib/debug/usr/bin/prog.debug. -mike
> 
> Can this be used for what you want:
> 
> (gdb) help set debug-file-directory

that is already set to "/usr/lib/debug/" by default.  if you look at the logic 
that loads the split debug files, the issue is that it immediately returns if 
no debugging information is found in the ELF -- which there isn't if all the 
sections have been split out.  so it doesn't get a chance to scan the debug 
file directory.

check out symfile.c:find_separate_debug_file_by_debuglink().  i hacked it locally 
so that when get_debug_link_info() returns NULL, the code would fall back to 
searching for the basename(argv[0]) + ".debug" of the ELF in question.  that 
seemed to do what i want: "just work".
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: working with split debug files and sectionless ELFs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1249 bytes --]

On Friday 14 October 2011 10:23:04 Aleksandar Ristovski wrote:
> On 11-10-12 01:35 PM, Mike Frysinger wrote:
> > second, i wonder if we can't have this work more intelligently out of the
> > box. is it unreasonable to have gdb automatically search /usr/lib/debug/
> > for split debuf files if the .gnu_debuglink section does not exist ?  or
> > at least do it if the ELF has no sections at all ?  it'd be nice if we
> > could do `gdb prog` and gdb is smart enough to at least check
> > /usr/lib/debug/usr/bin/prog.debug. -mike
> 
> Can this be used for what you want:
> 
> (gdb) help set debug-file-directory

that is already set to "/usr/lib/debug/" by default.  if you look at the logic 
that loads the split debug files, the issue is that it immediately returns if 
no debugging information is found in the ELF -- which there isn't if all the 
sections have been split out.  so it doesn't get a chance to scan the debug 
file directory.

check out symfile.c:find_separate_debug_file_by_debuglink().  i hacked it locally 
so that when get_debug_link_info() returns NULL, the code would fall back to 
searching for the basename(argv[0]) + ".debug" of the ELF in question.  that 
seemed to do what i want: "just work".
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: working with split debug files and sectionless ELFs

[Aleksandar Ristovski]

On 11-10-14 11:27 AM, Mike Frysinger wrote:
> On Friday 14 October 2011 10:23:04 Aleksandar Ristovski wrote:
>> On 11-10-12 01:35 PM, Mike Frysinger wrote:
>>> second, i wonder if we can't have this work more intelligently out of the
>>> box. is it unreasonable to have gdb automatically search /usr/lib/debug/
>>> for split debuf files if the .gnu_debuglink section does not exist ?  or
>>> at least do it if the ELF has no sections at all ?  it'd be nice if we
>>> could do `gdb prog` and gdb is smart enough to at least check
>>> /usr/lib/debug/usr/bin/prog.debug. -mike
>>
>> Can this be used for what you want:
>>
>> (gdb) help set debug-file-directory
>
> that is already set to "/usr/lib/debug/" by default.  if you look at the logic
> that loads the split debug files, the issue is that it immediately returns if
> no debugging information is found in the ELF -- which there isn't if all the
> sections have been split out.  so it doesn't get a chance to scan the debug
> file directory.
>
> check out symfile.c:find_separate_debug_file_by_debuglink().  i hacked it locally
> so that when get_debug_link_info() returns NULL, the code would fall back to
> searching for the basename(argv[0]) + ".debug" of the ELF in question.  that
> seemed to do what i want: "just work".
> -mike


Ok, so the problem is that if debuglink is missing, gdb just gives up.

FWIW, what you are proposing makes sense to me. Maybe make it an 
optional behaviour?

I'd suggest you open an enhancement request in bugzilla (if there is not 
something along those lines there already) and propose the patch so the 
maintainers have a say.

---
Aleksandar

Re: working with split debug files and sectionless ELFs

[Jan Kratochvil]

On Fri, 14 Oct 2011 17:38:30 +0200, Aleksandar Ristovski wrote:
> On 11-10-14 11:27 AM, Mike Frysinger wrote:
> > check out symfile.c:find_separate_debug_file_by_debuglink().  i hacked it locally
> > so that when get_debug_link_info() returns NULL, the code would fall back to
> > searching for the basename(argv[0]) + ".debug" of the ELF in question.  that
> > seemed to do what i want: "just work".
> 
> Ok, so the problem is that if debuglink is missing, gdb just gives up.
> 
> FWIW, what you are proposing makes sense to me. Maybe make it an
> optional behaviour?

The problem is the ".debug" extension is stored in .debug_link and it is not
assumed by GDB so far.  And for example Debian does not use it at all.

Using the ".debug" extension is too slow as the file needs to be checksummed
first.  One should use /usr/lib/debug/.build-id/ instead.  Still the argument
applies even /usr/lib/debug/.build-id/ is skipped without .debug_link.  But
for /usr/lib/debug/.build-id/ you do not need to assume any ".debug" suffix.


Thanks,
Jan

Re: working with split debug files and sectionless ELFs

[Jan Kratochvil]

On Fri, 14 Oct 2011 17:49:24 +0200, Jan Kratochvil wrote:
> Using the ".debug" extension is too slow as the file needs to be checksummed
> first.  One should use /usr/lib/debug/.build-id/ instead.  Still the argument
> applies even /usr/lib/debug/.build-id/ is skipped without .debug_link.  But
> for /usr/lib/debug/.build-id/ you do not need to assume any ".debug" suffix.

That's not true - one can check just the build-id note even if one finds it by
the ".debug" suffix; just GDB currently does not do so.  Although I do not
think it is useful in any way - if build-id is already present it can be used
for the filename as it prevents name clashes during multiple versions
installed, moved files etc.


Regards,
Jan

Re: working with split debug files and sectionless ELFs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 889 bytes --]

On Friday 14 October 2011 12:25:31 Jan Kratochvil wrote:
> On Fri, 14 Oct 2011 17:49:24 +0200, Jan Kratochvil wrote:
> > Using the ".debug" extension is too slow as the file needs to be
> > checksummed first.  One should use /usr/lib/debug/.build-id/ instead. 
> > Still the argument applies even /usr/lib/debug/.build-id/ is skipped
> > without .debug_link.  But for /usr/lib/debug/.build-id/ you do not need
> > to assume any ".debug" suffix.
> 
> That's not true - one can check just the build-id note even if one finds it
> by the ".debug" suffix; just GDB currently does not do so.  Although I do
> not think it is useful in any way - if build-id is already present it can
> be used for the filename as it prevents name clashes during multiple
> versions installed, moved files etc.

build-id is a section.  my ELF has no sections.  i'm back where i started :).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: working with split debug files and sectionless ELFs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1390 bytes --]

On Friday 14 October 2011 11:49:24 Jan Kratochvil wrote:
> On Fri, 14 Oct 2011 17:38:30 +0200, Aleksandar Ristovski wrote:
> > On 11-10-14 11:27 AM, Mike Frysinger wrote:
> > > check out symfile.c:find_separate_debug_file_by_debuglink().  i hacked
> > > it locally so that when get_debug_link_info() returns NULL, the code
> > > would fall back to searching for the basename(argv[0]) + ".debug" of
> > > the ELF in question.  that seemed to do what i want: "just work".
> > 
> > Ok, so the problem is that if debuglink is missing, gdb just gives up.
> > 
> > FWIW, what you are proposing makes sense to me. Maybe make it an
> > optional behaviour?
> 
> The problem is the ".debug" extension is stored in .debug_link and it is
> not assumed by GDB so far.  And for example Debian does not use it at all.

that's why it was a hack.  i think it reasonable that if there is no debug 
info to first look for the file name itself, and then look for the file name with 
a .debug suffix.

so `gdb prog` where prog is found at /usr/bin/prog would default to 
/usr/lib/debug/usr/bin/prog followed by /usr/lib/debug/usr/bin/prog.debug (and 
obviously /usr/lib/debug/ is the existing configurable setup and not a 
hardcoded path).

i'm thinking of the fallback/default behavior here.  none of this would 
preclude the existing explicit options that gdb has available.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: working with split debug files and sectionless ELFs

[Jan Kratochvil]

On Fri, 14 Oct 2011 19:05:46 +0200, Mike Frysinger wrote:
> build-id is a section. my ELF has no sections.  i'm back where i started :).

build-id is in a note being both a section and a segment.  GDB currently reads
it as a section but this can be changed.

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
[...]
  NOTE           0x000254 0x0000000000400254 0x0000000000400254 0x000044 0x000044 R   0x4
[...]
Notes at offset 0x00000274 with length 0x00000024:
  Owner         Data size       Description
  GNU           0x00000014      NT_GNU_BUILD_ID (unique build ID bitstring)

It was designed by Roland McGrath exactly this way so that in all cases of
debug info stripping build-id remains in the main executable.  Otherwise
build-id would be useless.


Thanks,
Jan

Re: working with split debug files and sectionless ELFs

[Jan Kratochvil]

On Fri, 14 Oct 2011 19:07:53 +0200, Mike Frysinger wrote:
> that's why it was a hack.  i think it reasonable that if there is no debug 
> info to first look for the file name itself, and then look for the file name with 
> a .debug suffix.

The debug files without any suffix are IMO problematic, there was already at
least a second patch to deal with it and it has performance issues:
	[patch] Verify byte-by-byte if both files are the same on "remote:" [Re: [rfc] False separate debuginfo warning with "remote:" access]
	http://sourceware.org/ml/gdb-patches/2011-10/msg00254.html

build-id should be the first one tried, it is already tried if .debug_link
exists so why to break it for the non-.debug_link case.  If build-id does not
exist I do not mind much how many ineffective fallbacks in which order get
implemented.


Regards,
Jan

Re: working with split debug files and sectionless ELFs

[Aleksandar Ristovski]

On 11-10-14 01:07 PM, Mike Frysinger wrote:
> On Friday 14 October 2011 11:49:24 Jan Kratochvil wrote:
>> On Fri, 14 Oct 2011 17:38:30 +0200, Aleksandar Ristovski wrote:
>>> On 11-10-14 11:27 AM, Mike Frysinger wrote:
>>>> check out symfile.c:find_separate_debug_file_by_debuglink().  i hacked
>>>> it locally so that when get_debug_link_info() returns NULL, the code
>>>> would fall back to searching for the basename(argv[0]) + ".debug" of
>>>> the ELF in question.  that seemed to do what i want: "just work".
>>>
>>> Ok, so the problem is that if debuglink is missing, gdb just gives up.
>>>
>>> FWIW, what you are proposing makes sense to me. Maybe make it an
>>> optional behaviour?
>>
>> The problem is the ".debug" extension is stored in .debug_link and it is
>> not assumed by GDB so far.  And for example Debian does not use it at all.
>
> that's why it was a hack.  i think it reasonable that if there is no debug
> info to first look for the file name itself, and then look for the file name with
> a .debug suffix.
>
> so `gdb prog` where prog is found at /usr/bin/prog would default to
> /usr/lib/debug/usr/bin/prog followed by /usr/lib/debug/usr/bin/prog.debug (and
> obviously /usr/lib/debug/ is the existing configurable setup and not a
> hardcoded path).
>
> i'm thinking of the fallback/default behavior here.  none of this would
> preclude the existing explicit options that gdb has available.
> -mike


I would prefer to not have gdb assume any suffix. When I said your 
proposal made sense, I did not go into the implementation details. I 
agree this would be useful in principle - but would strongly suggest not 
to hard-code such a suffix, fallback or not.

If suffix is desired, than at a minimum make it optional. Something like
(gdb) set debug-file-suffix .debug
You can make default settable at configure time.

If separate info is in a separate directory, suffix quite possibly is 
not needed at all; it does make a lot of sense if symbol file is in the 
same directory as the binary itself.

Further, it might not be .debug at all (e.g. we prefer using .sym).

---
Aleksandar

Re: working with split debug files and sectionless ELFs

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1128 bytes --]

On Friday 14 October 2011 13:25:08 Jan Kratochvil wrote:
> On Fri, 14 Oct 2011 19:05:46 +0200, Mike Frysinger wrote:
> > build-id is a section. my ELF has no sections.  i'm back where i started
> > :).
> 
> build-id is in a note being both a section and a segment.  GDB currently
> reads it as a section but this can be changed.
> 
> Program Headers:
>   Type           Offset   VirtAddr           PhysAddr           FileSiz 
> MemSiz   Flg Align [...]
>   NOTE           0x000254 0x0000000000400254 0x0000000000400254 0x000044
> 0x000044 R   0x4 [...]
> Notes at offset 0x00000274 with length 0x00000024:
>   Owner         Data size       Description
>   GNU           0x00000014      NT_GNU_BUILD_ID (unique build ID bitstring)
> 
> It was designed by Roland McGrath exactly this way so that in all cases of
> debug info stripping build-id remains in the main executable.  Otherwise
> build-id would be useless.

ah, wasn't aware of it also being in the program headers.  yes, i should be 
able to leverage this, once we fix gdb to fall back to the program header when 
the section isn't found.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]