From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20501 invoked by alias); 13 Jan 2009 19:37:43 -0000 Received: (qmail 20487 invoked by uid 22791); 13 Jan 2009 19:37:41 -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 19:37:05 +0000 Received: (qmail 19663 invoked from network); 13 Jan 2009 19:37:03 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Jan 2009 19:37:03 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [0/2] Inspect extra signal information Date: Tue, 13 Jan 2009 19:37:00 -0000 User-Agent: KMail/1.9.10 Cc: mark.kettenis@xs4all.nl References: <200901121846.51709.pedro@codesourcery.com> <200901131850.01687.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901131937.26135.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/msg00296.txt.bz2 On Tuesday 13 January 2009 19:18:05, Eli Zaretskii wrote: > The problem is not to clash with GDB code elsewhere, the problem is > the possibility of a clash with the library. A library implementation When I meant user code, I didn't mean *GDB* code, which of course it can't collide with, because I wrote literal strings, not identifiers. I meant code that isn't part of the C (library) implementation. > is free to change the symbol it uses for this any time, and use the > __uid_t one for something utterly incompatible. Since the name begins > with 2 underscores, the library implementation doesn't need to bother > being back-compatible, because such names are off-limits for user code. No, it is allowed to assume that the type name will not collide with any user defined type. It's only about namespace, that's all. Things will surelly break if the type changes to something else incompatible. In any case, user code will want to be using the si_pid, si_uid, si_status, si_addr, etc, X/Open macros. I'm *really exposing* C library internals. > > > Also, these are also the types you'd see if I wasn't synthesizing > > it, but using the debug info instead, in case it is available --- I > > was actually doing that in a previous version of the patch, and > > synthesized the type only as a fallback, but, then considered that > > if we're synthesizing sometimes, might as well make it simpler and > > always synthesize -- less cases, less bugs, less maintenance. > > Sorry, I don't follow: what do you mean by ``synthesizing''? It means that I'm building the ``struct type'' that represents this siginfo_t type "manually", instead of relying on debug info for it being available. What I was aiming for, is to see the same you see when you do this (this is from the already in tree siginfo-addr.exp BTW): static void handler (int sig, siginfo_t *info, void *context) { if (info->si_addr == p) printf ("Correct si_addr value.\n"); else printf ("Got si_addr = %p, expected %p.\n", info->si_addr, p); _exit (0); } static void *p; int main (void) { (...) /* Trigger SIGSEGV. */ *(int *)p = 0; return 0; } (gdb) b handler Breakpoint 1 at 0x40070b: file ../../../src/gdb/testsuite/gdb.base/siginfo-addr.c, line 32. (gdb) r Starting program: /home/pedro/gdb/siginfo/build/gdb/testsuite/gdb.base/siginfo-addr Program received signal SIGSEGV, Segmentation fault. 0x000000000040081b in main () at ../../../src/gdb/testsuite/gdb.base/siginfo-addr.c:66 66 *(int *)p = 0; (gdb) c Continuing. Breakpoint 1, handler (sig=11, info=0x7fffffffe130, context=0x7fffffffe000) at ../../../src/gdb/testsuite/gdb.base/siginfo-addr.c:32 32 if (info->si_addr == p) (gdb) (gdb) ptype info->_sifields type = union { int _pad[28]; struct { __pid_t si_pid; __uid_t si_uid; } _kill; struct { int si_tid; int si_overrun; sigval_t si_sigval; } _timer; struct { __pid_t si_pid; __uid_t si_uid; sigval_t si_sigval; } _rt; struct { __pid_t si_pid; __uid_t si_uid; int si_status; __clock_t si_utime; __clock_t si_stime; } _sigchld; struct { void *si_addr; } _sigfault; struct { long int si_band; int si_fd; } _sigpoll; } (gdb) Notice that these types came from debug info (but only because I siginfo_t, which will not be the common case). Versus the synthesized: (gdb) r Starting program: /home/pedro/gdb/siginfo/build/gdb/testsuite/gdb.base/siginfo-addr During symbol reading, DW_AT_name missing from DW_TAG_base_type. Program received signal SIGSEGV, Segmentation fault. 0x000000000040081b in main () at ../../../src/gdb/testsuite/gdb.base/siginfo-addr.c:66 66 *(int *)p = 0; (gdb) ptype $_siginfo._sifields type = union { int _pad[28]; struct { __pid_t si_pid; __uid_t si_uid; } _kill; struct { int si_tid; int si_overrun; sigval_t si_sigval; } _timer; struct { __pid_t si_pid; __uid_t si_uid; sigval_t si_sigval; } _rt; struct { __pid_t si_pid; __uid_t si_uid; int si_status; __clock_t si_utime; __clock_t si_stime; } _sigchld; struct { void *si_addr; } _sigfault; struct { long si_band; int si_fd; } _sigpoll; } -- Pedro Alves