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 8AF40385DC1D; Wed, 12 Oct 2022 13:01:36 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8AF40385DC1D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1665579696;
	bh=+QzZ4LIs9VlWH2ncSvemseodjJELM7xS98vY5Md+lUI=;
	h=From:To:Subject:Date:From;
	b=kz5N1dL21Ufeq17g8WBmAGccutLjlSidCmW5nuQT7Wq5wyTg1lFfhlYZFuOoHpPNQ
	 dy5a1gyNLLcJxgYAX7RjgzI1xp1oSVgi59dLmTKcIC3Kn62fBCyhF5JvxYIYm6Ul0w
	 SFZICEso4nX1g5LgVk7wV8zOgKU2KxkIFnw/tXnI=
From: "theophile.ranquet at gmail dot com"
 <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/29675] New: AArch32 vector base address register info
Date: Wed, 12 Oct 2022 13:01:36 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: 12.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: minor
X-Bugzilla-Who: theophile.ranquet at gmail dot com
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-29675-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=3D29675

            Bug ID: 29675
           Summary: AArch32 vector base address register info
           Product: gdb
           Version: 12.1
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: theophile.ranquet at gmail dot com
  Target Milestone: ---

I have been doing some Zephyr development, using their toolchain=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20
(arm-zephyr-eabi-gcc, qemu-system-xilinx-aarch64, arm-zephyr-eabi-gdb).=20=
=20=20=20=20=20=20=20=20

Though I believe the issue I am reporting here is not fork-dependent, I am =
open
to proof of the contrary.

$ ~/zephyr-sdk-0.15.1/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb --version=20=
=20=20=20=20=20=20=20=20
GNU gdb (Zephyr SDK 0.15.1) 12.1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20
                                                   Copyright (C) 2022 Free
Software Foundation, Inc.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20
                           License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20
This is free software: you are free to change and redistribute it.=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
There is NO WARRANTY, to the extent permitted by law.=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

This is ARMv7-A (Cortex-A9). The exception vector is linked at 0x00100000, =
and=20=20
its MMU region is flat. We are not using hivecs. We use the VBAR vector bas=
e=20=20=20=20
address register to point to 0x00100000, accessing it via coprocessor cp15:=
=20=20=20=20=20

(gdb) disass=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
Dump of assembler code for function z_arm_prep_c:=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   0x00106bd8 <+0>:     ldr     r3, [pc, #24]   ; 0x106bf8 <z_arm_prep_c+32=
>=20=20=20=20
   0x00106bdc <+4>:     push    {r4, lr}=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20
   0x00106be0 <+8>:     bic     r3, r3, #31=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20
=3D> 0x00106be4 <+12>:    mcr     15, 0, r3, cr12, cr0, {0}=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   0x00106be8 <+16>:    isb     sy=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20
   0x00106bec <+20>:    bl      0x108a90 <z_bss_zero>=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   0x00106bf0 <+24>:    bl      0x10789c <z_arm_interrupt_init>=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20
   0x00106bf4 <+28>:    bl      0x108b74 <z_cstart>=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
   0x00106bf8 <+32>:    andseq  r0, r0, r0=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20
End of assembler dump.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
(gdb) p/x $r3=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
$3 =3D 0x100000=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

Further down the line, we jump correctly to the exception vector, so the wr=
ite=20=20
to VBAR was successfull. However, attempting to read VBAR via `info registe=
r`
does not display a correct value for VBAR. I believe it should read 0x10000=
0.=20=20=20
See below:=20

(gdb) c=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20
Continuing.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

Breakpoint 5, z_mapped_start () at .../vector_table.S:22
22              ldr pc, =3Dz_arm_svc               /* svc               off=
set 8
*/=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20
(gdb) p/x $pc=20=20=20
$5 =3D 0x100008=20
(gdb) info register VBAR
VBAR           0x0                 0=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20

Is this intended behavior? Or should I not use `info register` to read VBAR?

An issue has also been opened on the Xilinx qemu side:
    https://github.com/Xilinx/qemu/issues/75

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