From: Doug Evans <dje@google.com>
To: ppluzhnikov@google.com, gdb-patches@sourceware.org
Subject: Re: [RFA] (display_uses_solib_p): Redo loop, scan element list backwards.
Date: Wed, 18 Mar 2009 05:02:00 -0000 [thread overview]
Message-ID: <e394668d0903172148w2cff98baj790edbeb0a0c8a54@mail.gmail.com> (raw)
In-Reply-To: <20090318043626.D9F121C7301@localhost>
On Tue, Mar 17, 2009 at 9:36 PM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> I noticed sigbpt.exp is failing.
> I was getting a "Value out of range" error inside display_uses_solib_p.
> I traced it to the expression elements array being referenced out of bounds.
>
> I think this patch is the right fix.
> The expression elements array needs to be scanned backwards
> when using operator_length: it examines the element at the _end_
> of the array.
>
> Ok to check in?
>
> 2009-03-17 Doug Evans <dje@google.com>
>
> * printcmd.c (display_uses_solib_p): Redo loop, scan element list
> backwards.
>
> Index: printcmd.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/printcmd.c,v
> retrieving revision 1.147
> diff -u -p -r1.147 printcmd.c
> --- printcmd.c 9 Mar 2009 22:38:37 -0000 1.147
> +++ printcmd.c 18 Mar 2009 04:28:26 -0000
> @@ -1763,18 +1763,23 @@ static int
> display_uses_solib_p (const struct display *d,
> const struct so_list *solib)
> {
> - int i;
> + int endpos;
> struct expression *const exp = d->exp;
> + union exp_element *const elts = exp->elts;
>
> if (d->block != NULL
> && solib_contains_address_p (solib, d->block->startaddr))
> return 1;
>
> - for (i = 0; i < exp->nelts; )
> + for (endpos = exp->nelts; endpos > 0; )
> {
> - int args, oplen = 0;
> - const union exp_element *const elts = exp->elts;
> + int i, args, oplen = 0;
>
> + exp->language_defn->la_exp_desc->operator_length (exp, endpos,
> + &oplen, &args);
> + gdb_assert (oplen > 0);
> +
> + i = endpos - oplen;
> if (elts[i].opcode == OP_VAR_VALUE)
> {
> const struct block *const block = elts[i + 1].block;
> @@ -1789,11 +1794,9 @@ display_uses_solib_p (const struct displ
> if (section && section->objfile == solib->objfile)
> return 1;
> }
> - exp->language_defn->la_exp_desc->operator_length (exp, i + 1,
> - &oplen, &args);
> - gdb_assert (oplen > 0);
> - i += oplen;
> + endpos -= oplen;
> }
> +
> return 0;
> }
>
>
btw, this was tested by singlestepping through display_uses_solib_p
with several moderately complex display expressions.
E.g.,
display/x ($pc + 123) * 321
before and after the patch is enough to see the problem.
next prev parent reply other threads:[~2009-03-18 4:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 4:49 Doug Evans
2009-03-18 5:02 ` Doug Evans [this message]
2009-03-18 5:45 ` Paul Pluzhnikov
2009-03-18 15:00 ` Joel Brobecker
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=e394668d0903172148w2cff98baj790edbeb0a0c8a54@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=ppluzhnikov@google.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