[2/2] Fix implptr-optimized-out.exp fail in thumb mode

  Hi,
I see the fail in gdb.dwarf2/implptr-optimized-out.exp in thumb mode

(gdb) p p->f^M
No symbol "p" in current context.^M
(gdb) FAIL: gdb.dwarf2/implptr-optimized-out.exp: p p->f

In thumb mode, the lsb of references to 'main' in the assembly
(produced by dwarf assember) is set, so the generated debug
information is incorrect.

in this patch, we add a label main_label inside function main.  Linker
doesn't set its lsb in thumb mode, and we can get function main's
address by 'main_label - $main_label_offset'.

gdb/testsuite:

2014-09-29  Yao Qi  <yao@codesourcery.com>

	* gdb.dwarf2/implptr-optimized-out.exp: Compile main.c to object.
	Calculate the offset of main_label to main.  Compile the generated
	asm file and link the executable.
	(Dwarf::assemble): Get address of main by
	main_label - $main_label_offset.
---
 gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp | 39 ++++++++++++++++++++--
 1 file changed, 36 insertions(+), 3 deletions(-)
  

On 09/29/2014 01:52 AM, Yao Qi wrote:
> Hi,
> I see the fail in gdb.dwarf2/implptr-optimized-out.exp in thumb mode
> 
> (gdb) p p->f^M
> No symbol "p" in current context.^M
> (gdb) FAIL: gdb.dwarf2/implptr-optimized-out.exp: p p->f
> 
> In thumb mode, the lsb of references to 'main' in the assembly
> (produced by dwarf assember) is set, so the generated debug
> information is incorrect.
> 
> in this patch, we add a label main_label inside function main.

Hmm, I think I'm missing something.  I'm not where this "main_label"
label is coming from?

Thanks,
Pedro Alves
  

Pedro Alves <palves@redhat.com> writes:

> Hmm, I think I'm missing something.  I'm not where this "main_label"
> label is coming from?

Ur... main_label is added by this patch
https://sourceware.org/ml/gdb-patches/2014-09/msg00497.html which is
pending for review too.  I forget to mention that this patch depends on
the gdb.dwarf2/dwz.exp patch, sorry.
  

