Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: [0/2] Inspect extra signal information
Date: Tue, 13 Jan 2009 11:05:00 -0000	[thread overview]
Message-ID: <200901131105.34822.pedro@codesourcery.com> (raw)
In-Reply-To: <200901122324.n0CNOGrH019079@brahms.sibelius.xs4all.nl>

Hi Mark,

Thanks for taking a look, and for your comments.

On Monday 12 January 2009 23:24:16, Mark Kettenis wrote:

> One thing I wonder about is whether it really is a good idea to is the
> obfuscated typenames like __uid_t instead of a straight uid_t.  I
> realize that is the way the type is defined in headers, but in GDB we
> don't really have to worry about namespace pollution.

I don't really have much of an opinion here.  I didn't think of a reason
to be different, so I just cloned the types from glibc's headers.  I
can change that if you think it's important.

> The other thing I worry about is padding for these structure types
> that may be necessary on some platforms.  Does your code handle that?

I think so.  That is handled on the synthesized type itself.
There's this in linux_get_siginfo_type:

+  {
+    const int si_max_size = 128;
+    int si_pad_size;
+    int size_of_int = gdbarch_int_bit (gdbarch) / HOST_CHAR_BIT;
+
+    /* _pad */
+    if (gdbarch_ptr_bit (gdbarch) == 64)
+      si_pad_size = (si_max_size / size_of_int) - 4;
+    else
+      si_pad_size = (si_max_size / size_of_int) - 3;
+    append_composite_type_field (sifields_type, "_pad",
+                                init_vector_type (int_type, si_pad_size));
+  }

Which mimics this, in glibc's headers:

# define __SI_MAX_SIZE     128
# if __WORDSIZE == 64
#  define __SI_PAD_SIZE     ((__SI_MAX_SIZE / sizeof (int)) - 4)
# else
#  define __SI_PAD_SIZE     ((__SI_MAX_SIZE / sizeof (int)) - 3)
# endif

 struct siginfo
   {
     int si_signo;
     int si_errno;
     int si_code;
 
     union
       {
         int _pad[__SI_PAD_SIZE]; <<<


There's also this change, that allows us to add a field to
a struct with enforced alignment > 0:

 void
-append_composite_type_field (struct type *t, char *name,
-                            struct type *field)
+append_composite_type_field_aligned (struct type *t, char *name,
+                                    struct type *field, int alignment)
 {
   struct field *f;
   TYPE_NFIELDS (t) = TYPE_NFIELDS (t) + 1;
@@ -1860,12 +1860,31 @@ append_composite_type_field (struct type
     {
       TYPE_LENGTH (t) = TYPE_LENGTH (t) + TYPE_LENGTH (field);
       if (TYPE_NFIELDS (t) > 1)
-       FIELD_BITPOS (f[0]) = (FIELD_BITPOS (f[-1])
-                              + (TYPE_LENGTH (FIELD_TYPE (f[-1]))
-                                 * TARGET_CHAR_BIT));
+       {
+         FIELD_BITPOS (f[0]) = (FIELD_BITPOS (f[-1])
+                                + (TYPE_LENGTH (FIELD_TYPE (f[-1]))
+                                   * TARGET_CHAR_BIT));
+
+         if (alignment)
+           {
+             int left = FIELD_BITPOS (f[0]) % (alignment * TARGET_CHAR_BIT);
+             if (left)
+               {
+                 FIELD_BITPOS (f[0]) += left;
+                 TYPE_LENGTH (t) += left / TARGET_CHAR_BIT;
+               }
+           }
+       }
     }
 }

It is used to add the _sifields field to ``struct siginfo'' aligned to
``TYPE_LENGTH (long_type)'', with:

+  append_composite_type_field_aligned (siginfo_type,
+                                      "_sifields", sifields_type,
+                                      TYPE_LENGTH (long_type));

-- 
Pedro Alves


  reply	other threads:[~2009-01-13 11:05 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-12 18:47 Pedro Alves
2009-01-12 18:49 ` Pedro Alves
2009-01-12 18:52   ` [1/2] " Pedro Alves
2009-01-12 19:40     ` Eli Zaretskii
2009-02-02 16:51       ` Pedro Alves
2009-02-02 21:04         ` Eli Zaretskii
2009-02-05  1:14           ` Pedro Alves
2009-02-05 20:30             ` Eli Zaretskii
2009-02-06 23:31               ` Pedro Alves
2009-01-12 18:50 ` [2/2] " Pedro Alves
2009-01-12 19:39   ` Eli Zaretskii
2009-01-13 12:32     ` Pedro Alves
2009-01-13 18:55       ` Eli Zaretskii
2009-01-13 19:08         ` Pedro Alves
2009-01-13 19:15           ` Eli Zaretskii
2009-02-06 23:35         ` Pedro Alves
2009-02-09  6:23           ` Paul Pluzhnikov
2009-02-09 22:17             ` Pedro Alves
2009-04-06 19:00               ` Paul Pluzhnikov
2009-04-06 19:18                 ` relying on testsuite results Thiago Jung Bauermann
2009-04-06 19:33                   ` Paul Pluzhnikov
2009-04-06 19:57                     ` Daniel Jacobowitz
2009-04-06 19:51                   ` Tom Tromey
2009-04-06 20:22                     ` Mark Kettenis
2009-04-07 14:57                 ` [2/2] Inspect extra signal information Pedro Alves
2009-01-12 23:27 ` [0/2] " Mark Kettenis
2009-01-13 11:05   ` Pedro Alves [this message]
2009-01-13 18:42     ` Eli Zaretskii
2009-01-13 18:50       ` Pedro Alves
2009-01-13 19:19         ` Eli Zaretskii
2009-01-13 19:37           ` Pedro Alves
2009-01-13 19:47             ` Pedro Alves
2009-02-02 14:40               ` Pedro Alves
2009-02-02 20:49                 ` Mark Kettenis
2009-02-03 15:02 ` Pedro Alves
2009-02-03 16:42   ` Ulrich Weigand
2009-02-03 18:06     ` Daniel Jacobowitz
2009-02-03 18:24       ` Pedro Alves
2009-02-03 19:04         ` Daniel Jacobowitz
2009-02-03 19:51           ` Pedro Alves
2009-02-03 23:18             ` Doug Evans
2009-02-03 23:50               ` Pedro Alves
2009-02-04  0:17                 ` Doug Evans
2009-02-04  0:24             ` Daniel Jacobowitz
2009-02-04  0:49               ` Pedro Alves
2009-02-04 21:02                 ` [3/2] Inspect extra signal information, handle amd64 bi-arch gdb Pedro Alves
2009-02-04 21:17                   ` Daniel Jacobowitz
2009-02-06 23:37                     ` Pedro Alves
2009-02-07  2:28                       ` Paul Pluzhnikov
2009-02-07 14:56                         ` Pedro Alves
2009-02-07 16:14                           ` Paul Pluzhnikov
2009-02-04 22:07                   ` Doug Evans
2009-02-03 18:23     ` [0/2] Inspect extra signal information Pedro Alves

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=200901131105.34822.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /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