From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 5BD953858C54; Wed,  7 Jun 2023 09:05:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5BD953858C54
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1686128721;
	bh=1PNHTujxSUmsR70atnPt5gL3q95Q6k/4IKE43Ak5owk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ks0ugB6MDwcxPbO2yDTGcX25cXb1eB5S3kgcknBcueyTGhPiSYkYl50NCX5D66c7y
	 ERGR5xdILWd8xA3lthEuE+C0eSMzwgxhxYUDccx62NaWR1VfNCkHj3FSxBOF23G7Hz
	 ZzHAAwLLrix3X2EzouqcPtTnrEIpqPdHk4Ju8Y5Y=
From: "pedro at palves dot net" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/30525] gdb cannot read shared libraries on SPARC64
Date: Wed, 07 Jun 2023 09:05:21 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pedro at palves dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-30525-4717-pEwBoWUvud@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-30525-4717@http.sourceware.org/bugzilla/>
References: <bug-30525-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30525

--- Comment #3 from Pedro Alves <pedro at palves dot net> ---
> (gdb) info sharedlibrary
> Cannot access memory at address 0xfff80001002011e0
> Cannot access memory at address 0xfff80001002011d8
> Cannot access memory at address 0xfff80001002011d8

Those addresses look suspiciously high for userspace.  They are 64-bit
addresses, with the high bits set.  When interpreted as signed, they'd be
negative.  Are they really correct?

We have, in gdb/linux-nat.c:

static enum target_xfer_status
linux_proc_xfer_memory_partial_fd (int fd, int pid,
                                   gdb_byte *readbuf, const gdb_byte *write=
buf,
                                   ULONGEST offset, LONGEST len,
                                   ULONGEST *xfered_len)
{
  ssize_t ret;

  gdb_assert (fd !=3D -1);

  /* Use pread64/pwrite64 if available, since they save a syscall and can
     handle 64-bit offsets even on 32-bit platforms (for instance, SPARC
     debugging a SPARC64 application).  */
#ifdef HAVE_PREAD64
  ret =3D (readbuf ? pread64 (fd, readbuf, len, offset)
         : pwrite64 (fd, writebuf, len, offset));
#else
  ret =3D lseek (fd, offset, SEEK_SET);
  if (ret !=3D -1)
    ret =3D (readbuf ? read (fd, readbuf, len)
           : write (fd, writebuf, len));
#endif


So one thing to check is whether the HAVE_PREAD64 code is enabled.  And the=
n,
that may be failing due to a negative offset, give pread64's offset paramet=
er
is an off_t.

Try enabling "set debug linux-nat 1", so that the following log is output:

  if (ret =3D=3D -1)
    {
      linux_nat_debug_printf ("accessing fd %d for pid %d failed: %s (%d)",
                              fd, pid, safe_strerror (errno), errno);
      return TARGET_XFER_E_IO;
    }

Maybe the errno gives us some clue.

Does hacking the linux-nat.c:proc_mem_file_is_writable to always return fal=
se
paper over the problem?

--=20
You are receiving this mail because:
You are on the CC list for the bug.=