Re: DWARF question

[Jim Blandy <jimb at codesourcery dot com>]

Carlos Eduardo Seo <cseo at linux.vnet.ibm.com> writes:
> Jim Blandy wrote:
>>
>> What probably happens is that '-readnow' somehow affects the order in
>> which the full symtabs get put in the list.  I'm surprised that
>> breakpoints by line number in both main and the function work, but I
>> guess that has something to do with the nature of the bug in
>> find_line_symtab.
> Here's what I got. The loop  'ALL_SYMTABS' has only one iteration
> because 's->next' is NULL. So it seems that GDB isn't loading the
> other symtab.
>
> When I use '-readnow', both symtabs are there:
>
> (top-gdb) p s->filename
> $6 = 0x106a4930 "init.c"
> (top-gdb) p (s->next)->filename
> $7 = 0x1069cf10 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crti.S"
> (top-gdb) p ((s->next)->next)->filename
> $8 = 0x1069cc60 "test-main.f"
> (top-gdb) p (((s->next)->next)->next)->filename
> $9 = 0x1069c280 "test-main.f"
> (top-gdb) p ((((s->next)->next)->next)->next)->filename
> $10 = 0x1068d5c0 "crtsavres.S"
> (top-gdb) p (((((s->next)->next)->next)->next)->next)->filename
> $11 = 0x1068d2a0 "/usr/src/packages/BUILD/glibc-2.4/cc-nptl/csu/crtn.S"
> (top-gdb) p (((((s->next)->next)->next)->next)->next)->next
> $17 = (struct symtab *) 0x0
>
> And the loop 'ALL_SYMTABS' work. So, it looks like the bug isn't in
> this function. I'm going to look at where GDB populates the symtabs
> list now.
>
> Any thoughts?

(Vlad, this touches on some of the multi-breakpoint code.  If you're
interested, I'm using example code I posted up-thread.)

I think I see the problem.  First, check this out:

    (gdb) break 20
    No line 20 in file "1s2c.c".
    (gdb) break 10
    Breakpoint 1 at 0x80483a1: file 1s2c.c, line 10.
    (gdb) break 20
    Breakpoint 2 at 0x80483c6: file 1s2c.c, line 20.
    (gdb) 

So, for some reason setting a breakpoint on line 10 reads in both
symtabs, but setting one in line 20 does not.

What's going on is as follows:

When we type 'break 20', GDB needs to know what source file we're
referring to.  select_source_symtab says:

  /* Make the default place to list be the function `main'
     if one exists.  */
  if (lookup_symbol (main_name (), 0, VAR_DOMAIN, 0, NULL))
    ...

So this brings in full symbols for whatever compilation unit contains
'main'.  However, that symtab doesn't have a line 20, so the command
fails.

When we type 'break 10', main's symtab does have a line 10, so we
succeed.  However, we then call expand_line_sal (added as part of
Vlad's new multi-location breakpoint code), which reads in full
symbols for all partial symbol tables with the given name ---
including the one that does have a line 20.

Thus, when we type 'break 20' the second time, the loop in
find_line_symtab does have a second symtab to search, and the search
succeeds.

As for the fix, it seems to me that if find_line_symtab can't find a
match in the symtabs currently loaded, it should expand partial symbol
tables with the same name as the given symtab one by one until it
either finds one that does have the line we're looking for, or it runs
out of plausible psymtabs to try.

Even when find_line_common does return a line number, if it sets
*exact_match is zero, I think find_line_symtab should proceed to
expand psymtabs.  Otherwise, if the first symtab we happen to find has
line numbers higher than the one we're looking for, but some unread
symtab has an exact match, we'll just return the first line number in
the symtab we've got.