public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [0/4] RFC: add DWARF index support
Date: Mon, 09 Aug 2010 20:36:00 -0000	[thread overview]
Message-ID: <m34of3h6bn.fsf@fleche.redhat.com> (raw)
In-Reply-To: <AANLkTi=+bdMUtn6JcwHRMJrvT42=-ToAeM-S81KOGrcG@mail.gmail.com>	(Doug Evans's message of "Fri, 6 Aug 2010 13:52:50 -0700")

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> I don't want to unnecessarily delay the patch (given, for example, its
Doug> size), but not generating an index file when asked to and not flagging
Doug> an error feels wrong at a gut level.

For our particular use (RPM builds), we'll just ignore errors anyhow,
because (IMO) it is more important for the build to succeed than for
this optimization to be applied.

There are a few problems here if you want it to work the other way.

First, main.c doesn't play well with errors.  When processing -ex
arguments we just ignore error returns, and then later call quit_force,
which exits with status 0.  I think this makes sense to change, but I
have not thought through all the ramifications, or tried to research the
history.

Second, save_gdb_index_command prints the error but doesn't propagate
it.  Since it loops over all objfiles this seemed nicest.  But, we don't
use it that way from this script; maybe we could add a "-fail" option to
the command or something like that.

I think I will just revert the gdb-add-index.sh addition, since it has
too many problems.  I'll revisit it when I can spend some time fixing up
-batch.  I'll send a reversion patch tomorrow.

Doug> E.g., I wonder what should happen if there isn't enough (or any) info
Doug> to generate .gdb-index.
Doug> Is that an error?

I guess it could be.  I don't really care much about the various
pathological cases.

Doug> I hate to add another wrinkle, and thanks for bearing with me.
Doug> I just tried passing a file that doesn't exist.  gdb writes something
Doug> to stderr and then exits with a zero exit code.
Doug> That needs to be flagged as an error (presumably with test -r or some
Doug> such before invoking gdb) , but it could be deferred to another patch.

This is the main.c problem.  The "file" command fails, but that doesn't
affect operation.

Tom

  reply	other threads:[~2010-08-09 20:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-30 22:33 Tom Tromey
2010-07-09 17:31 ` Tom Tromey
2010-07-09 17:45   ` Eli Zaretskii
2010-07-09 20:26     ` Tom Tromey
2010-07-10  7:03       ` Eli Zaretskii
2010-07-12 16:52         ` Tom Tromey
2010-07-22 11:31   ` Jan Kratochvil
2010-07-22 15:54     ` Tom Tromey
2010-07-30 20:46   ` Tom Tromey
2010-08-02 18:10     ` Doug Evans
2010-08-05 16:30       ` Tom Tromey
2010-08-05 16:32         ` Doug Evans
2010-08-05 19:55           ` Tom Tromey
2010-08-05 19:57           ` Tom Tromey
2010-08-06 17:15             ` Doug Evans
2010-08-06 17:40               ` Tom Tromey
2010-08-06 20:53                 ` Doug Evans
2010-08-09 20:36                   ` Tom Tromey [this message]
2010-08-09 21:16                     ` Doug Evans
2010-08-10 18:46                       ` Tom Tromey
2010-08-10 18:57                         ` Doug Evans
2010-08-09 20:25                 ` Jan Kratochvil
2010-08-09 20:43                   ` Tom Tromey
2010-08-09 20:33                 ` Jan Kratochvil
2010-07-13 20:42 ` Tom Tromey
2010-07-22  4:28   ` Paul Pluzhnikov
2010-07-22 14:14     ` Tom Tromey
2010-07-22 15:54       ` Tom Tromey
2010-07-22 16:20         ` Paul Pluzhnikov
2010-07-22 20:54         ` Tom Tromey
2010-07-23 22:12           ` Tom Tromey
2010-07-26 18:41             ` Ken Werner
2010-07-26 18:50               ` Tom Tromey
2010-07-27  7:58                 ` Ken Werner

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=m34of3h6bn.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).