support for compilation units with discontiguous address ranges? (.debug_ranges)

support for compilation units with discontiguous address ranges? (.debug_ranges)

[Brian Grant]

Has anyone implemented dwarf2 support in gdb for compilation units with 
discontiguous ranges of addresses?  gcc 3.x doesn't seem to produce
.debug_ranges and gdb 5.0 doesn't read it at all. gdb also seems to
ignore .debug_aranges.

What I've tried to do is to put different functions in the same C file into 
different text sections using gcc as follows:

foobar.c:
__attribute__((section(".text1"))) void foo() {...}
__attribute__((section(".text2"))) void bar() {...}

In the executable, they are located something like:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
...
  2 .text1        0000a688  00ec5800  00ec5800  000001b4  2**10
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .text2        0000ee58  00ed5800  00ed5800  0000a83c  2**10
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
...

What currently happens in gdb is that all functions in .text1 
and .text2 at addresses between foo() and bar() are attributed
the file and line number of the last line of foo(). Their real,
accurate line-number info is overshadowed completely.

I noticed that gcc doesn't produce DW_AT_low_pc/high_pc fields for
foobar.c, as it normally would for a DW_TAG_compilation_unit record,
where all functions in the compilation unit were in the same section.
Does anyone know of a workaround for this problem?

--Brian Grant
  Transmeta Corp.

Re: support for compilation units with discontiguous address ranges? (.debug_ranges)

[Jim Blandy]

Brian Grant <grant@transmeta.com> writes:
> Has anyone implemented dwarf2 support in gdb for compilation units with 
> discontiguous ranges of addresses?

No.  Patches are welcome!

> gcc 3.x doesn't seem to produce .debug_ranges and gdb 5.0 doesn't
> read it at all. gdb also seems to ignore .debug_aranges.

That's right.

> What currently happens in gdb is that all functions in .text1 
> and .text2 at addresses between foo() and bar() are attributed
> the file and line number of the last line of foo(). Their real,
> accurate line-number info is overshadowed completely.

Right --- GDB misidentifies which compilation unit they belong to, so
it never looks at the right compilation units' line tables.

> I noticed that gcc doesn't produce DW_AT_low_pc/high_pc fields for
> foobar.c, as it normally would for a DW_TAG_compilation_unit record,
> where all functions in the compilation unit were in the same
> section.

Right, that's as required by the Dwarf 2 spec:

        The presence of low and high pc attributes in a compilation
        unit entry imply that the code generated for that compilation
        unit is contiguous and exists totally within the boundaries
        specified by those two attributes.  If that is not the case,
        no low and high pc attributes should be produced.

The Dwarf 2.1 spec says something similar.

> Does anyone know of a workaround for this problem?

I can only think of two options:

1) Don't do that.  Put functions that need to go in separate segments
   in separate .c files.

2) Implement DW_AT_ranges support in GCC and GDB.

Re: support for compilation units with discontiguous address ranges? (.debug_ranges)

[Daniel Berlin]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Brian Grant <grant@transmeta.com> writes:
>> Has anyone implemented dwarf2 support in gdb for compilation units with 
>> discontiguous ranges of addresses?
> 
> No.  Patches are welcome!
> 
>> gcc 3.x doesn't seem to produce .debug_ranges and gdb 5.0 doesn't
>> read it at all. gdb also seems to ignore .debug_aranges.
> 
> That's right.
> 
>> What currently happens in gdb is that all functions in .text1 
>> and .text2 at addresses between foo() and bar() are attributed
>> the file and line number of the last line of foo(). Their real,
>> accurate line-number info is overshadowed completely.
> 
> Right --- GDB misidentifies which compilation unit they belong to, so
> it never looks at the right compilation units' line tables.
> 
>> I noticed that gcc doesn't produce DW_AT_low_pc/high_pc fields for
>> foobar.c, as it normally would for a DW_TAG_compilation_unit record,
>> where all functions in the compilation unit were in the same
>> section.
> 
> Right, that's as required by the Dwarf 2 spec:
> 
>         The presence of low and high pc attributes in a compilation
>         unit entry imply that the code generated for that compilation
>         unit is contiguous and exists totally within the boundaries
>         specified by those two attributes.  If that is not the case,
>         no low and high pc attributes should be produced.
> 
> The Dwarf 2.1 spec says something similar.
> 
>> Does anyone know of a workaround for this problem?
> 
> I can only think of two options:
> 
> 1) Don't do that.  Put functions that need to go in separate segments
>    in separate .c files.
> 
> 2) Implement DW_AT_ranges support in GCC and GDB.

I have the first part of this done.
I just haven't submitted the patch yet, because i haven't had time to
update hte new dwarf2 reader to support it.


-- 
"When I woke up this morning my girlfriend asked me, "Did you
sleep good?"  I said, "No, I made a few mistakes."
"-Steven Wright

Re: support for compilation units with discontiguous address ranges? (.debug_ranges)

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> I have the first part of this done.
> I just haven't submitted the patch yet, because i haven't had time to
> update hte new dwarf2 reader to support it.

You should post it --- maybe Brian can finish it up.  Just mark it
clearly as work-in-progress.