[Bug symtab/15028] New: regressions with dwz -m

[Bug symtab/15028] New: regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

             Bug #: 15028
           Summary: regressions with dwz -m
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
        AssignedTo: unassigned@sourceware.org
        ReportedBy: tromey@redhat.com
    Classification: Unclassified


There are some test suite regressions using dwz -m:

gdb.base/completion.exp: complete ptype enum some_: PASS => FAIL
gdb.cp/derivation.exp: p (A::value_type) 0: PASS => FAIL
gdb.cp/derivation.exp: p (D::value_type) 0: PASS => FAIL
gdb.cp/derivation.exp: p (E::value_type) 0: PASS => FAIL
gdb.cp/derivation.exp: p (F::value_type) 0: PASS => FAIL
gdb.cp/derivation.exp: p (Z::value_type) 0: PASS => FAIL
gdb.cp/derivation.exp: p (ZZ::value_type) 0: PASS => FAIL
gdb.cp/derivation.exp: ptype A::value_type: PASS => FAIL
gdb.cp/derivation.exp: ptype D::value_type: PASS => FAIL
gdb.cp/derivation.exp: ptype E::value_type: PASS => FAIL
gdb.cp/derivation.exp: ptype F::value_type: PASS => FAIL
gdb.cp/derivation.exp: ptype Z::value_type: PASS => FAIL
gdb.cp/derivation.exp: ptype ZZ::value_type: PASS => FAIL
gdb.cp/derivation.exp: whatis A::value_type: PASS => FAIL
gdb.cp/derivation.exp: whatis D::value_type: PASS => FAIL
gdb.cp/derivation.exp: whatis E::value_type: PASS => FAIL
gdb.cp/derivation.exp: whatis F::value_type: PASS => FAIL
gdb.cp/derivation.exp: whatis Z::value_type: PASS => FAIL
gdb.cp/derivation.exp: whatis ZZ::value_type: PASS => FAIL

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware    |tromey at redhat dot com
                   |dot org                     |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #1 from Tom Tromey <tromey at redhat dot com> 2013-01-28 16:54:07 UTC ---
The first problem I see here is that the symbols in the
imported psymtab are given language_minimal.
This causes symbol_matches_domain to fail when looking up "A"
in "ptype A::value_type".

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #2 from Tom Tromey <tromey at redhat dot com> 2013-01-28 19:40:11 UTC ---
The completion.exp problem is a mismatch between what dwz
produces and what gdb expects.

dwz makes a DW_TAG_partial_unit holding various types from
break1.c; "some_enum" is there.  This is stored in the .dwz file.
However, nothing imports this unit.  Instead the specific enum
type DIE is referenced from the main file:

 <1><44a>: Abbrev Number: 25 (DW_TAG_variable)
    <44b>   DW_AT_name        : (alt indirect string, offset: 0x219)    
    <44f>   DW_AT_decl_file   : 1    
    <450>   DW_AT_decl_line   : 34    
    <451>   DW_AT_type        : <alt 0x27b>    
    <455>   DW_AT_external    : 1    
    <455>   DW_AT_location    : 9 byte block: 3 c4 f 60 0 0 0 0 0    
(DW_OP_addr: 600fc4)

This approach causes gdb not to make a symbol for the enum.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #3 from Tom Tromey <tromey at redhat dot com> 2013-01-29 18:37:42 UTC ---
Fixing the first problem yields a different regression:

FAIL: gdb.cp/anon-struct.exp: print type of X::t2::t2


This happens because namespace X appears in both the primary
file as:

 <1><2e>: Abbrev Number: 9 (DW_TAG_namespace)
    <2f>   DW_AT_name        : X    
    <31>   DW_AT_decl_file   : 1    
    <32>   DW_AT_decl_line   : 31    
    <33>   DW_AT_sibling     : <0x35>    

and in the .dwz file as:

 <1><68>: Abbrev Number: 10 (DW_TAG_namespace)
    <69>   DW_AT_name        : X    
    <6b>   DW_AT_sibling     : <0x86>    
[children]

... and symbol lookup in gdb picks the wrong one.

This seems reasonably tricky to solve in the general case.

One option might be to get dwz to add DW_AT_extension in this scenario.

