Re: [0/4] RFC: add DWARF index support

[Doug Evans <dje@google.com>]

On Mon, Aug 9, 2010 at 1:36 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "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.

Are you sure you'll just ignore *all* such errors?

I suspect you'd want to at least catch, for example, spelling errors
in file names passed to the script.
Otherwise you'll trip over problems downstream when simple things such
as this could be caught up front.

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

Yep.

> 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.

Well, -fail should be the default, and if one wants gdb to be usable
in these kinds of scripting situations, error catching should be a
general facility rather than adhoc additions to particular commands.

For reference sake, some alternatives:
- don't loop, specify the objfile instead?
- don't exit half-completed
   - e.g. if one fails they all fail

> 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.

Well, there are various kinds of pathological cases.
I think we should at least invest time thinking about things the user
is likely to trip over.
[I'd also want to make sure we're on the same page as to what is
pathological, I suspect we are not.]

> 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.

Right, but this is a common thing that can be tripped over, and
trivially dealt with in the script (e.g. with test -r), at least until
gdb supports being scripted better.
[For pedantic completeness sake, there would a window between doing
the test -r and the file command, but *I'm* not suggesting handling
that *pathological* case! :-)]