From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 646 invoked by alias); 13 Jan 2009 11:05:52 -0000 Received: (qmail 635 invoked by uid 22791); 13 Jan 2009 11:05:51 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Jan 2009 11:05:15 +0000 Received: (qmail 21348 invoked from network); 13 Jan 2009 11:05:13 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Jan 2009 11:05:13 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [0/2] Inspect extra signal information Date: Tue, 13 Jan 2009 11:05:00 -0000 User-Agent: KMail/1.9.10 Cc: Mark Kettenis References: <200901121846.51709.pedro@codesourcery.com> <200901122324.n0CNOGrH019079@brahms.sibelius.xs4all.nl> In-Reply-To: <200901122324.n0CNOGrH019079@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901131105.34822.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00276.txt.bz2 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