This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA/DWARF2] Handle nested subprograms in CU pc bound calculation


Hello,

We just recently encountered a situation where GDB was emitting the following
warning:

| (gdb) b f1
| warning: (Internal error: pc 0x80495ce in read in psymtab, but not in symtab.)
| warning: (Internal error: pc 0x80495d1 in read in psymtab, but not in symtab.)
| warning: (Internal error: pc 0x80495d1 in read in psymtab, but not in symtab.)
| warning: (Internal error: pc 0x80495d1 in read in psymtab, but not in symtab.)
| Breakpoint 1 at 0x80495d1: file gen1.adb, line 3.



This happened after compiling the CU with -ffunction-sections, and
is related to the fact that f1 is a nested subprogram.  The code looks
like this:

    procedure Foo is
       procedure F1 is new Gen;
    begin
       ...

Here is what happens:

  1. When compiling with -ffunction-sections, the compiler is not
     providing the CU PC bounds (DW_AT_low_pc and DW_AT_high_pc).
     I would imagine that this is because functions might be removed
     later during the link, and thus bounds might be affected.

  2. As a result, GDB ends up having to compute the PC bounds itself
     by inspecting the children of the CU.  This is done inside
     get_scope_pc_bounds.  However, this function only handles
     non-nested functions.  As a result, after having determined
     the bounds of the main procedure Foo, it goes directly to
     the next sibling of that function, past the two nested
     subprograms.  The net effect is that the low/high PC range
     is too short, missing the range for our nested subprogram.

  3. Later, when the user inserts a breakpoint on the nested
     subprogram, GDB finds symbol f1, converts the associated
     psymtab into a symtab, and then tries to find the first
     "real" line of code, and so ends up searching the symtab
     associated to a PC inside our subprogram.  The search
     among known symtabs fails because of the incorrect PC bounds.
     So the next step is searching through the psymtabs, where
     we find the correct one, and realize that it has already
     been read in, meaning that the previous search should have
     found it -> warning.

The attached patch fixes this problem by handling nested subprograms.
Similarly to what was done earlier, I am limiting this to languages
that allow nested subprogram, which means only Ada for now. Other
languages should be unaffected.

2008-09-30  Joel Brobecker  <brobecker@adacore.com>
  
        * dwarf2read.c (dwarf2_get_subprogram_pc_bounds): New function.
        (get_scope_pc_bounds): Use it.

Tested on x86-linux. No regression. Any objection?

Thanks,
-- 
Joel

Attachment: dwarf2read.c.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]