[testsuite,ppc64] +kfail: gdb_target_symbol does not support function descriptors

  Hi,

Marin Cermak has found various testcases (or one of them) of GDB FAIL on
ppc64.

https://sourceware.org/bugzilla/show_bug.cgi?id=20328
# powerpc64-unknown-linux-gnu:
# FAIL: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
# FAIL: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
# FAIL: gdb.dwarf2/dw2-lexical-block-bare.exp: p testvar
# FAIL: gdb.dwarf2/atomic-type.exp: ptype f
# 
# but:
# powerpc64le-unknown-linux-gnu does PASS them (ppc64le does not use function
# descriptors anymore)

I do not see how to really fix it, DWARF needs to contain PC addresses, not
function descriptor addresses.  But .o contains only the function descriptor
address.

The DWARF as produced by Tcl Dwarf::assemble:
 <1><27>: Abbrev Number: 4 (DW_TAG_subprogram)
    <28>   DW_AT_name        : main     
    <2d>   DW_AT_external    : 1        
    <2e>   DW_AT_low_pc      : 0x1001ff98       
    <36>   DW_AT_high_pc     : 0x1002ff98       
 <2><3e>: Abbrev Number: 5 (DW_TAG_lexical_block)

Runtime info:
$2 = {<text variable, no debug info>} 0x10000674 <.main>
$3 = {void ()} 0x1001ff98 <main>

I haven't tried to use for DW_AT_low_pc (normally using DW_FORM_addr) to use
DW_FORM_block* with DW_OP_deref as IIRC that is unsupported by GDB's
dwarf2read.c et al.; if anyone thinks it could work I can try that.

Also I am not sure whether "powerpc64-*linux*" really catches all and only all
function descriptor platforms.

OK for check-in?


Jan
gdb/testsuite/ChangeLog
2016-07-05  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.dwarf2/atomic-type.exp (ptype f): Add kfail testsuite/20328.
	* gdb.dwarf2/dw2-bad-mips-linkage-name.exp (ptype f, ptype g): Likewise.
	* gdb.dwarf2/dw2-lexical-block-bare.exp (p testvar): Likewise.
  

On Tue, Jul 5, 2016 at 3:54 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> Marin Cermak has found various testcases (or one of them) of GDB FAIL on
> ppc64.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=20328
> # powerpc64-unknown-linux-gnu:
> # FAIL: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
> # FAIL: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
> # FAIL: gdb.dwarf2/dw2-lexical-block-bare.exp: p testvar
> # FAIL: gdb.dwarf2/atomic-type.exp: ptype f
> #
> # but:
> # powerpc64le-unknown-linux-gnu does PASS them (ppc64le does not use function
> # descriptors anymore)
>
> I do not see how to really fix it, DWARF needs to contain PC addresses, not
> function descriptor addresses.  But .o contains only the function descriptor
> address.

In ppc64 ELFv1 abi, symbol "f" is the address of function descriptor,
symbol ".f"
is the address of function entry.  If we hack
gdb.dwarf2/dw2-bad-mips-linkage-name.exp like this,  "f" -> ".f", and
"g" -> ".g",

            DW_TAG_subprogram {
                {name f}
                {low_pc [gdb_target_symbol .f] addr}
                {high_pc f_end_lbl addr}
                {type :$b_l}
                {DW_AT_MIPS_linkage_name _Z1fv}
            }
            DW_TAG_subprogram {
                {name g}
                {low_pc [gdb_target_symbol .g] addr}
                {high_pc g_end_lbl addr}
                {type :$b_l}
                {DW_AT_MIPS_linkage_name 42 DW_FORM_data1}
            }

the tests pass.  The right fix would be teaching proc gdb_target_symbol to add
prefix "." to symbol if target is powerpc64 and abi is ELFv1, in which function
descriptor is used.
  

On Wed, 06 Jul 2016 09:51:15 +0200, Yao Qi wrote:
> If we hack gdb.dwarf2/dw2-bad-mips-linkage-name.exp like this,  "f" -> ".f",
> and "g" -> ".g",

OK, I didn't realize that the ".dotted" synthetic symbols can be used even in
as/ld, not just inside GDB.


> The right fix would be teaching proc gdb_target_symbol to add
> prefix "." to symbol if target is powerpc64 and abi is ELFv1, in which function
> descriptor is used.

Now the question is how to detect that.  I used "powerpc64-*linux*" target
match in my patch but I guess that is not right.  Maybe it could compile first
something and check if ".somesymbol" exists.


Thanks,
Jan