problem while probing the local variables

problem while probing the local variables

[chansarav]

Hi,

I am porting gdb (7.3.1) for the first time to a 32 bit VLIW
architecture. I have added the bfd files, architecture descriptions
files by studying the reference ports. Now the ported gdb is able to
do the following basic operations:

1. Inserting/removing breakpoints
2. probing the global variables at a particular breakpoint

But I face problem while probing the local variables during execution
at a particular breakpoint. (Note: I build the application for debug
mode in which no optimization is performed by the compiler tool
chain).

Please consider the following example case:

1 . #define N 1000
2 .
3 . int global_var1 = 0;
4 . int global_var2 = 1;
5 .
6 . void func (int arg)
7 . {
8 .   global_var2 = arg;
9 . }
10.
11. int main()
12. {
13.   int i;
14.   int result = 0;
15.   int A[N];
16.
17.   global_var1 = 2;
18.
19.   for (i=0; i<N; i++)
20.   {
21.     result += i*10;
22.     A[i] = result;
23.   }
24.
25.   func (result);
26.
27.   global_var1 = result;
28.
29.   return 0;
30. }


When I break the exection at line 27 and print the local variable
'result', gdb says "No symbol "result" in current context.".

And on issuing the "info scope main", gdb says "Symbol i is Unexpected
opcode after DW_OP_breg0 for symbol "i"."

On analyzing on this issue I found the following:

1. Currently the compiler tool chain generates the ELF files only with
allocable sections (data and code). The non-allocable sections are not
included in the ELF file generated. Hence the symbol table information
is missing. Will this hinder the debugging by gdb?

2. On debugging for the message "Symbol i is Unexpected opcode after
DW_OP_breg0 for symbol "i".", I found that in function
locexpr_describe_location_piece () of dwarf2loc.c, the frame_offset
for symbol 'i' is being read correctly. But problem comes out in the
following piece of code:

-- cut --
      if (base_data[0] >= DW_OP_breg0 && base_data[0] <= DW_OP_breg31)
        {
          const gdb_byte *buf_end;

          frame_reg = base_data[0] - DW_OP_breg0;
          buf_end = read_sleb128 (base_data + 1,
                                  base_data + base_size, &base_offset);
          if (buf_end != base_data + base_size)
            error (_("Unexpected opcode after "
                     "DW_OP_breg%u for symbol \"%s\"."),
                   frame_reg, SYMBOL_PRINT_NAME (symbol));
        }
-- cut --
Function: locexpr_describe_location_piece ()
File: dwarf2loc.c

From this I get the understanding of that there could be problem with
the dwarf information generated. I should check the dwarf information
generated regarding this issue. Is my understanding correct?

3. On debugging for the message "No symbol "result" in current
context.", I found that in function parse_exp_in_context () of file
parse.c the exception is thrown by 'lang->la_parser ()'. I couldn't
understand what goes wrong here. Could anyone direct me on this?

Thanks,
Chandra Kumar R.

Re: problem while probing the local variables

[Tom Tromey]

>>>>> ">" == chansarav  <chansarav@gmail.com> writes:

>> 1. Currently the compiler tool chain generates the ELF files only with
>> allocable sections (data and code). The non-allocable sections are not
>> included in the ELF file generated. Hence the symbol table information
>> is missing. Will this hinder the debugging by gdb?

I don't really know the answer to this one, sorry.
I suspect it will hurt.

>> 2. On debugging for the message "Symbol i is Unexpected opcode after
>> DW_OP_breg0 for symbol "i".", I found that in function
>> locexpr_describe_location_piece () of dwarf2loc.c, the frame_offset
>> for symbol 'i' is being read correctly. But problem comes out in the
>> following piece of code:

>> From this I get the understanding of that there could be problem with
>> the dwarf information generated. I should check the dwarf information
>> generated regarding this issue. Is my understanding correct?

Yes, check the DWARF.

>> 3. On debugging for the message "No symbol "result" in current
>> context.", I found that in function parse_exp_in_context () of file
>> parse.c the exception is thrown by 'lang->la_parser ()'. I couldn't
>> understand what goes wrong here. Could anyone direct me on this?

This is a complicated area.

I would say that for a missing symbol your best bet is to start by
debugging the DWARF reading.  This is most likely where things go wrong.
But, there are many possible ways it could fail.  For example, I've been
debugging problems like this recently, where the problem was that gdb
ended up choosing the wrong block to search.

Tom