Add _sigsys info to siginfo struct

Message ID 20220103185854.1675-1-ssbssa@yahoo.de
State New
Headers show
Series
  • Add _sigsys info to siginfo struct
Related show

Commit Message

Simon Marchi via Gdb-patches Jan. 3, 2022, 6:58 p.m.
This patch adds information about _sigsys structure from newer
kernels, so that $_siginfo decoding can show information about
_sigsys, making it easier for developers to debug seccomp failures.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283
---
 gdb/linux-tdep.c | 7 +++++++
 1 file changed, 7 insertions(+)

-- 
2.34.1

Comments

Simon Marchi via Gdb-patches Jan. 8, 2022, 11:03 a.m. | #1
Hi Hannes,

On Mon, Jan 03, 2022 at 07:58:54PM +0100, Hannes Domani via Gdb-patches wrote:
> This patch adds information about _sigsys structure from newer

> kernels, so that $_siginfo decoding can show information about

> _sigsys, making it easier for developers to debug seccomp failures.

> 

> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283


Thanks for the patch.

I'm trusting you for the proper definition of the various fields.
This looks reasonable to me, but before we push this, I'm wondering
what happens when debugging on a kernel which does not support
this feature? Is the data undefined? If yes, do we a precendent
for this already?

> ---

>  gdb/linux-tdep.c | 7 +++++++

>  1 file changed, 7 insertions(+)

> 

> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c

> index 927e69bf1e1..fb2abdd1a21 100644

> --- a/gdb/linux-tdep.c

> +++ b/gdb/linux-tdep.c

> @@ -379,6 +379,13 @@ linux_get_siginfo_type_with_fields (struct gdbarch *gdbarch,

>    append_composite_type_field (type, "si_fd", int_type);

>    append_composite_type_field (sifields_type, "_sigpoll", type);

>  

> +  /* _sigsys */

> +  type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT);

> +  append_composite_type_field (type, "_call_addr", void_ptr_type);

> +  append_composite_type_field (type, "_syscall", int_type);

> +  append_composite_type_field (type, "_arch", uint_type);

> +  append_composite_type_field (sifields_type, "_sigsys", type);

> +

>    /* struct siginfo */

>    siginfo_type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT);

>    siginfo_type->set_name (xstrdup ("siginfo"));

> -- 

> 2.34.1

> 


-- 
Joel
Simon Marchi via Gdb-patches Jan. 8, 2022, 12:34 p.m. | #2
Am Samstag, 8. Januar 2022, 12:04:01 MEZ hat Joel Brobecker via Gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:

> Hi Hannes,

>

> On Mon, Jan 03, 2022 at 07:58:54PM +0100, Hannes Domani via Gdb-patches wrote:

> > This patch adds information about _sigsys structure from newer

> > kernels, so that $_siginfo decoding can show information about

> > _sigsys, making it easier for developers to debug seccomp failures.

> >

> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283

>

> Thanks for the patch.

>

> I'm trusting you for the proper definition of the various fields.

> This looks reasonable to me, but before we push this, I'm wondering

> what happens when debugging on a kernel which does not support

> this feature? Is the data undefined? If yes, do we a precendent

> for this already?


As I understood it, if the kernel doesn't support this feature, then it will
never send a SIGSYS signal, and so you wouldn't care about these fields.


Hannes
Simon Marchi via Gdb-patches Jan. 8, 2022, 12:44 p.m. | #3
> > > This patch adds information about _sigsys structure from newer

> > > kernels, so that $_siginfo decoding can show information about

> > > _sigsys, making it easier for developers to debug seccomp failures.

> > >

> > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283

> >

> > Thanks for the patch.

> >

> > I'm trusting you for the proper definition of the various fields.

> > This looks reasonable to me, but before we push this, I'm wondering

> > what happens when debugging on a kernel which does not support

> > this feature? Is the data undefined? If yes, do we a precendent

> > for this already?

> 

> As I understood it, if the kernel doesn't support this feature, then it will

> never send a SIGSYS signal, and so you wouldn't care about these fields.


I see; thanks for clarifying this for me. The patch looks good to me.

Thank you,
-- 
Joel
Simon Marchi via Gdb-patches Jan. 8, 2022, 1:18 p.m. | #4
Am Samstag, 8. Januar 2022, 13:44:15 MEZ hat Joel Brobecker <brobecker@adacore.com> Folgendes geschrieben:

> > > > This patch adds information about _sigsys structure from newer

> > > > kernels, so that $_siginfo decoding can show information about

> > > > _sigsys, making it easier for developers to debug seccomp failures.

> > > >

> > > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24283

> > >

> > > Thanks for the patch.

> > >

> > > I'm trusting you for the proper definition of the various fields.

> > > This looks reasonable to me, but before we push this, I'm wondering

> > > what happens when debugging on a kernel which does not support

> > > this feature? Is the data undefined? If yes, do we a precendent

> > > for this already?

> >

> > As I understood it, if the kernel doesn't support this feature, then it will

> > never send a SIGSYS signal, and so you wouldn't care about these fields.

>

> I see; thanks for clarifying this for me. The patch looks good to me.


Pushed, thanks.


Hannes
Tom Tromey Jan. 10, 2022, 3:12 p.m. | #5
>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:


Hannes> This patch adds information about _sigsys structure from newer
Hannes> kernels, so that $_siginfo decoding can show information about
Hannes> _sigsys, making it easier for developers to debug seccomp failures.

I wonder if this is deserving of a NEWS entry.

Tom
Simon Marchi via Gdb-patches Jan. 16, 2022, 9:39 a.m. | #6
> Hannes> This patch adds information about _sigsys structure from newer

> Hannes> kernels, so that $_siginfo decoding can show information about

> Hannes> _sigsys, making it easier for developers to debug seccomp failures.

> 

> I wonder if this is deserving of a NEWS entry.


Hmm, yeah; I think Tom is right, it does.

-- 
Joel

Patch

diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index 927e69bf1e1..fb2abdd1a21 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -379,6 +379,13 @@  linux_get_siginfo_type_with_fields (struct gdbarch *gdbarch,
   append_composite_type_field (type, "si_fd", int_type);
   append_composite_type_field (sifields_type, "_sigpoll", type);
 
+  /* _sigsys */
+  type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT);
+  append_composite_type_field (type, "_call_addr", void_ptr_type);
+  append_composite_type_field (type, "_syscall", int_type);
+  append_composite_type_field (type, "_arch", uint_type);
+  append_composite_type_field (sifields_type, "_sigsys", type);
+
   /* struct siginfo */
   siginfo_type = arch_composite_type (gdbarch, NULL, TYPE_CODE_STRUCT);
   siginfo_type->set_name (xstrdup ("siginfo"));