Alternatively maybe we could hack around it somehow.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #4 from Tom Tromey <tromey at redhat dot com> 2013-01-30 20:21:47 UTC ---
(In reply to comment #3)

> One option might be to get dwz to add DW_AT_extension in this scenario.

Jakub didn't want to do this.

One option that he pointed out is to assume that all namespaces with
the same name in a given objfile are the same, and merge their contents.
I am not sure this is really correct -- it is in a correct program,
but it may yield weird results in an incorrect program.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #5 from Tom Tromey <tromey at redhat dot com> 2013-02-04 17:24:16 UTC ---
Further debugging show that the namespace regression isn't
actually about the namespace DIEs, but rather the file
name of the "main" function.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #6 from Tom Tromey <tromey at redhat dot com> 2013-02-04 21:12:28 UTC ---
With my various patches in place I see:

gdb.base/dbx.exp: whereis my_list: PASS => FAIL
gdb.cp/namespace.exp: info func xyzq: PASS => FAIL

Both of these are caused by the strange way in which we
invoke dwz -- passing in two identical copies of the same
program.  This means that some objects are duplicated
(once in the .dwz file and another time in the main file,
but usually there with a source location).

It is unclear to me if this kind of thing can ever happen
with a real use of dwz.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #7 from Tom Tromey <tromey at redhat dot com> ---
I see different issues with the current cvs head:

    Regressions:
    gdb.base/completion.exp: complete ptype enum some_: PASS => FAIL
    gdb.base/maint.exp: mt expand-symtabs: PASS => FAIL
    gdb.cp/derivation.exp: ptype N::value_type: PASS => FAIL
    gdb.cp/namespace.exp: print AAA::ALPHA: PASS => FAIL
    gdb.cp/namespace.exp: whatis ::C::cOtherFileType: PASS => FAIL
    gdb.cp/namespace.exp: whatis C::cOtherFileType: PASS => FAIL
    gdb.dwarf2/implptrconst.exp: print *c: PASS => FAIL
    gdb.dwarf2/implptrconst.exp: print d[-2]: PASS => FAIL

    Missing tests:
    gdb.base/fullpath-expand.exp: info source: PASS
    gdb.base/fullpath-expand.exp: list func: PASS
    gdb.base/fullpath-expand.exp: rbreak XXX/fullpath-expand-func.c:func: PASS
    gdb.dwarf2/dw2-restrict.exp: ptype f: PASS
    gdb.linespec/break-ask.exp: 0: PASS
    gdb.linespec/break-ask.exp: 2: PASS
    gdb.linespec/break-ask.exp: 3: PASS
    gdb.linespec/break-ask.exp: break twodup absolute: PASS
    gdb.linespec/break-ask.exp: break twodup relative: PASS
    gdb.linespec/break-ask.exp: break twodup relative other: PASS
    gdb.linespec/break-ask.exp: continue to breakpoint: body_elsewhere: PASS
    gdb.linespec/break-ask.exp: continue to breakpoint: body_elsewhere other:
PASS
    gdb.linespec/break-ask.exp: expect breakpoint: PASS
    gdb.linespec/break-ask.exp: expect breakpoint other: PASS
    gdb.linespec/break-ask.exp: info source: PASS
    gdb.linespec/break-ask.exp: info source other: PASS
    gdb.linespec/break-ask.exp: set filename-display absolute: PASS
    gdb.linespec/break-ask.exp: set filename-display relative: PASS
    gdb.linespec/break-ask.exp: set multiple-symbols ask: PASS
    gdb.linespec/macro-relative.exp: info macro HEADER: PASS

fullpath-expand, break-ask, and macro-relative fail due to test
oddities, like:

    cc-with-tweaks.sh: unable to find usable gdb

This can happen if, e.g., the test case "cd"s into the srcdir.

dw2-restrict fails due to a dwz crash.  I reported this.

    https://bugzilla.redhat.com/show_bug.cgi?id=994658

My original series is still ok -- it doesn't help much with the
current test suite, but it includes at least one new test case
demonstrating a bug.

I haven't investigated the new regressions yet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/15028] regressions with dwz -m

[cvs-commit at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15028

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
CVSROOT:    /cvs/src
Module name:    src
Changes by:    tromey@sourceware.org    2013-08-07 20:10:36

Modified files:
    gdb            : ChangeLog dwarf2read.c 

Log message:
    fix PR symtab/15028

    This fixes some derivation.exp regressions with "dwz -m".

    The bug here is that the imported PU is given language_minimal.
    However, it ought to be C++.

    The "pretend language" machinery exists to solve this problem, but it
    wasn't handled in process_psymtab_comp_unit.  So, this patch adds it
    there.

    Built and regtested, both normally and using "dwz -m", on x86-64
    Fedora 18.

    PR symtab/15028:
    * dwarf2read.c (struct process_psymtab_comp_unit_data): New.
    (process_psymtab_comp_unit_reader): Use it.
    (process_psymtab_comp_unit): Update.  Add "pretend_language"
    argument.
    (dwarf2_build_psymtabs_hard): Update.
    (scan_partial_symbols): Pass CU's language to
    process_psymtab_comp_unit.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.15872&r2=1.15873
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/dwarf2read.c.diff?cvsroot=src&r1=1.823&r2=1.824

-- 
You are receiving this mail because:
You are on the CC list for the bug.