Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org,  Eli Zaretskii <eliz@gnu.org>
Cc: mark.kettenis@xs4all.nl
Subject: Re: [0/2] Inspect extra signal information
Date: Tue, 13 Jan 2009 19:37:00 -0000	[thread overview]
Message-ID: <200901131937.26135.pedro@codesourcery.com> (raw)
In-Reply-To: <umydvauc2.fsf@gnu.org>

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


  reply	other threads:[~2009-01-13 19:37 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
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 [this message]
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=200901131937.26135.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=eliz@gnu.org \
    --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