Re: [RFA/commit/ia64-linux] Allow libunwind to fetch register 0

[Pedro Alves <palves at redhat dot com>]

On 03/28/2012 12:03 AM, Joel Brobecker wrote:

>>> I will make the small changes you suggested at the beginning of
>>> > > the patch. I just wanted to confirm something:
>> >
>> > <snip my own confusion>
>> >
>>> > > I will send a new patch...
>> >
>> > Do you have that new patch handy?  Want to check it in?
>> > I'm testing something on ia64-linux, and notice that gr0 shows up
>> > as *unavailable*.
> Argh - I could have sworn I sent the new patch, but I cannot find it
> anyway in my sent box, or my repository on my laptop. 


> And bad luck on the timing, as we've done an emergency shutdown of most of our

> machines due to some construction going on in our building (TMI?).


( :-) )

> 
> Anyway, I didn't want you to wait, so I redid the changes. I just
> cannot compile or test them. I will do that tomorrow, hoping that
> the machines will be powered up again, and if that shows no
> regression, I will check it in.


I've tested them on ia64-unknown-linux-gnu (debian 6).  No regressions,
and a few progressions.

> 
> Given that the cannot_fetch_register gdbarch hook wasn't attached,
> my understanding is that there isn't anything else that really needs
> changing...


Yeah.  Please check it in.

I see that $f0 (always 0.0) and $f1 (always 1.0) could/should be given
similar treatment:

(gdb) info register $f0 $f1
f0             *value not available*
f1             *value not available*

$p0 also has one bit that should always be read as 1, but it
seems something (the kernel?) is already handling that:

(gdb) info register $p0
p0             0x1      1

gcore.exp failures related to these issues.  It shows the $f0/$f1 issue, and
also, that $ec is read back from the core as 0, but it is read as
*unavailable* when debugging a live process.  The latter is because
have (ia64-linux-nat.c):

static int u_offsets[] =
  {
...
    PT_AR_LC,
    -1,		/* Not available: EC, the Epilog Count register.  */

But in ia64-linux-nat.c:supply_gregset:

  regcache_raw_supply (regcache, IA64_LC_REGNUM, regp + 53);
  regcache_raw_supply (regcache, IA64_EC_REGNUM, regp + 54);

which is suspicious (the registers is not retrievable with ptrace, but
it's in the core?).  Indeed, on this system's /usr/include/asm/ptrace_offsets.h
I see:

#define PT_AR_EC                0x0800
#define PT_AR_LC                0x0808

So it does look like it is available with ptrace.

I'm testing patches for these issues.

GDBserver also needs the same treatment for these things.  (e.g.,
you can see gdb.server/ tests failing on ia64-linux).

-- 
Pedro Alves