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 8E5CB3858C53; Tue, 17 Jan 2023 15:12:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E5CB3858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1673968353;
	bh=T6hstJs9dB+pU4VAFC0/K/4vJiklIqD4/plVx8Vs9II=;
	h=From:To:Subject:Date:From;
	b=IDEPorHn4PCkM/LEHDx0rx/K+bYSxejqPkWQiUVUFNk82tFt5RWbjOnbeFkPOI4fX
	 fw3DUj2FTYfwIDO1AFozp795/bA75xHlJJ2Sj2KYkCHa2QuHnIwShTHEGmem6LCaVa
	 6CYOXE6PAS48K8eyzza+cV/hO7Y2QqscWMvEH6Ew=
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug tdep/30012] New: [gdb/tdep, aarch64] fp and sp register aliases
 ignored
Date: Tue, 17 Jan 2023 15:12:33 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: tdep
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-30012-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=3D30012

            Bug ID: 30012
           Summary: [gdb/tdep, aarch64] fp and sp register aliases ignored
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case:
...
$ cat test.c
void
foo (const char *s)
{
}

int
main (void)
{
  foo ("foo");
  return 0;
}
...

Compiled without debug info:
...
$ gcc test.c
...

Disassembly of foo:
...
0000000000400564 <foo>:
  400564:       d10043ff        sub     sp, sp, #0x10
  400568:       f90007e0        str     x0, [sp, #8]
  40056c:       d503201f        nop
  400570:       910043ff        add     sp, sp, #0x10
  400574:       d65f03c0        ret
...

This looks interesting:
...
$ gdb -q -batch a.out \
    -ex "display /x \$sp" \
    -ex "display /x \$x29" \
    -ex "display /x \$fp" \
    -ex "b *foo" \
    -ex run \
    -ex stepi
Breakpoint 1 at 0x400564

Breakpoint 1, 0x0000000000400564 in foo ()
1: /x $sp =3D 0xfffffffff3a0
2: /x $x29 =3D 0xfffffffff3a0
3: /x $fp =3D 0xfffffffff3a0
0x0000000000400568 in foo ()
1: /x $sp =3D 0xfffffffff390
2: /x $x29 =3D 0xfffffffff3a0
3: /x $fp =3D 0xfffffffff390
...

The effect of "sub sp, sp, #0x10" on sp (the canonical name in gdb for x31)=
 is
as expected, it drops 0x10.

The effect on x29, the frame pointer register, is none, again as expected.

However, fp is supposed to be an alias for x29, according to:
...
static const struct
{
  const char *const name;
  int regnum;
} aarch64_register_aliases[] =3D
{
  /* 64-bit register names.  */
  {"fp", AARCH64_FP_REGNUM},
  {"lr", AARCH64_LR_REGNUM},
  {"sp", AARCH64_SP_REGNUM},
  /*  specials */
  {"ip0", AARCH64_X0_REGNUM + 16},
  {"ip1", AARCH64_X0_REGNUM + 17}
};
...

So we'd expect fp to be unaffected, but that's not the case.

The reason for this is this:
...
void
_initialize_frame_reg ()
{
  /* Frame based $fp, $pc, $sp and $ps.  These only come into play=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
     when the target does not define its own version of these=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
     registers.  */
  user_reg_add_builtin ("fp", value_of_builtin_frame_fp_reg, NULL);
  user_reg_add_builtin ("pc", value_of_builtin_frame_pc_reg, NULL);
  user_reg_add_builtin ("sp", value_of_builtin_frame_sp_reg, NULL);
  user_reg_add_builtin ("ps", value_of_builtin_frame_ps_reg, NULL);
}
...

So, the fp register alias is simply ignored.

Note that the sp alias is likewise ignored, given that the canonical name f=
or
"x31" is "sp".

We probably should:
- error out when creating aliases with a name that's already taken.
- remove the sp and fp aliases

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