[Bug debug/54887] New: gdb test case failure with mi-var-rtti

[Bug debug/54887] New: gdb test case failure with mi-var-rtti

[arnez at linux dot vnet.ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

             Bug #: 54887
           Summary: gdb test case failure with mi-var-rtti
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: arnez@linux.vnet.ibm.com


Current upstream gcc causes a regression with the gdb test case
mi-var-rtti.exp:
FAIL: gdb.mi/mi-var-rtti.exp: create varobj for ptr (without RTTI) in
use_rtti_for_ptr
...

Here's a link to the C++ source:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/testsuite/gdb.mi/mi-var-rtti.cc?rev=1.1&cvsroot=src

The test case sets a breakpoint in use_rtti_for_ptr_test() on the last
variable declaration ('constPtrConst', line 37) and then advances with
'next' to the return statement.  There it tries to access the variable
'ptr', but the 'next' already carried us into the epilogue beyond that
variable's lexical block.  This is because the line number information
now places the return statement _after_ everything else, even after
the destructor call for 'd'.

I've verified the failure on x86_64 and s390x.  The regression was
introduced by: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191338

[Bug debug/54887] gdb test case failure with mi-var-rtti

[dehao at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

--- Comment #1 from dehao at gcc dot gnu.org 2012-10-10 15:47:47 UTC ---
I think r192285 already solve the problem. Could you help verify that?

Thanks,
Dehao

[Bug debug/54887] gdb test case failure with mi-var-rtti

[arnez at linux dot vnet.ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

--- Comment #2 from Andreas Arnez <arnez at linux dot vnet.ibm.com> 2012-10-10 17:14:32 UTC ---
Right. I've checked that the new upstream gcc with r192285 fixes the problem. 
Thanks!

BTW, while investigating this I wondered why g++ wraps all locals in a lexical
block instead of attaching them directly to the subprogram DIE.  Is there a
particular reason for that?

[Bug debug/54887] gdb test case failure with mi-var-rtti

[dehao at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

dehao at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from dehao at gcc dot gnu.org 2012-10-10 17:56:56 UTC ---
That should also have been fixed in r192165.

[Bug debug/54887] gdb test case failure with mi-var-rtti

[arnez at linux dot vnet.ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

Andreas Arnez <arnez at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |

--- Comment #4 from Andreas Arnez <arnez at linux dot vnet.ibm.com> 2012-10-11 08:28:52 UTC ---
(In reply to comment #3)
> That should also have been fixed in r192165.

Hm, for the test case above I still see the locals of rtti_for_ptr_test()
wrapped in a lexical block:

 <2><32e>: Abbrev Number: 27 (DW_TAG_lexical_block)
    <32f>   DW_AT_low_pc      : 0x400758
    <337>   DW_AT_high_pc     : 0x38 0x0
 <3><33f>: Abbrev Number: 28 (DW_TAG_variable)
    <340>   DW_AT_name        : d
 ...

Should we follow up on this?

[Bug debug/54887] gdb test case failure with mi-var-rtti

[arnez at linux dot vnet.ibm.com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

--- Comment #5 from Andreas Arnez <arnez at linux dot vnet.ibm.com> 2012-10-24 17:51:44 UTC ---
(In reply to comment #4)

>  <2><32e>: Abbrev Number: 27 (DW_TAG_lexical_block)
>     <32f>   DW_AT_low_pc      : 0x400758
>     <337>   DW_AT_high_pc     : 0x38 0x0
>  <3><33f>: Abbrev Number: 28 (DW_TAG_variable)
>     <340>   DW_AT_name        : d

Such a whole-subprogram lexical block is still generated by mainline gcc at
r192761.  I verified this on x86_64 with use_rtti_for_ptr_test() in
mi-var-rtti.cc.

Note that the lexical block's range is slightly smaller than the subprogram's:
 <1><30d>: Abbrev Number: 26 (DW_TAG_subprogram)
    <30e>   DW_AT_external    : 1       
    <30e>   DW_AT_name        : (indirect string, offset: 0x35f):
use_rtti_for_ptr_test 
    <312>   DW_AT_decl_file   : 1       
    <313>   DW_AT_decl_line   : 30      
    <314>   DW_AT_linkage_name: (indirect string, offset: 0x173):
_Z21use_rtti_for_ptr_testv    
    <318>   DW_AT_low_pc      : 0x400750        
    <320>   DW_AT_high_pc     : 0x42 0x0        
    <328>   DW_AT_frame_base  : 1 byte block: 9c        (DW_OP_call_frame_cfa)
    <32a>   Unknown AT value: 2116: 1   
    <32a>   DW_AT_sibling     : <0x386> 
 <2><32e>: Abbrev Number: 27 (DW_TAG_lexical_block)
    <32f>   DW_AT_low_pc      : 0x400758        
    <337>   DW_AT_high_pc     : 0x38 0x0        

Is this expected or not?  If needed, I can open a separate Bugzilla for this.

[Bug debug/54887] gdb test case failure with mi-var-rtti

[dehao at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

--- Comment #6 from dehao at gcc dot gnu.org 2012-10-24 17:56:32 UTC ---
I'll take a look at this case today.

[Bug debug/54887] gdb test case failure with mi-var-rtti

[dehao at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54887

--- Comment #7 from dehao at gcc dot gnu.org 2012-10-24 21:25:24 UTC ---
I looked at this. Looks like even before r191494, this lexical block was there
already. So I'd think this is as expected.

Dehao