On Sun, Sep 28, 2014 at 8:52 PM, Yao Qi <yao@codesourcery.com> wrote:
> Hi,
> I see the fail in gdb.dwarf2/implptr-optimized-out.exp in thumb mode
>
> (gdb) p p->f^M
> No symbol "p" in current context.^M
> (gdb) FAIL: gdb.dwarf2/implptr-optimized-out.exp: p p->f
>
> In thumb mode, the lsb of references to 'main' in the assembly
> (produced by dwarf assember) is set, so the generated debug
> information is incorrect.
>
> in this patch, we add a label main_label inside function main.  Linker
> doesn't set its lsb in thumb mode, and we can get function main's
> address by 'main_label - $main_label_offset'.
>
> gdb/testsuite:
>
> 2014-09-29  Yao Qi  <yao@codesourcery.com>
>
>         * gdb.dwarf2/implptr-optimized-out.exp: Compile main.c to object.
>         Calculate the offset of main_label to main.  Compile the generated
>         asm file and link the executable.
>         (Dwarf::assemble): Get address of main by
>         main_label - $main_label_offset.
> ---
>  gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp | 39 ++++++++++++++++++++--
>  1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp b/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp
> index 649f52d..534bed0 100644
> --- a/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp
> +++ b/gdb/testsuite/gdb.dwarf2/implptr-optimized-out.exp
> @@ -22,9 +22,35 @@ if {![dwarf2_support]} {
>  standard_testfile main.c .S
>  set executable ${testfile}
>
> +if  {[gdb_compile ${srcdir}/${subdir}/${srcfile} ${binfile}1.o \
> +         object {}] != ""} {
> +    return -1
> +}
> +# Start GDB and load object file, compute the offset from main to
> +# main_label which are needed in the Dwarf Assembler below.
> +clean_restart ${binfile}1.o
> +
> +set main_label_offset ""
> +set test "p main_label - main"
> +gdb_test_multiple $test $test {
> +    -re ".* = ($decimal)\r\n$gdb_prompt $" {
> +       set main_label_offset $expect_out(1,string)
> +    }
> +}
> +
> +if { $main_label_offset == "" } {
> +    # Bail out here, because we can't do the following tests if
> +    # $main_label_offset is unknown.
> +    return -1
> +}
> +
> +gdb_exit
> +
>  # Create the DWARF.
>  set asm_file [standard_output_file $srcfile2]
>  Dwarf::assemble $asm_file {
> +    global main_label_offset
> +
>      cu { version 3 } {
>         compile_unit {
>             {producer "GNU C 4.4.3"}
> @@ -52,8 +78,8 @@ Dwarf::assemble $asm_file {
>
>             subprogram {
>                 {name main}
> -               {low_pc main addr}
> -               {high_pc main+0x100 addr}
> +               {low_pc "main_label - $main_label_offset" addr}
> +               {high_pc "main_label - $main_label_offset + 0x100" addr}
>                 {type :$int_label}
>                 {external 1 flag}
>             } {
> @@ -80,10 +106,17 @@ Dwarf::assemble $asm_file {
>      }
>  }
>
> -if [prepare_for_testing ${testfile}.exp $executable "${asm_file} ${srcfile}" {}] {
> +if  {[gdb_compile $asm_file ${binfile}0.o object {}] != ""} {
>      return -1
>  }
>
> +if  {[gdb_compile [list ${binfile}0.o ${binfile}1.o] \
> +         "${binfile}" executable {}] != ""} {
> +    return -1
> +}
> +
> +clean_restart ${testfile}
> +
>  # DW_OP_GNU_implicit_pointer implementation requires a valid frame.
>  if ![runto_main] {
>      return -1

Hi.

One question that comes to mind is: If this solution is going to
proliferate it would be good to convince ourselves there's no better
solution.  I'm ok with this as a one-off here and there, but I'd like
to understand how many more of these will there be.  Plus I can
imagine of course the number growing over time.
Can we, for example, enhance the dwarf assembler and provide a hook
for the thumb target to use to fix this there?

But *if* we do decide there's no better solution, there's a lot of
boilerplate here.
Can we tuck it away in a utility?
  

Doug Evans <dje@google.com> writes:

> One question that comes to mind is: If this solution is going to
> proliferate it would be good to convince ourselves there's no better
> solution.  I'm ok with this as a one-off here and there, but I'd like
> to understand how many more of these will there be.  Plus I can
> imagine of course the number growing over time.

There are three, dwz.exp, implptr-optimized-out.exp and
dw2-ifort-parameter.exp, but you are right, the number will grow.

> Can we, for example, enhance the dwarf assembler and provide a hook
> for the thumb target to use to fix this there?

ppc64 target has the similar problem too.  We need a way suitable for
{thumb, ppc64, other} x {gcc, clang}.

Hacking dwarf assembler doesn't help much, because we are still unable
to get the right function address.

>
> But *if* we do decide there's no better solution, there's a lot of
> boilerplate here.

Let me list the solutions I thought about and tried, so that we can
evaluate which one is the best.

 - Tweak dwarf assembler to generate assembly debug info together with
   __thumb__ and __thumb2__, like

   #if defined (__thumb__) || defined (__thumb2__)
   .uleb128        main-1            /* DW_AT_low_pc */
   #else
   .uleb128        main              /* DW_AT_low_pc */
   #endif

   this doesn't work because main in "main-1" is resolved to the function
   address (without lsb set).  Unfortunately, "main-1+1" is resolved to
   the function address *with* lsb set.

 - The approach I proposed here, which should fix the problem on ppc64
   (I didn't verify that on the real hardware).

 - Fix ld that stop setting function address lsb if they are in debug
   info.  I didn't try.

 - Make use of local symbols.  I find gcc/clang generates local symbol on the
   entry of the function but looks "-Wa,-L" doesn't keep them.