Re: native hppa2.0w-hp-hpux11.00, 32-bit versus 64-bit

Re: native hppa2.0w-hp-hpux11.00, 32-bit versus 64-bit

[Michael Elizabeth Chastain]

ac> What's the ABI wordsize - the size of a register pushed onto the stack? 
ac> "info registers" should be using that register size and looking at the 
ac> HP/PA code, that appears to be the case.

It's 4 bytes, all right.

ac> It might also pay to check out `file gdb`, `file test-program`, "(gdb) 
ac> show architecture" and "(gdb) maint print registers" to see what's been 
ac> compbined.  At least for other architectures only a 64-bit native 

  /home/mec/bin/gdb-611:  PA-RISC1.1 shared executable dynamically linked -not stripped
  a.out:          PA-RISC2.0 shared executable dynamically linked -not stripped

  (gdb-611) show architecture
  The target architecture is set automatically (currently hppa1.0)

The funny thing is, gdb 6.1.1 "maint print registers" says that
r19 is 4 bytes long, but "info reg r19" has special code to print
all 8 bytes of it.

I'm still kinda dubious, but if it's okay with randolph that the
debugger quietly operates in 32-bit mode, it's okay with me.
I would do something like this:

  gdb_test_multiple "info reg r19" "$name" {
    -re "r19 deadbeefbadcadee ..." {
      pass "$name (64 bit)"
    }
    -re "r19 "badcadee ..." {
      pass "$name (32 bit)"
    }
  }

Michael C

Re: native hppa2.0w-hp-hpux11.00, 32-bit versus 64-bit

[Randolph Chung]

> ac> What's the ABI wordsize - the size of a register pushed onto the stack? 
> ac> "info registers" should be using that register size and looking at the 
> ac> HP/PA code, that appears to be the case.
> 
> It's 4 bytes, all right.

The hppa target naming conventions are a bit weird (to me, at least)

hppa2.0w-*-* is a 32-bit target, however the w means that you can use 
64-bit registers and the pa2.0 64-bit opcodes (ldd, std, etc)

hppa64-*-* is the 64-bit target.

> The funny thing is, gdb 6.1.1 "maint print registers" says that
> r19 is 4 bytes long, but "info reg r19" has special code to print
> all 8 bytes of it.
> 
> I'm still kinda dubious, but if it's okay with randolph that the
> debugger quietly operates in 32-bit mode, it's okay with me.
> I would do something like this:

Yes, i think this is ok.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: native hppa2.0w-hp-hpux11.00, 32-bit versus 64-bit

[Daniel Jacobowitz]

On Sun, Jun 27, 2004 at 11:40:26AM -0700, Randolph Chung wrote:
> > ac> What's the ABI wordsize - the size of a register pushed onto the stack? 
> > ac> "info registers" should be using that register size and looking at the 
> > ac> HP/PA code, that appears to be the case.
> > 
> > It's 4 bytes, all right.
> 
> The hppa target naming conventions are a bit weird (to me, at least)
> 
> hppa2.0w-*-* is a 32-bit target, however the w means that you can use 
> 64-bit registers and the pa2.0 64-bit opcodes (ldd, std, etc)
> 
> hppa64-*-* is the 64-bit target.
> 
> > The funny thing is, gdb 6.1.1 "maint print registers" says that
> > r19 is 4 bytes long, but "info reg r19" has special code to print
> > all 8 bytes of it.
> > 
> > I'm still kinda dubious, but if it's okay with randolph that the
> > debugger quietly operates in 32-bit mode, it's okay with me.
> > I would do something like this:
> 
> Yes, i think this is ok.

If hppa2.0w-*-* is a 32-bit target (pointers, I assume you mean), but
has 64-bit registers, then the regcache for it should indicate that
registers are eight bytes wide... maybe this isn't a regression or a
surprise, but it's definitely better if you show all bits.

-- 
Daniel Jacobowitz

Re: native hppa2.0w-hp-hpux11.00, 32-bit versus 64-bit

[Andrew Cagney]

>>ac> What's the ABI wordsize - the size of a register pushed onto the stack? 
>>> ac> "info registers" should be using that register size and looking at the 
>>> ac> HP/PA code, that appears to be the case.
>>> 
>>> It's 4 bytes, all right.

Lets expand the list (you can get much of this from sizeof.exp):

- sizeof (saved register)
- sizeof (int)
- sizeof (long)
- sizeof (void *)
- sizeof (long long)
- sizeof (ptrace/ktrace register)

> The hppa target naming conventions are a bit weird (to me, at least)

I'm guessing that we're missing one:

hppa1.x executable.  Since michael stated that registers were being 
saved as 4-bytes, I think we're looking at this one.

> hppa2.0w-*-* is a 32-bit target, however the w means that you can use 
> 64-bit registers and the pa2.0 64-bit opcodes (ldd, std, etc)

This is sounding a lot like MIPS N32:

8 - sizeof (saved register)
4 - sizeof (int)
4 - sizeof (long)
4 - sizeof (void *)
8 - sizeof (long long)
8 - sizeof (ptrace/ktrace register)

