On Tue, Jan 22, 2013 at 08:53:46PM +0100, Jan Kratochvil wrote:
On Tue, 22 Jan 2013 19:19:04 +0100, Mark Wielaard wrote:
> On Tue, Jan 22, 2013 at 06:28:03PM +0100, Jan Kratochvil wrote:
> > This is OK as long as there cannot happen:
> > mod->first_global == 0 && mod->aux_symdata != NULL
> > and therefore also: mod->aux_first_global > 0
>
> If that happens then first_global = 0. Which means we just don't know
> where the first global is in the table. And so we will just search the
> whole table (1, syments). That means we just don't do the optimization
It has functionality impact, that means we will ignore the first global symbol
of minidebuginfo as search_table will be called with (1, syments) as you say
but in such case symbol #0 is a valid one - from minidebuginfo (shifted to
number #1 there).
That could only happen if also mod->syments = 0, aka there is no dynsym at
all. But then we will not get here, because...
Yes, and this is a bug. In the testcase below are perfectly valid
shdrs.
1003 case DWFL_E_NO_SYMTAB:
1004 if (symscn != NULL)
1005 {
1006 /* We still have the dynamic symbol table. */
1007 mod->symerr = DWFL_E_NOERROR;
1008
1009 /* The dynsym table might be extended by an auxiliary table. */
1010 find_aux_sym (mod, &aux_symscn, &aux_xndxscn, &aux_strshndx);
1011 break;
1012 }
minidebuginfo may exist even if there is no .symtab/.dynsym and therefore
SYMSCN == NULL.
Attached such example.
echo 'int main (void) { return 0; }' >3.c
gcc -o 3 3.c -Wall -static -s
objcopy --add-section
.gnu_debugdata=/path/to/gdb/testsuite/gdb.base/gnu-debugdata.mini_debuginfo.xz 3
GDB in such cas displays symbols from minidebuginfo correctly (it complains
a bit as this testcase is unclean but the purpose works).
But dwfl_module_getsymtab() returns 0.
Right. The code indeed assumes that the auxiliary table is always in addition to a
minimal dynsym table. Thanks for the testcase, I can see if it is easy to support it with
aux table == full table.
I do wonder how realistic it is that we will ever encounter such a case though. Is
this very contrived or do you think people will actually use .gnu_debugdata this way?
Thanks,
Mark