Fix register selection in var-access.exp

The new test var-access.exp causes FAILs on i686.  This is because the
test chooses the wrong name for DWARF register number 1: It uses
"edx" (which corresponds to DWARF register number 2), but should have used
"ecx" instead.

Also, the current logic in var-access.exp does not correctly distinguish
between a 64-bit and a 32-bit program on an x86-64 target.  It uses the
64-bit register names for both.

These problems are fixed.  In order to address the latter, the convenience
macros is_*_target are exploited where appropriate.

gdb/testsuite/ChangeLog:

	* gdb.dwarf2/var-access.exp: Use register name ecx instead of edx
	on 32-bit x86 targets.  Exploit is_*_target macros where
	appropriate.
---
 gdb/testsuite/gdb.dwarf2/var-access.exp | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

On 2017-06-13 20:34, Andreas Arnez wrote:
> The new test var-access.exp causes FAILs on i686.  This is because the
> test chooses the wrong name for DWARF register number 1: It uses
> "edx" (which corresponds to DWARF register number 2), but should have 
> used
> "ecx" instead.
> 
> Also, the current logic in var-access.exp does not correctly 
> distinguish
> between a 64-bit and a 32-bit program on an x86-64 target.  It uses the
> 64-bit register names for both.
> 
> These problems are fixed.  In order to address the latter, the 
> convenience
> macros is_*_target are exploited where appropriate.
> 
> gdb/testsuite/ChangeLog:
> 
> 	* gdb.dwarf2/var-access.exp: Use register name ecx instead of edx
> 	on 32-bit x86 targets.  Exploit is_*_target macros where
> 	appropriate.
> ---
>  gdb/testsuite/gdb.dwarf2/var-access.exp | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.dwarf2/var-access.exp
> b/gdb/testsuite/gdb.dwarf2/var-access.exp
> index 157a96c..96c54e7 100644
> --- a/gdb/testsuite/gdb.dwarf2/var-access.exp
> +++ b/gdb/testsuite/gdb.dwarf2/var-access.exp
> @@ -28,16 +28,16 @@ if {![dwarf2_support]} {
> 
>  set dwarf_regnum {0 1}
> 
> -if { [istarget "aarch64*-*-*"] } {
> +if { [is_aarch64_target] } {
>      set regname {x0 x1}
> -} elseif { [istarget "arm*-*-*"]
> +} elseif { [is_aarch32_target]
>  	   || [istarget "s390*-*-*" ]
>  	   || [istarget "powerpc*-*-*"]
>  	   || [istarget "rs6000*-*-aix*"] } {
>      set regname {r0 r1}
> -} elseif { [istarget "i?86-*-*"] } {
> -    set regname {eax edx}
> -} elseif { [istarget "x86_64-*-*"] } {
> +} elseif { [is_x86_like_target] } {
> +    set regname {eax ecx}
> +} elseif { [is_amd64_regs_target] } {
>      set regname {rax rdx}
>  } else {
>      verbose "Skipping tests for accessing DWARF-described variables."

The patch LGTM.

However could you (or somebody else) explain this to me?  The doc of 
is_amd64_regs_target says:

2465 # Return 1 if target has x86_64 registers - either amd64 or x32.
2466 # x32 target identifies as x86_64-*-linux*, therefore it cannot be 
determined
2467 # just from the target string.

If x32 identifies as x86_64-something and that procedure should return 
true when testing with x32 and x86_64/amd64, why can't we test the 
target string for x86_64-*?

On 06/13/2017 09:33 PM, Simon Marchi wrote:

> However could you (or somebody else) explain this to me?  The doc of
> is_amd64_regs_target says:
> 
> 2465 # Return 1 if target has x86_64 registers - either amd64 or x32.
> 2466 # x32 target identifies as x86_64-*-linux*, therefore it cannot be
> determined
> 2467 # just from the target string.
> 
> If x32 identifies as x86_64-something and that procedure should return
> true when testing with x32 and x86_64/amd64, why can't we test the
> target string for x86_64-*?

Some vendors build --target i686-* toolchains, and then
use -m64 to target the 64-bit multilib.

Thanks,
Pedro Alves

On Tue, Jun 13 2017, Pedro Alves wrote:

> On 06/13/2017 09:33 PM, Simon Marchi wrote:
>
>> However could you (or somebody else) explain this to me?  The doc of
>> is_amd64_regs_target says:
>> 
>> 2465 # Return 1 if target has x86_64 registers - either amd64 or x32.
>> 2466 # x32 target identifies as x86_64-*-linux*, therefore it cannot be
>> determined
>> 2467 # just from the target string.
>> 
>> If x32 identifies as x86_64-something and that procedure should return
>> true when testing with x32 and x86_64/amd64, why can't we test the
>> target string for x86_64-*?
>
> Some vendors build --target i686-* toolchains, and then
> use -m64 to target the 64-bit multilib.

Hm, I wasn't aware of that.  In addition, even on an x86_64-* target,
-m32 could be in effect.  IMHO the comment is indeed misleading, but I'd
rather leave it to someone who actually knows all the various x86/amd64
targets and ABIs to fix it.

As this discussion is unrelated to the fix itself and the fix was
approved already, I pushed it now.

Thanks,
Andreas