Re: Two debug entries for one local variables, is it a bug in GCC or GDB

[Daniel Berlin <dberlin@dberlin.org>]

Your bug was not a real bug, AFAICT.
At least the debug info you have shown in
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html is not wrong.
Certainly, two DIES were unnecessary, but the way it did it was not broken.
Note that one of them is marked as DW_AT_declaration, specifying that
is where the declaration of that variable occurred.
The other is a definition.

They happen to be at the same line, so it's pointless to create two
DIE's, but it's not broken.

In this case, the debug information asmwarrior is showing is clearly broken.
I suspect GCC is splitting the variable somehow, because if you
notice, templateArgument is given different memory locations in both
blocks.


On Fri, Jul 9, 2010 at 1:58 AM, Nenad Vukicevic <nenad@intrepid.com> wrote:
>  I reported something similar back in January:
>
> http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html
>
> As I recall, GCC creates duplicates.
>
> Nenad
>
> On 7/8/10 7:33 PM, asmwarrior wrote:
>>
>>  I have post this message to both GCC and GDB, because I'm not sure it is
>> a bug in GDB or GCC.
>> Hi, I have just find two dwarf debug entries for one local variables.
>>
>> For example, the sample code is just like:
>>
>> -----------------------------------------
>>
>> wxString ParserThread::ReadAncestorList()
>> {
>>
>>    wxString ccc;
>>    wxString templateArgument;
>>    wxString aaa;
>>    aaa = m_Tokenizer.GetToken(); // eat ":"
>>    templateArgument = aaa;
>>    while (!TestDestroy())
>>    {
>>
>>        //Peek the next token
>>        wxString next = m_Tokenizer.PeekToken();
>>
>>        if (next.IsEmpty()
>>            || next==ParserConsts::opbrace
>>            || next==ParserConsts::semicolon ) // here, we are at the end
>> of ancestor list
>>        {
>>            break;
>>        }
>>        else if (next==ParserConsts::lt)       // class AAA : BBB<  int,
>> float>
>>        {
>>            wxString arg = SkipAngleBraces();
>>            if(!arg.IsEmpty())                 // find a matching<>
>>            {
>>                templateArgument<<arg;
>>            }
>>            else
>>            {
>>                TRACE(_T("Not Matching<>  find. Error!!!") );
>>            }
>>        }
>> ...
>> -------------------------------------------
>>
>> But I found that GDG can show the wxString aaa correctly, but wxString
>> templateArgument incorrectly.
>>
>> I have just check the debug information in the object file.
>> and found that there are two entries for local variable
>> "argumentTemplate", but only one entry for "aaa".
>>
>> --------------------------------------------
>> <2><40a9f>: Abbrev Number: 182 (DW_TAG_variable)
>> <40aa1>    DW_AT_name        : (indirect string, offset: 0x1095):
>> templateArgument
>> <40aa5>    DW_AT_decl_file   : 19
>> <40aa6>    DW_AT_decl_line   : 2593
>> <40aa8>    DW_AT_type        :<0xd168>
>> <40aac>    DW_AT_accessibility: 3    (private)
>> <40aad>    DW_AT_location    : 2 byte block: 53 6     (DW_OP_reg3;
>> DW_OP_deref)
>> <2><40ab0>: Abbrev Number: 164 (DW_TAG_lexical_block)
>> <40ab2>    DW_AT_ranges      : 0x168
>> <3><40ab6>: Abbrev Number: 165 (DW_TAG_variable)
>> <40ab8>    DW_AT_name        : ccc
>> <40abc>    DW_AT_decl_file   : 19
>> <40abd>    DW_AT_decl_line   : 2592
>> <40abf>    DW_AT_type        :<0xd168>
>> <40ac3>    DW_AT_location    : 2 byte block: 91 50     (DW_OP_fbreg: -48)
>> <3><40ac6>: Abbrev Number: 179 (DW_TAG_variable)
>> <40ac8>    DW_AT_name        : (indirect string, offset: 0x1095):
>> templateArgument
>> <40acc>    DW_AT_decl_file   : 19
>> <40acd>    DW_AT_decl_line   : 2593
>> <40acf>    DW_AT_type        :<0xd168>
>> <40ad3>    DW_AT_location    : 2 byte block: 91 4c     (DW_OP_fbreg: -52)
>> <3><40ad6>: Abbrev Number: 165 (DW_TAG_variable)
>> <40ad8>    DW_AT_name        : aaa
>> <40adc>    DW_AT_decl_file   : 19
>> <40add>    DW_AT_decl_line   : 2594
>> <40adf>    DW_AT_type        :<0xd168>
>> <40ae3>    DW_AT_location    : 2 byte block: 91 48     (DW_OP_fbreg: -56)
>> <3><40ae6>: Abbrev Number: 170 (DW_TAG_lexical_block)
>>
>>
>> ------------------------------------------------------------------------------
>> Also, you can see the screen shot in my Codeblocks forums' post:
>>
>> http://forums.codeblocks.org/index.php/topic,12873.msg86906.html#msg86906
>>
>>
>> So, my question is:
>>
>> Is this a bug in GCC or GDB? ( I have just test the MinGW GCC 4.5 and
>> MinGW 4.4.4, they get the same result)
>>
>>
>> Thanks
>>
>> Asmwarrior (ollydbg from codeblocks' forum)
>>
>