Re: [PATCH v1] Synchronize siginfo type described in GDB with the kernel and glibc ones.

[Pedro Alves <palves at redhat 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