public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
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 [thread overview] Message-ID: <bug-29675-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29675 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 (arm-zephyr-eabi-gcc, qemu-system-xilinx-aarch64, arm-zephyr-eabi-gdb). 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 GNU gdb (Zephyr SDK 0.15.1) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. This is ARMv7-A (Cortex-A9). The exception vector is linked at 0x00100000, and its MMU region is flat. We are not using hivecs. We use the VBAR vector base address register to point to 0x00100000, accessing it via coprocessor cp15: (gdb) disass Dump of assembler code for function z_arm_prep_c: 0x00106bd8 <+0>: ldr r3, [pc, #24] ; 0x106bf8 <z_arm_prep_c+32> 0x00106bdc <+4>: push {r4, lr} 0x00106be0 <+8>: bic r3, r3, #31 => 0x00106be4 <+12>: mcr 15, 0, r3, cr12, cr0, {0} 0x00106be8 <+16>: isb sy 0x00106bec <+20>: bl 0x108a90 <z_bss_zero> 0x00106bf0 <+24>: bl 0x10789c <z_arm_interrupt_init> 0x00106bf4 <+28>: bl 0x108b74 <z_cstart> 0x00106bf8 <+32>: andseq r0, r0, r0 End of assembler dump. (gdb) p/x $r3 $3 = 0x100000 Further down the line, we jump correctly to the exception vector, so the write to VBAR was successfull. However, attempting to read VBAR via `info register` does not display a correct value for VBAR. I believe it should read 0x100000. See below: (gdb) c Continuing. Breakpoint 5, z_mapped_start () at .../vector_table.S:22 22 ldr pc, =z_arm_svc /* svc offset 8 */ (gdb) p/x $pc $5 = 0x100008 (gdb) info register VBAR VBAR 0x0 0 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 -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2022-10-12 13:01 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-12 13:01 theophile.ranquet at gmail dot com [this message] 2022-12-26 13:15 ` [Bug gdb/29675] " theophile.ranquet at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29675-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).