From: Andrew Jones <andrew.jones@linux.dev>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu,
kvm@vger.kernel.org, Nikos Nikoleris <nikos.nikoleris@arm.com>,
Nadav Amit <namit@vmware.com>
Subject: Re: [kvm-unit-tests PATCH 1/6] arm: keep efi debug information in a separate file
Date: Sat, 24 Jun 2023 12:12:08 +0200 [thread overview]
Message-ID: <20230624-7f0459e3472cf78947b5464f@orel> (raw)
In-Reply-To: <20230617014930.2070-2-namit@vmware.com>
On Sat, Jun 17, 2023 at 01:49:25AM +0000, Nadav Amit wrote:
> From: Nadav Amit <namit@vmware.com>
>
> Debugging tests that run on EFI is hard because the debug information is
> not included in the EFI file. Dump it into a separeate .debug file to
> allow the use of gdb or pretty_print_stacks script.
>
> Signed-off-by: Nadav Amit <namit@vmware.com>
> ---
> arm/Makefile.common | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arm/Makefile.common b/arm/Makefile.common
> index d60cf8c..f904702 100644
> --- a/arm/Makefile.common
> +++ b/arm/Makefile.common
> @@ -69,7 +69,7 @@ FLATLIBS = $(libcflat) $(LIBFDT_archive) $(libeabi)
> ifeq ($(CONFIG_EFI),y)
> %.so: EFI_LDFLAGS += -defsym=EFI_SUBSYSTEM=0xa --no-undefined
> %.so: %.o $(FLATLIBS) $(SRCDIR)/arm/efi/elf_aarch64_efi.lds $(cstart.o)
> - $(CC) $(CFLAGS) -c -o $(@:.so=.aux.o) $(SRCDIR)/lib/auxinfo.c \
> + $(CC) $(CFLAGS) -c -g -o $(@:.so=.aux.o) $(SRCDIR)/lib/auxinfo.c \
> -DPROGNAME=\"$(@:.so=.efi)\" -DAUXFLAGS=$(AUXFLAGS)
> $(LD) $(EFI_LDFLAGS) -o $@ -T $(SRCDIR)/arm/efi/elf_aarch64_efi.lds \
> $(filter %.o, $^) $(FLATLIBS) $(@:.so=.aux.o) \
> @@ -78,6 +78,9 @@ ifeq ($(CONFIG_EFI),y)
>
> %.efi: %.so
> $(call arch_elf_check, $^)
> + $(OBJCOPY) --only-keep-debug $^ $@.debug
> + $(OBJCOPY) --strip-debug $^
> + $(OBJCOPY) --add-gnu-debuglink=$@.debug $^
> $(OBJCOPY) \
> -j .text -j .sdata -j .data -j .dynamic -j .dynsym \
> -j .rel -j .rela -j .rel.* -j .rela.* -j .rel* -j .rela* \
> --
> 2.34.1
>
Any reason to not also do this for x86?
One reason I ask, is that in order for pretty_print_stacks.py to make
use of this from run_tests.sh we need a patch like
diff --git a/run_tests.sh b/run_tests.sh
index f61e0057b537..67b239f1adc7 100755
--- a/run_tests.sh
+++ b/run_tests.sh
@@ -125,8 +125,14 @@ fi
RUNTIME_log_stderr () { process_test_output "$1"; }
RUNTIME_log_stdout () {
local testname="$1"
+ local kernel
+
if [ "$PRETTY_PRINT_STACKS" = "yes" ]; then
- local kernel="$2"
+ if [ "$CONFIG_EFI" = "y" ]; then
+ kernel="${TEST_DIR}/${2}.efi.debug"
+ else
+ kernel="$2"
+ fi
./scripts/pretty_print_stacks.py "$kernel" | process_test_output "$testname"
else
process_test_output "$testname"
We'd have to special-case that CONFIG_EFI condition for arm64 if we don't
also create .efi.debug files for x86.
Thanks,
drew
next prev parent reply other threads:[~2023-06-24 10:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-17 1:49 [kvm-unit-tests PATCH 0/6] arm64: improve debuggability Nadav Amit
2023-06-17 1:49 ` [kvm-unit-tests PATCH 1/6] arm: keep efi debug information in a separate file Nadav Amit
2023-06-24 10:12 ` Andrew Jones [this message]
2023-06-24 10:31 ` Andrew Jones
2023-06-25 19:21 ` Nadav Amit
2023-06-17 1:49 ` [kvm-unit-tests PATCH 2/6] lib/stack: print base addresses on efi Nadav Amit
2023-06-24 10:13 ` Andrew Jones
2023-06-25 19:23 ` Nadav Amit
2023-06-17 1:49 ` [kvm-unit-tests PATCH 3/6] arm64: enable frame pointer and support stack unwinding Nadav Amit
2023-06-24 10:13 ` Andrew Jones
2023-06-25 19:22 ` Nadav Amit
2023-06-26 5:42 ` Andrew Jones
2023-06-17 1:49 ` [kvm-unit-tests PATCH 4/6] arm64: stack: update trace stack on exception Nadav Amit
2023-06-24 10:18 ` Andrew Jones
2023-06-17 1:49 ` [kvm-unit-tests PATCH 5/6] efi: Print address of image Nadav Amit
2023-06-17 1:49 ` [kvm-unit-tests PATCH 6/6] arm64: dump stack on bad exception Nadav Amit
2023-06-17 1:52 ` Nadav Amit
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=20230624-7f0459e3472cf78947b5464f@orel \
--to=andrew.jones@linux.dev \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=kvmarm@lists.linux.dev \
--cc=nadav.amit@gmail.com \
--cc=namit@vmware.com \
--cc=nikos.nikoleris@arm.com \
/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: link
Be 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