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

["Tedeschi, Walfred" <walfred dot tedeschi at intel dot com>]

Hello Pedro,

Thanks a lot for your feedback!

Moving forward on this patch I observed that there is fixup for 32 and x32 on gdbserver and gdb side.
I  suppose we should join both implementation so we patch only once every time! :)

To do that I was wondering where should be the appropriated place, the "nat" or the "common" folder.


Thanks and regards,

-Fred



-----Original Message-----
From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Pedro Alves
Sent: Thursday, November 19, 2015 6:07 PM
To: Tedeschi, Walfred; Joel Brobecker; Yao Qi <yao@codesourcery.com> (yao@codesourcery.com)
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v1] Synchronize siginfo type described in GDB with the kernel and glibc ones.

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
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928