From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27029 invoked by alias); 10 Feb 2009 10:08:04 -0000 Received: (qmail 27014 invoked by uid 22791); 10 Feb 2009 10:08:03 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Feb 2009 10:07:57 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n1AA6Y7p022126; Tue, 10 Feb 2009 11:06:34 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n1AA6Xgq012736; Tue, 10 Feb 2009 11:06:33 +0100 (CET) Date: Tue, 10 Feb 2009 10:08:00 -0000 Message-Id: <200902101006.n1AA6Xgq012736@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: dje@google.com, gdb@sourceware.org In-reply-to: <200902092255.03612.pedro@codesourcery.com> (message from Pedro Alves on Mon, 9 Feb 2009 22:55:03 +0000) Subject: Re: new siginfo support doesn't build on glibc 2.2.2 References: <200902092255.03612.pedro@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00076.txt.bz2 > From: Pedro Alves > Date: Mon, 9 Feb 2009 22:55:03 +0000 > > On Monday 09 February 2009 21:07:41, Doug Evans wrote: > > fyi, glibc 2.2.2 doesn't have si_timerid, si_overrun. compilation of > > amd64-linux-nat.c fails. > > Bummer. According to sigaction(2), those exist only since kernel > 2.6. Those are defines, we could #ifdef on them, assuming we're > ok with a gdb built on that platform and then moved to some more > recent glibc will not translate those fields. Isn't it fun having an OS where the kernel and C library are seperate projects that are hardy ever fully in sync? > I don't know if the siginfo layout in that version is the same > as defined by the gdbarch callback, or even if your glibc's siginfo_t > declaration matches your kernel's siginfo_t object layout --- there's > a history of breakage on these matters. I doubt there is actual breakage. The total size of siginfo_t should not have changed between kernel releases. What may have happened is that there have been new structs added to the union part of siginfo_t, or that existing structs in there have been extended.