From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: Jon Doron <arilou@gmail.com>
Cc: qemu-devel@nongnu.org, linux-debuggers@vger.kernel.org,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Laszlo Ersek" <lersek@redhat.com>
Subject: Re: Concerns regarding e17bebd049 ("dump: Set correct vaddr for ELF dump")
Date: Wed, 20 Sep 2023 10:35:29 -0700 [thread overview]
Message-ID: <87edisycgu.fsf@oracle.com> (raw)
In-Reply-To: <ZQqj9tFS7cLMTkHv@jondnuc>
Hi Jon,
Jon Doron <arilou@gmail.com> writes:
> Hi Stephen,
> Like you have said the reason is as I wrote in the commit message,
> without "fixing" the vaddr GDB is messing up mapping and working with
> the generated core file.
For the record I totally love this workaround :)
It's clever and gets the job done and I would have done it in a
heartbeat. It's just that it does end up making vmcores that have
incorrect data, which is a pain for debuggers that are actually designed
to look at kernel core dumps.
> This patch is almost 4 years old, perhaps some changes to GDB has been
> introduced to resolve this, I have not checked since then.
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x0000000000000168 0x0000000000000000 0x0000000000000000
0x0000000000001980 0x0000000000001980 0x0
LOAD 0x0000000000001ae8 0x0000000000000000 0x0000000000000000
0x0000000080000000 0x0000000080000000 0x0
LOAD 0x0000000080001ae8 0x0000000000000000 0x00000000fffc0000
0x0000000000040000 0x0000000000040000 0x0
(gdb) info files
Local core dump file:
`/home/stepbren/repos/test_code/elf/dumpfile', file type elf64-x86-64.
0x0000000000000000 - 0x0000000080000000 is load1
0x0000000000000000 - 0x0000000000040000 is load2
$ gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux 10.2-10.0.2.el9
Copyright (C) 2021 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.
It doesn't *look like* anything has changed in this version of GDB. But
I'm not really certain that GDB is expected to use the physical
addresses in the load segments: it's not a kernel debugger.
I think hacking the p_vaddr field _is_ the way to get GDB to behave in
the way you want: allow you to read physical memory addresses.
> As I'm no longer using this feature and have not worked and tested it
> in a long while, so I have no obligations to this change, but perhaps
> someone else might be using it...
I definitely think it's valuable for people to continue being able to
use QEMU vmcores generated with paging=off in GDB, even if GDB isn't
desgined for it. It seems like a useful hack that appeals to the lowest
common denominator: most people have GDB and not a purpose-built kernel
debugger. But maybe we could point to a program like the below that will
tweak the p_paddr field after the fact, in order to appeal to GDB's
sensibilities?
Thanks,
Stephen
---
#include <stdbool.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <byteswap.h>
#include <elf.h>
static void fail(const char *msg)
{
fprintf(stderr, "%s\n", msg);
exit(EXIT_FAILURE);
}
static void perror_fail(const char *pfx)
{
perror(pfx);
exit(EXIT_FAILURE);
}
static void usage(void)
{
puts("usage: phys2virt COREFILE");
puts("Modifies the ELF COREFILE so that load segments have their virtual");
puts("address value copied from the physical address field.");
exit(EXIT_SUCCESS);
}
static int endian(void)
{
union {
uint32_t ival;
char cval[4];
} data;
data.ival = 1;
if (data.cval[0])
return ELFDATA2LSB;
else
return ELFDATA2MSB;
}
int main(int argc, char **argv)
{
char *filename;
FILE *f;
Elf64_Ehdr hdr;
Elf64_Phdr *phdrs;
off_t phoff;
int phnum, phentsize;
bool bswap;
if (argc != 2 || strcmp(argv[1], "-h") == 0)
usage();
filename = argv[1];
f = fopen(filename, "r+");
if (!f)
perror_fail("open");
if (fread(&hdr, sizeof(hdr), 1, f) != 1)
perror_fail("read elf header");
if (memcmp(hdr.e_ident, ELFMAG, 4) != 0)
fail("not an ELF file");
if (hdr.e_ident[EI_CLASS] != ELFCLASS64)
fail("file is not 64-bits: unsupported");
if (bswap) {
phoff = bswap_64(hdr.e_phoff);
phnum = bswap_16(hdr.e_phnum);
phentsize = bswap_16(hdr.e_phentsize);
} else {
phoff = hdr.e_phoff;
phnum = hdr.e_phnum;
phentsize = hdr.e_phentsize;
}
if (phentsize != sizeof(Elf64_Phdr))
fail("error: mismatch between phentsize and sizeof(Elf64_Phdr)");
if (fseek(f, phoff, SEEK_SET) < 0)
perror_fail("fseek");
phdrs = calloc(phnum, phentsize);
if (!phdrs)
fail("error: allocation error");
if (fread(phdrs, phentsize, phnum, f) != phnum)
perror_fail("fread phdrs");
for (int i = 0; i < phnum; i++)
phdrs[i].p_vaddr = 0; //phdrs[i].p_paddr;
if (fseek(f, phoff, SEEK_SET) < 0)
perror_fail("fseek");
if (fwrite(phdrs, phentsize, phnum, f) != phnum)
perror_fail("fwrite phdrs");
fclose(f);
return EXIT_SUCCESS;
}
next prev parent reply other threads:[~2023-09-20 17:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 17:39 Concerns regarding e17bebd049 ("dump: Set correct vaddr for ELF dump") Stephen Brennan
2023-09-20 7:49 ` Jon Doron
2023-09-20 17:35 ` Stephen Brennan [this message]
2023-09-20 17:43 ` Stephen Brennan
2023-09-22 3:06 ` Dave Young
2023-09-21 7:49 ` Laszlo Ersek
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=87edisycgu.fsf@oracle.com \
--to=stephen.s.brennan@oracle.com \
--cc=arilou@gmail.com \
--cc=lersek@redhat.com \
--cc=linux-debuggers@vger.kernel.org \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.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: 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;
as well as URLs for NNTP newsgroup(s).