From: Carl Love via Gdb-patches <gdb-patches@sourceware.org>
To: John Baldwin <jhb@FreeBSD.org>, Simon Marchi <simark@simark.ca>,
gdb-patches@sourceware.org
Cc: Rogerio Alves <rogealve@br.ibm.com>
Subject: RE: [PATCH] gdb fix for catch-syscall.exp
Date: Wed, 24 Nov 2021 09:46:12 -0800 [thread overview]
Message-ID: <fb73dec5451599d7016df8974bde5d9aa7224fe9.camel@us.ibm.com> (raw)
In-Reply-To: <ebc71ee1-7c1a-2550-3433-2a416268e71c@FreeBSD.org>
On Tue, 2021-11-23 at 14:34 -0800, John Baldwin wrote:
> > >
<snip>
> On 11/23/21 12:34 PM, Simon Marchi wrote:
> >
> > The behavior on powerpc sounds like a bug to me, and adjusting the
> > test
> > like this patch did just covers it up. It doesn't make sense for
> > that
> > behavior to be different per arch, for the same OS.
> >
> > If you all agree that it's a bug, I would suggest reverting this
> > patch
> > and making a patch that kfails the test when on powerpc. And
> > ideally,
> > someone should dig to understand why we don't see the return on
> > powerpc
> > (and fix it), but I'm not here to tell what other people should
> > work on
> > :).
>
> I do think this is likely a kernel bug. In FreeBSD's case we report
> a single
> event for both the syscall exit and exec event (but set flags to
> indicate that
> both events are present.. in practice for GDB I think this means that
> on
> FreeBSD we only report the exec event. Not sure if it would be more
> correct
> to report two events to the core in that case.) I do think that a
> given OS
> should probably be consistent here across architectures.
>
So I sent out a preliminary patch for comments to revert the change and
make it an xfail.
I was looking to see where I should file a bug. The discussion has
said it is a kernel bug. The Freebsd commit you pointed to is a distro
fix from what I can see? So, is it really a linux kernel issue or
something that the distros handle? I believe there is a ptrace code in
glib see that interacts with the result from the kernel, is that where
the fix should go to fix all arch?
Anyway, it isn't clear to me at the moment which bugzilla a bug should
be filed with. Thoughts?
Carl
next prev parent reply other threads:[~2021-11-24 17:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 23:30 Carl Love via Gdb-patches
2021-11-18 15:23 ` Tom Tromey
2021-11-18 18:10 ` Simon Marchi
2021-11-20 0:27 ` Carl Love via Gdb-patches
2021-11-22 1:07 ` Simon Marchi via Gdb-patches
2021-11-22 18:16 ` Carl Love via Gdb-patches
2021-11-22 17:01 ` John Baldwin
2021-11-23 20:34 ` Simon Marchi
2021-11-23 22:34 ` John Baldwin
2021-11-24 17:46 ` Carl Love via Gdb-patches [this message]
2021-11-24 17:51 ` John Baldwin
2021-11-24 1:15 ` Carl Love via Gdb-patches
2021-11-24 19:29 ` Simon Marchi
2021-11-29 16:46 ` Carl Love via Gdb-patches
2021-12-02 16:32 ` Ping " Carl Love via Gdb-patches
2021-12-10 18:36 ` Simon Marchi
2021-12-10 19:59 ` [PATCH v2] " Carl Love via Gdb-patches
2021-12-11 0:21 ` Simon Marchi via Gdb-patches
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=fb73dec5451599d7016df8974bde5d9aa7224fe9.camel@us.ibm.com \
--to=gdb-patches@sourceware.org \
--cc=cel@us.ibm.com \
--cc=jhb@FreeBSD.org \
--cc=rogealve@br.ibm.com \
--cc=simark@simark.ca \
/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