Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: dberlin@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: Option to elide single-bit bitfields when printing structures
Date: Tue, 27 Feb 2001 00:17:00 -0000	[thread overview]
Message-ID: <20010227001652.H27567@wolery.stanford.edu> (raw)
In-Reply-To: <Pine.SUN.3.91.1010225094511.10629L-100000@is>

On Sun, Feb 25, 2001 at 09:51:13AM +0200, Eli Zaretskii wrote:
> 
> On Sat, 24 Feb 2001, Zack Weinberg wrote:
> 
> > > Then IMHO this feature is less helpful than it could be.  See the list
> > > above: can you really remember all of the flags if they are not shown?
> > > And if half of them are shown, is it really easy to know which are and
> > > which aren't?
> > 
> > Perhaps you are not familiar with the way these flags get used in gcc.
> 
> I thought you were proposing a general-purpose feature, not something 
> specific to GCC.

I am proposing a general-purpose feature.  The GCC usage is a specific
example of why it would be useful.

> > GCC already has a prettyprinter you can call from the debugger for
> > these things, which obeys the same convention.  The problem with it is
> > that if the structure is damaged, the prettyprinter is liable to
> > crash.
> 
> Perhaps it would be better to make the GCC prettyprinter more robust in 
> the face of such calamities.  After all, GDB doesn't do anything that any 
> other program cannot do, to avoid crashing when accessing invalid 
> addresses and corrupted data structures.

Oh really?  GDB gets a nice EFAULT/EIO error return from ptrace(2)
when it tries to dereference wild pointers.  The prettyprinter runs in
inferior context and gets SIGSEGV when it does that.  We'd have to
trap it and longjmp out.  The complexity cost would be huge.

Unless you're saying GCC could ptrace itself...

zw


  reply	other threads:[~2001-02-27  0:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20010222115633.B11707@wolery.stanford.edu>
     [not found] ` <200102230756.CAA06304@indy.delorie.com>
2001-02-23  7:03   ` Daniel Berlin
     [not found]     ` <6137-Fri23Feb2001183455+0200-eliz@is.elta.co.il>
2001-02-24 13:10       ` Zack Weinberg
2001-02-24 23:53         ` Eli Zaretskii
2001-02-27  0:17           ` Zack Weinberg [this message]
2001-02-27 11:04             ` Eli Zaretskii
2001-02-27 11:44               ` Daniel Berlin
2001-02-27 14:41               ` Michael Snyder
2001-02-23 10:09   ` Michael Snyder
2001-02-24 13:05     ` Zack Weinberg
2001-02-24 23:54       ` Eli Zaretskii
2001-02-27  0:13         ` Zack Weinberg

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=20010227001652.H27567@wolery.stanford.edu \
    --to=zackw@stanford.edu \
    --cc=dberlin@redhat.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.redhat.com \
    /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