This is the mail archive of the gdb@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]

Re: problem while probing the local variables


>>>>> ">" == 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


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