Re: Improve separate debug file support for elfutils

[Daniel Jacobowitz <drow@false.org>]

On Sun, Oct 15, 2006 at 01:45:41AM +0200, Jan Kratochvil wrote:
> Hi Daniel,
> 
> thanks for this patch. Unfortunately using CVS + this patch the problem is
> still present:
> 	Reading symbols from /lib/modules/2.6.18-1.2747.fc6/kernel/fs/ext3/ext3.ko...Reading symbols from /usr/lib/debug/lib/modules/2.6.18-1.2747.fc6/kernel/fs/ext3/ext3.ko.debug...DW_FORM_strp pointing outside of .debug_str section [in module /usr/lib/debug/lib/modules/2.6.18-1.2747.fc6/kernel/fs/ext3/ext3.ko.debug]
> 
> These two testfiles stored at:
> 	http://www.jankratochvil.net/priv/ext3-debug.tar.gz
> 
> According to the error I believe the patch also needs to cover libbfd.
> Is it valid it still needs to be patched for this case?
> 
> Jakub Jelinek was confirming before that elfutils produce in some way valid
> ELFs - with the missing strtab/symtab.  I did not check the binaries myself.

I didn't even know it was possible to put a .gnu_debuglink in a
relocatable file!  So this is a different problem than the one I was
working on, I suppose.

I presume from the error message that
bfd_simple_get_relocated_section_contents hasn't relocated the file's
debug info.  You'll see that it takes a symbol_table.  You could
probably arrange to supply one from the alternate file.  I'm worried
that the section offsets would not match up, though, because section
numbering changes.

Simply put, I do not understand how Jakub can describe this file as
valid.  The ext3.ko.debug has relocation sections with an sh_link
pointing to the NOBITS symtab.  And that symtab isn't in that file, and
at least one section has a different section index between the two
files, so I don't see how you can trust that a symtab from another file
is useful in this one.

You get lucky, in that only .module_sig moved and there's only one
symbol in it (symbol #321), and there's no relocations against the
debug sections.

Jakub, how do you expect this weird file to be interpreted (and why are
you producing things that BFD can't handle, anyway?)

-- 
Daniel Jacobowitz
CodeSourcery