Question about Dwarf2 for VLIW processor

Question about Dwarf2 for VLIW processor

[wangjiong]

Dear all:

        Suppose I have a c file example.c, the 15th line is " int i=1 "
 
        ...
        ...

        int i=1;    // the 15th line

        ...
        ...

       And this statement corresponds to two instruction groups, the first 
instruction group ranges from from 0x800003c5 to 0x800003ca and the second 
from 0x800003cb to 0x800003cf.

       But the dwarf2 information of the line range generated is:

         Special opcode 89: advance Address by 6 to 0x800003bd and Line by 
0 to 14
         Special opcode 6: advance Address by 0 to 0x800003bd and Line by 
1 to 15           ****
        Special opcode 117: advance Address by 8 to 0x800003c5 and Line by 
0 to 15         ****  These three lines should be compressed to one ???
        Special opcode 89: advance Address by 6 to 0x800003cb and Line by 
0 to 15          ****
        Special opcode 76: advance Address by 5 to 0x800003d0 and Line by 
1 to 16

      that is one line for each instruction group which should be one 
statement. 
 
      so gdb will think the statement "int i=1" is from 0x800003c5 to 
0x800003cb which should be 0x800003c5 to 0x800003cf.

      How should I handle this situation, wish your advice .
 

Wang Jiong 

  tel:2254

Re: Question about Dwarf2 for VLIW processor

[Joel Brobecker]

It usually helps to know which version of GDB you are using, just in
case we know the problem is already fixed in more recent versions.

>       so gdb will think the statement "int i=1" is from 0x800003c5 to 
> 0x800003cb which should be 0x800003c5 to 0x800003cf.
> 
>       How should I handle this situation, wish your advice .

Can you tell us more about the problem that you have (ie the actual
external symptoms)? Does GDB stop at the wrong location after you
do a "next"?

-- 
Joel

Re: Question about Dwarf2 for VLIW processor

[wangjiong]

Dear Joel:

        I am using GDB6.1.1

        GDB did not stop at the wrong location now, but I have see that 
the function:

        find_pc_line_pc_range (stop_pc, &step_range_start, 
&step_range_end) didn`t work correctly.

       when stop_pc is 0x8000035 the returned value of step_range_start 
and step_range_end is

        0x800003c5 and 0x800003cb

        but they should be

        0x800003c5 and 0x800003cf


        I have found all these are because there is something wrong with 
the Dwarf2 .debug_line section. 
        Now every instruction has a entry in this section, maybe it should 
be every c statement.

        Cause I can not modify compiler or assembler now, So I want to 
know How can I solve this problem
        just within GDB.

        Thanks.

 

 
Wang Jiong 

  tel:2254



Joel Brobecker <brobecker@adacore.com> 
2007-11-08 03:16



To
wangjiong@sunnorth.com.cn
cc
gdb@sourceware.org
Subject
Re: Question about Dwarf2 for VLIW processor






It usually helps to know which version of GDB you are using, just in
case we know the problem is already fixed in more recent versions.

>       so gdb will think the statement "int i=1" is from 0x800003c5 to 
> 0x800003cb which should be 0x800003c5 to 0x800003cf.
> 
>       How should I handle this situation, wish your advice .

Can you tell us more about the problem that you have (ie the actual
external symptoms)? Does GDB stop at the wrong location after you
do a "next"?

-- 
Joel

Re: Question about Dwarf2 for VLIW processor

[wangjiong]

Dear Joel:

        I am using GDB6.1.1

        GDB did not stop at the wrong location now, but I have see that 
the function:

        find_pc_line_pc_range (stop_pc, &step_range_start, 
&step_range_end) didn`t work correctly.

       when stop_pc is 0x8000035 the returned value of step_range_start 
and step_range_end is

        0x800003c5 and 0x800003cb

        but they should be

        0x800003c5 and 0x800003cf


        I have found all these are because there is something wrong with 
the Dwarf2 .debug_line section. 
        Now every instruction has a entry in this section, maybe it should 
be every c statement.

        Cause I can not modify compiler or assembler now, So I want to 
know How can I solve this problem
        just within GDB.

        Thanks.

Wang Jiong 

  tel:2254

Re: Question about Dwarf2 for VLIW processor

[Daniel Jacobowitz]

On Thu, Nov 08, 2007 at 09:26:28AM +0800, wangjiong@sunnorth.com.cn wrote:
> Dear Joel:
> 
>         I am using GDB6.1.1
> 
>         GDB did not stop at the wrong location now, but I have see that 
> the function:
> 
>         find_pc_line_pc_range (stop_pc, &step_range_start, 
> &step_range_end) didn`t work correctly.

Why is this behavior not correct?  What problem does it cause?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Question about Dwarf2 for VLIW processor

[wangjiong]

the address range of that line is from 0x800003c5 to 0x800003cf
but what find_pc_line_pc_range returned is from 0x800003c5 to 0x800003cb.

It do not cause problem now, maybe in the future, I am not sure about 
this, any advices?

Thanks.

Wang Jiong 

  tel:2254



Daniel Jacobowitz <drow@false.org> 
2007-11-08 09:41



To
wangjiong@sunnorth.com.cn
cc
gdb@sourceware.org
Subject
Re: Question about Dwarf2 for VLIW processor






On Thu, Nov 08, 2007 at 09:26:28AM +0800, wangjiong@sunnorth.com.cn wrote:
> Dear Joel:
> 
>         I am using GDB6.1.1
> 
>         GDB did not stop at the wrong location now, but I have see that 
> the function:
> 
>         find_pc_line_pc_range (stop_pc, &step_range_start, 
> &step_range_end) didn`t work correctly.

Why is this behavior not correct?  What problem does it cause?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Question about Dwarf2 for VLIW processor

[Joel Brobecker]

> It do not cause problem now, maybe in the future, I am not sure about 
> this, any advices?

It shouldn't actually cause any problem, neither now, nor in the future.
You're correct that the current line table is suboptimal, but GDB should
be able to deal with it.

-- 
Joel