Fix gdb.dwarf2/dwz.exp for thumb mode

  Hi,
We see the fail in gdb.dwarf2/dwz.exp in thumb mode,

p the_int^M
$2 = 99^M
(gdb) FAIL: gdb.dwarf2/dwz.exp: p the_int

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.

This patch copies the approach from

  [PATCH 4/4] Fix gdb.trace/entry-values.exp for thumb mode
  https://sourceware.org/ml/gdb-patches/2014-07/msg00041.html

introduce new label 'main_start' which is the correct
function address (without lsb set).  This patch fixes these
fails we've seen.

Regression tested on arm-none-eabi and x86_64-linux.

gdb/testsuite:

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

	* gdb.dwarf2/dwz.exp: Use main_start instead of main.
	* gdb.dwarf2/main.c: Define label 'main_start' at the beginning
	function 'main'.
---
 gdb/testsuite/gdb.dwarf2/dwz.exp | 4 ++--
 gdb/testsuite/gdb.dwarf2/main.c  | 4 ++++
 2 files changed, 6 insertions(+), 2 deletions(-)
  

On Tue, Sep 2, 2014 at 6:15 PM, Yao Qi <yao@codesourcery.com> wrote:
> Hi,
> We see the fail in gdb.dwarf2/dwz.exp in thumb mode,
>
> p the_int^M
> $2 = 99^M
> (gdb) FAIL: gdb.dwarf2/dwz.exp: p the_int
>
> 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.
>
> This patch copies the approach from
>
>   [PATCH 4/4] Fix gdb.trace/entry-values.exp for thumb mode
>   https://sourceware.org/ml/gdb-patches/2014-07/msg00041.html
>
> introduce new label 'main_start' which is the correct
> function address (without lsb set).  This patch fixes these
> fails we've seen.
>
> Regression tested on arm-none-eabi and x86_64-linux.
>
> gdb/testsuite:
>
> 2014-09-03  Yao Qi  <yao@codesourcery.com>
>
>         * gdb.dwarf2/dwz.exp: Use main_start instead of main.
>         * gdb.dwarf2/main.c: Define label 'main_start' at the beginning
>         function 'main'.
> ---
>  gdb/testsuite/gdb.dwarf2/dwz.exp | 4 ++--
>  gdb/testsuite/gdb.dwarf2/main.c  | 4 ++++
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/dwz.exp b/gdb/testsuite/gdb.dwarf2/dwz.exp
> index 9175f9e..ef19631 100644
> --- a/gdb/testsuite/gdb.dwarf2/dwz.exp
> +++ b/gdb/testsuite/gdb.dwarf2/dwz.exp
> @@ -79,8 +79,8 @@ Dwarf::assemble $asm_file {
>         partial_label: partial_unit {} {
>             subprogram {
>                 {name main}
> -               {low_pc main addr}
> -               {high_pc "main + $main_length" addr}
> +               {low_pc main_start addr}
> +               {high_pc "main_start + $main_length" addr}
>             }
>         }
>      }
> diff --git a/gdb/testsuite/gdb.dwarf2/main.c b/gdb/testsuite/gdb.dwarf2/main.c
> index 3ddd194..5a4cbc3 100644
> --- a/gdb/testsuite/gdb.dwarf2/main.c
> +++ b/gdb/testsuite/gdb.dwarf2/main.c
> @@ -17,6 +17,10 @@
>
>  /* Dummy main function.  */
>
> +asm (".section \".text\"");
> +asm (".balign 8");
> +asm ("main_start: .globl main_start");
> +
>  int
>  main()
>  {

This approach is fragile w.r.t. clang.
IIUC, Clang makes no guarantees about the ordering of global asms and
other objects, or even other objects w.r.t. each other (even at -O0).

The email you refer to above refers to another email,
https://sourceware.org/ml/gdb-patches/2014-03/msg00202.html
and that email does a similar thing to fix dw2-ifort-parameter.exp
(not for thumb, but for similar reasons).

dw2-ifort-parameter.exp currently fails with clang on amd64-linux because
func gets moved after main, but the asms that wrap func stay put.

Loosely speaking,

asm ("func_start:");
void func () {}
asm ("func_end:");
int main () { return 0; }

gets emitted as:

asm ("func_start:");
asm ("func_end:");
int main () { return 0; }
void func () {}

I don't have a solution yet, I'm just giving a "heads up".
  

Doug Evans <dje@google.com> writes:

> This approach is fragile w.r.t. clang.
> IIUC, Clang makes no guarantees about the ordering of global asms and
> other objects, or even other objects w.r.t. each other (even at -O0).

Doug, how about compile main.c to execution first, get the address of
main, write this address down to dwz.S, and recompile main.c with dwz.S
again.  I assume that debug information changes doesn't affect the
location of .text section and main's address.