Re: [Qemu-devel] [PATCH] linux-user: Support gdb 'qOffsets' query for ELF
The `Data` and `Code` flags in `qOffsets` are actually section offsets rather than segment offsets. GDB relocates the symbols in those sections relative to their location in the binary. So we have to use `load_bias`. See here for a more detailed description: https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets On Mon, Aug 26, 2019 at 1:29 AM Laurent Vivier wrote: > Le 17/08/2019 à 01:34, Josh Kunz via Qemu-devel a écrit : > > This is needed to support debugging PIE ELF binaries running under QEMU > > user mode. Currently, `code_offset` and `data_offset` remain unset for > > all ELF binaries, so GDB is unable to correctly locate the position of > > the binary's text and data. > > > > The fields `code_offset`, and `data_offset` were originally added way > > back in 2006 to support debugging of bFMT executables (978efd6aac6), > > and support was just never added for ELF. Since non-PIE binaries are > > loaded at exactly the address specified in the binary, GDB does not need > > to relocate any symbols, so the buggy behavior is not normally observed. > > > > Buglink: https://bugs.launchpad.net/qemu/+bug/1528239 > > Signed-off-by: Josh Kunz > > --- > > linux-user/elfload.c | 2 ++ > > 1 file changed, 2 insertions(+) > > As it seems they are text and data segment offsets, why it's not based > on info->start_code and info->start_data? > > Thanks, > Laurent >
Re: [Qemu-devel] [EXTERNAL]Re: patch to swap SIGRTMIN + 1 and SIGRTMAX - 1
I can take over the series. I'll rebase the patch set, and update it to address the SIGRTMIN - 1 issue. I should have an update sometime next week. On Wed, Aug 28, 2019 at 10:31 AM Aleksandar Markovic wrote: > > From: Laurent Vivier > > Sent: Wednesday, August 28, 2019 10:51 AM > > To: Josh Kunz; Aleksandar Markovic; milos.stojano...@rt-rk.com > > Cc: marlies.r...@gmail.com; qemu-devel@nongnu.org; riku.voi...@iki.fi; > > qemu-triv...@nongnu.org; Peter Maydell; Shu-Chun Weng; Aleksandar > Markovic > > Subject: [EXTERNAL]Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and > SIGRTMAX - 1 > > > > Le 26/08/2019 à 23:10, Josh Kunz a écrit : > > > On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier > > <mailto:laur...@vivier.eu>> wrote: > > > > > > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > > > > Hi all, > > > > > > > > I have also experienced issues with SIGRTMIN + 1, and am > interested in > > > > moving this patch forwards. Anything I can do here to help? > Would the > > > > maintainers prefer myself or Marli re-submit the patch? > > > > > > > > The Go issue here seems particularly sticky. Even if we update > the Go > > > > runtime, users may try and run older binaries built with older > > > versions of > > > > Go for quite some time (months? years?). Would it be better to > > > hide this > > > > behind some kind of build-time flag > > > (`--enable-sigrtmin-plus-one-proxy` or > > > > something), so that some users can opt-in, but older binaries > > > still work as > > > > expected? > > > > > > > > Also, here is a link to the original thread this message is in > > > reply to > > > > in-case my mail-client doesn't set up the reply properly: > > > > > https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html > > > > > > The problem here is we break something to fix something else. > > > > > > I'm wondering if the series from Aleksandar Markovic, "linux-user: > > > Support signal passing for targets having more signals than host" > [1] > > > can fix the problem in a better way? > > > > > > > > > That patch[1] (which I'll refer to as the MUX patch to avoid confusion) > > > does not directly fix the issue addressed by this patch (re-wiring > > > SIGRTMIN+1), but since it basically implements generic signal > > > multiplexing, it could be re-worked to address this case as well. The > > > way it handles `si_code` spooks me a little bit. It could easily be > > > broken by a kernel version change, and such a breakage could be hard to > > > detect or lead to surprising results. Other than that, it looks like a > > > reasonable implementation. > > > > > > That said, overall, fixing the SIGRTMIN+1 issue using a more-generic > > > signal-multiplexing mechanism doesn't seem *that* much better to me. It > > > adds a lot of complexity, and only saves a single signal (assuming > glibc > > > doesn't add more reserved signals). The "big win" is additional > > > emulation features, like those introduced in MUX patch (being able to > > > utilize signals outside of the host range). If having those features in > > > QEMU warrants the additional complexity, then re-working this patch > > > on-top of that infrastructure seems like a good idea. > > > > > > If the maintainers want to go down that route, then I would be happy to > > > re-work this patch utilizing the infrastructure from the MUX patch. > > > Unfortunately it will require non-trivial changes, so it may be best to > > > wait until that patch is merged. I could also provide a patch "on top > > > of" the MUX patch, if that's desired/more convenient. > > > > > > Just one last note, if you do decide to merge the MUX patch, then it > > > would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the > > > multiplexing signal if possible, to avoid breaking go binaries. > > > > > > > Personally, I prefer a solution that breaks nothing. > > > > Aleksandar, Milos, > > > > do you have an updated version of you series "Support signal passing for > > targets having more signals than host"? > > > > Milos is unfortunetely working on an entirely different project now, and > can't spare enough time to finish the series. I am also busy with other > issues, even though I would like very much this or equivalent solution to > be integrated. Alternatively, someone in the team may have time later this > year, but I do not know that yet - perhaps somebody else (Josh) can take > over the series? > > Sincerely, > Aleksandar > > > > Thanks, > > Laurent > >
Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1
On Wed, Aug 21, 2019 at 2:28 AM Laurent Vivier wrote: > Le 19/08/2019 à 23:46, Josh Kunz via Qemu-devel a écrit : > > Hi all, > > > > I have also experienced issues with SIGRTMIN + 1, and am interested in > > moving this patch forwards. Anything I can do here to help? Would the > > maintainers prefer myself or Marli re-submit the patch? > > > > The Go issue here seems particularly sticky. Even if we update the Go > > runtime, users may try and run older binaries built with older versions > of > > Go for quite some time (months? years?). Would it be better to hide this > > behind some kind of build-time flag (`--enable-sigrtmin-plus-one-proxy` > or > > something), so that some users can opt-in, but older binaries still work > as > > expected? > > > > Also, here is a link to the original thread this message is in reply to > > in-case my mail-client doesn't set up the reply properly: > > https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html > > The problem here is we break something to fix something else. > > I'm wondering if the series from Aleksandar Markovic, "linux-user: > Support signal passing for targets having more signals than host" [1] > can fix the problem in a better way? > That patch[1] (which I'll refer to as the MUX patch to avoid confusion) does not directly fix the issue addressed by this patch (re-wiring SIGRTMIN+1), but since it basically implements generic signal multiplexing, it could be re-worked to address this case as well. The way it handles `si_code` spooks me a little bit. It could easily be broken by a kernel version change, and such a breakage could be hard to detect or lead to surprising results. Other than that, it looks like a reasonable implementation. That said, overall, fixing the SIGRTMIN+1 issue using a more-generic signal-multiplexing mechanism doesn't seem *that* much better to me. It adds a lot of complexity, and only saves a single signal (assuming glibc doesn't add more reserved signals). The "big win" is additional emulation features, like those introduced in MUX patch (being able to utilize signals outside of the host range). If having those features in QEMU warrants the additional complexity, then re-working this patch on-top of that infrastructure seems like a good idea. If the maintainers want to go down that route, then I would be happy to re-work this patch utilizing the infrastructure from the MUX patch. Unfortunately it will require non-trivial changes, so it may be best to wait until that patch is merged. I could also provide a patch "on top of" the MUX patch, if that's desired/more convenient. Just one last note, if you do decide to merge the MUX patch, then it would be best to use SIGRTMAX (instead of SIGRTMAX-1) as the multiplexing signal if possible, to avoid breaking go binaries. Thanks again for taking a look at this issue. Cheers, Josh Kunz [1] http://patchwork.ozlabs.org/cover/1103565/
Re: [Qemu-devel] patch to swap SIGRTMIN + 1 and SIGRTMAX - 1
Hi all, I have also experienced issues with SIGRTMIN + 1, and am interested in moving this patch forwards. Anything I can do here to help? Would the maintainers prefer myself or Marli re-submit the patch? The Go issue here seems particularly sticky. Even if we update the Go runtime, users may try and run older binaries built with older versions of Go for quite some time (months? years?). Would it be better to hide this behind some kind of build-time flag (`--enable-sigrtmin-plus-one-proxy` or something), so that some users can opt-in, but older binaries still work as expected? Also, here is a link to the original thread this message is in reply to in-case my mail-client doesn't set up the reply properly: https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg01303.html Thanks, Josh Kunz
Re: [Qemu-devel] [PATCH] linux-user: Support gdb 'qOffsets' query for ELF
+cc: riku.voi...@iki.fi, I typoed the email on the first go. On Fri, Aug 16, 2019 at 4:34 PM Josh Kunz wrote: > This is needed to support debugging PIE ELF binaries running under QEMU > user mode. Currently, `code_offset` and `data_offset` remain unset for > all ELF binaries, so GDB is unable to correctly locate the position of > the binary's text and data. > > The fields `code_offset`, and `data_offset` were originally added way > back in 2006 to support debugging of bFMT executables (978efd6aac6), > and support was just never added for ELF. Since non-PIE binaries are > loaded at exactly the address specified in the binary, GDB does not need > to relocate any symbols, so the buggy behavior is not normally observed. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1528239 > Signed-off-by: Josh Kunz > --- > linux-user/elfload.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/linux-user/elfload.c b/linux-user/elfload.c > index 3365e192eb..ceac035208 100644 > --- a/linux-user/elfload.c > +++ b/linux-user/elfload.c > @@ -2380,6 +2380,8 @@ static void load_elf_image(const char *image_name, > int image_fd, > } > > info->load_bias = load_bias; > +info->code_offset = load_bias; > +info->data_offset = load_bias; > info->load_addr = load_addr; > info->entry = ehdr->e_entry + load_bias; > info->start_code = -1; > -- > 2.23.0.rc1.153.gdeed80330f-goog > >
[Qemu-devel] [PATCH] linux-user: Support gdb 'qOffsets' query for ELF
This is needed to support debugging PIE ELF binaries running under QEMU user mode. Currently, `code_offset` and `data_offset` remain unset for all ELF binaries, so GDB is unable to correctly locate the position of the binary's text and data. The fields `code_offset`, and `data_offset` were originally added way back in 2006 to support debugging of bFMT executables (978efd6aac6), and support was just never added for ELF. Since non-PIE binaries are loaded at exactly the address specified in the binary, GDB does not need to relocate any symbols, so the buggy behavior is not normally observed. Buglink: https://bugs.launchpad.net/qemu/+bug/1528239 Signed-off-by: Josh Kunz --- linux-user/elfload.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/linux-user/elfload.c b/linux-user/elfload.c index 3365e192eb..ceac035208 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -2380,6 +2380,8 @@ static void load_elf_image(const char *image_name, int image_fd, } info->load_bias = load_bias; +info->code_offset = load_bias; +info->data_offset = load_bias; info->load_addr = load_addr; info->entry = ehdr->e_entry + load_bias; info->start_code = -1; -- 2.23.0.rc1.153.gdeed80330f-goog
