This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v1] Synchronize siginfo type described in GDB with the kernel and glibc ones.
- From: Pedro Alves <palves at redhat dot com>
- To: "Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>, Joel Brobecker <brobecker at adacore dot com>, "Yao Qi <yao at codesourcery dot com> (yao at codesourcery dot com)" <yao at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 19 Nov 2015 17:07:08 +0000
- Subject: Re: [PATCH v1] Synchronize siginfo type described in GDB with the kernel and glibc ones.
- Authentication-results: sourceware.org; auth=none
- References: <1445864086-4831-1-git-send-email-walfred dot tedeschi at intel dot com> <1445864086-4831-3-git-send-email-walfred dot tedeschi at intel dot com> <20151118230151 dot GA7958 at adacore dot com> <AC542571535E904D8E8ADAE745D60B19444FBC60 at IRSMSX104 dot ger dot corp dot intel dot com> <564DCE42 dot 5060000 at redhat dot com> <AC542571535E904D8E8ADAE745D60B19444FC2A6 at IRSMSX104 dot ger dot corp dot intel dot com>
On 11/19/2015 04:40 PM, Tedeschi, Walfred wrote:
> Pedro,
>
> If I understood you right you are in favour of keeping the siginfo as global one?
> In case this is correct, I will start working on the code you pointed out.
I favor not querying whether the running x86 kernel supports the extra field.
But I wouldn't say I'm in favor of exposing the field in all targets -- more
like, if it's hard and we really want to be lazy, I see no real big harm in
making the change affect all archs, though I'd mildly prefer making the change
be x86-specific, like glibc did. I actually think it'd be simple. IIRC, Yao
already suggested how to do it without much changes. Simply rename the existing
linux_get_siginfo_type function, and add a new parameter that allows
saying "I want field X". Then the x86 version can install a siginfo type with
the field, while other ports not.
e.g.,
enum linux_siginfo_extra_field_values
{
LINUX_SIGINFO_FIELD_ADDR_BND = 1,
...
};
DEF_ENUM_FLAGS_TYPE (enum linux_siginfo_extra_field_values, linux_siginfo_extra_fields);
static struct type *
linux_get_siginfo_type_with_fields (struct gdbarch *gdbarch,
linux_siginfo_extra_fields extra_fields)
{
...
if ((extra_fields & LINUX_SIGINFO_FIELD_ADDR_BND) != 0)
{
...
}
}
static struct type *
linux_get_siginfo_type (struct gdbarch *gdbarch)
{
return linux_get_siginfo_type_with_fields (gdbarch, 0);
}
x86:
x86_linux_get_siginfo_type_with_fields (struct gdbarch *gdbarch,
linux_siginfo_extra_fields extra_fields)
{
return linux_get_siginfo_type_with_fields (gdbarch,
LINUX_SIGINFO_FIELD_ADDR_BND);
}
...
set_gdbarch_get_siginfo_type (gdbarch, x86_linux_get_siginfo_type_with_fields);
...
>
> What I could see from the glibc code the structure is reset via memset.
Actually, gdb reads the siginfo object out of the kernel directly, so whatever
glibc does has no bearing here. The question is whether the kernel really
shows garbage in those fields when si_code is not 3, or whether it always
pre-fills the siginfo objects (including the padding) with zeroes.
>
> Thanks a lot for your feedback!
> Muito obrigado!
You're welcome. De nada. ;-)
Thanks,
Pedro Alves