> hppa64-*-* is the 64-bit target.
> 
> 
>>> The funny thing is, gdb 6.1.1 "maint print registers" says that
>>> r19 is 4 bytes long, but "info reg r19" has special code to print
>>> all 8 bytes of it.
>>> 
>>> I'm still kinda dubious, but if it's okay with randolph that the
>>> debugger quietly operates in 32-bit mode, it's okay with me.
>>> I would do something like this:
> 
> 
> Yes, i think this is ok.

This is getting into 32x64 - there be dragons.

Andrew

native hppa2.0w-hp-hpux11.00, 32-bit versus 64-bit

[Michael Elizabeth Chastain]

We've got this test script to print hp register values,
gdb/testsuite/gdb.hp/gdb.base-hp/reg.exp.  I'm working on it because
the hp register code changed between 6.1 and HEAD.  There's some
cosmetic differences in the results, which are easy for me to fix,
and there's some 32-bit/64-bit changes, which I need help with.

I'm testing with gdb 6.1.1 and with gdb HEAD 2004-06-01.
My gdb's are native hppa2.0w-hp-hpux11.00, and I built them with
gcc 3.3.2 using no special flags.

Here is my actual output:

  # gdb 6.1.1
  # gdb built with gcc 3.3.2, no special flags
  (gdb) info reg r19
  r19 deadbeefbadcadee
  (gdb) print /x $r19
  $1 = 0xbadcadee^M

  # gdb HEAD 2004-06-01
  # gdb built with gcc 3.3.2, no special flags
  (gdb) info reg r19
  r19            0xbadcadee       3135024622
  (gdb) print /x $r19
  $1 = 0xbadcadee^M

The inferior program has used assembly language to build a 64-bit
value in $r19, and I'm using gdb to examine the value.

In three of these four instances, there's 32-bit truncation going on.
I need to figure out how to mark these in the test suite.

In my view, the only correct result is the full 64-bit result.
I want to make the test results be:

  # gdb 6.1.1
  PASS: gdb.base-hp/reg.exp: info reg r19
  KFAIL: gdb.base-hp/reg.exp: print /x $r19 (pr gdb/NNNN)

  # gdb HEAD 2004-06-01
  KFAIL: gdb.base-hp/reg.exp: info reg r19 (pr gdb/NNNN)
  KFAIL: gdb.base-hp/reg.exp: print /x $r19 (pr gdb/NNNN)

The alternative would be to consider 32-bit truncation to be okay
issue a PASS on all four results.

Advice please?

Michael C

Re: native hppa2.0w-hp-hpux11.00, 32-bit versus 64-bit

[Andrew Cagney]

> We've got this test script to print hp register values,
> gdb/testsuite/gdb.hp/gdb.base-hp/reg.exp.  I'm working on it because
> the hp register code changed between 6.1 and HEAD.  There's some
> cosmetic differences in the results, which are easy for me to fix,
> and there's some 32-bit/64-bit changes, which I need help with.

What's the ABI wordsize - the size of a register pushed onto the stack? 
  "info registers" should be using that register size and looking at the 
HP/PA code, that appears to be the case.

It might also pay to check out `file gdb`, `file test-program`, "(gdb) 
show architecture" and "(gdb) maint print registers" to see what's been 
compbined.  At least for other architectures only a 64-bit native 
compiler can debug 64-bit code, and 32x64 while possible, gets more 
interesting :-)

Andrew

> I'm testing with gdb 6.1.1 and with gdb HEAD 2004-06-01.
> My gdb's are native hppa2.0w-hp-hpux11.00, and I built them with
> gcc 3.3.2 using no special flags.
> 
> Here is my actual output:
> 
>   # gdb 6.1.1
>   # gdb built with gcc 3.3.2, no special flags
>   (gdb) info reg r19
>   r19 deadbeefbadcadee
>   (gdb) print /x $r19
>   $1 = 0xbadcadee^M
> 
>   # gdb HEAD 2004-06-01
>   # gdb built with gcc 3.3.2, no special flags
>   (gdb) info reg r19
>   r19            0xbadcadee       3135024622
>   (gdb) print /x $r19
>   $1 = 0xbadcadee^M
> 
> The inferior program has used assembly language to build a 64-bit
> value in $r19, and I'm using gdb to examine the value.
> 
> In three of these four instances, there's 32-bit truncation going on.
> I need to figure out how to mark these in the test suite.
> 
> In my view, the only correct result is the full 64-bit result.
> I want to make the test results be:
> 
>   # gdb 6.1.1
>   PASS: gdb.base-hp/reg.exp: info reg r19
>   KFAIL: gdb.base-hp/reg.exp: print /x $r19 (pr gdb/NNNN)
> 
>   # gdb HEAD 2004-06-01
>   KFAIL: gdb.base-hp/reg.exp: info reg r19 (pr gdb/NNNN)
>   KFAIL: gdb.base-hp/reg.exp: print /x $r19 (pr gdb/NNNN)
> 
> The alternative would be to consider 32-bit truncation to be okay
> issue a PASS on all four results.
> 
> Advice please?
> 
> Michael C