lin-lwp.c and UltraSPARC

lin-lwp.c and UltraSPARC

[Mark Kettenis]

Ever since I created the file, lin-lwp.c has had the following code:

static int
lin_lwp_thread_alive (ptid_t ptid)
{
  gdb_assert (is_lwp (ptid));

  errno = 0;
  ptrace (PTRACE_PEEKUSER, GET_LWP (ptid), 0, 0);
  if (debug_lin_lwp)
    fprintf_unfiltered (gdb_stdlog,
			"LLTA: PTRACE_PEEKUSER %s, 0, 0 (%s)\n",
			target_pid_to_str (ptid),
			errno ? safe_strerror (errno) : "OK");
  if (errno)
    return 0;

  return 1;
}

Today I discovered that a sparc64 Linux kernel doesn't implement
PTRACE_PEEKUSER, and therefore always sets errno to EIO.  The result
is that for UltraSPARC systems running on a 64-bit kernel, all threads
are always considered to be dead.  Sooner or later this gets us into
real trouble.

There are basically two things we can do.  The first one is:

-  if (errno)
+  if (errno && errno != EIO)
     return 0;

The alternative is:

-  if (errno)
+  if (errno == ESRCH)
     return 0;

I'm leaning towards the latter since I think it is cleaner, although
perhaps a bit more riskier (I haven't looked at all the
architecture-specific ptrace(2) implementations in the Linux kernel).

I'm also thinking about replacing the PTRACE_PEEKUSER with a
PTRACE_PEEKDATA since the latter should be implemented on all
architectures.  In that case the call would probably fail the same way
on all architectures (assuming that nothing is mapped at address 0 on
all those architectures).

Opinions?

Mark

Re: lin-lwp.c and UltraSPARC

[Kevin Buettner]

On Oct 31,  9:38pm, Mark Kettenis wrote:

> I'm also thinking about replacing the PTRACE_PEEKUSER with a
> PTRACE_PEEKDATA since the latter should be implemented on all
> architectures.  In that case the call would probably fail the same way
> on all architectures (assuming that nothing is mapped at address 0 on
> all those architectures).

This sounds like a good idea.

Kevin

Re: lin-lwp.c and UltraSPARC

[Daniel Jacobowitz]

On Fri, Oct 31, 2003 at 04:31:51PM -0700, Kevin Buettner wrote:
> On Oct 31,  9:38pm, Mark Kettenis wrote:
> 
> > I'm also thinking about replacing the PTRACE_PEEKUSER with a
> > PTRACE_PEEKDATA since the latter should be implemented on all
> > architectures.  In that case the call would probably fail the same way
> > on all architectures (assuming that nothing is mapped at address 0 on
> > all those architectures).
> 
> This sounds like a good idea.

Yes, I agree.  Interesting, this explains a number of pending Debian
bug reports... you could also PEEKDATA at an address that we expect to
be mapped.  $sp might work.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer