Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Cary Coutant <ccoutant@google.com>
To: Doug Evans <dje@google.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [RFC] better dwarf checking for values on the stack
Date: Tue, 15 Sep 2009 20:20:00 -0000	[thread overview]
Message-ID: <c17be2b30909151320l7a4a5a0cnd7857e965249620a@mail.gmail.com> (raw)
In-Reply-To: <e394668d0909141604h4ca3d193o3f3113f209aea851@mail.gmail.com>

>        * dwarf2expr.c (dwarf_expr_grow_stack): Update calculation of
>        size of stack value.
>        (dwarf_expr_push): New arg in_stack_memory, all callers updated.
>        (dwarf_expr_fetch_in_stack_memory): New function.
>        (add_piece): Set in_stack_memory for non-literal values.
>        (execute_stack_op): Allow ops to specify where the value is on the
>        program's stack.
>        (execute_stack_op, case DW_OP_fbreg): Mark value as in stack memory.
>        (execute_stack_op, case DW_OP_call_frame_cfa): Ditto.
>        (execute_stack_op, case DW_OP_dup): Copy in_stack_memory flag.
>        (execute_stack_op, cases DW_OP_pick, DW_OP_over): Ditto.
>        (execute_stack_op, cases DW_OP_swap, DW_OP_rot): Update type of
>        dwarf stack value.

It seems to me that if you're going to go this route (rather than the
heuristic approach of your first patch), you need to do some type
algebra here. You've got three types of things on the expression
stack; let's call them M (generic addresses, probably not on the
memory stack), S (addresses of things on the memory stack), and K
(unitless constants). There are combining rules for these types; for
example:

  K <anyop> K -> K
  M +/- K -> M
  K +/- M -> M
  M - M -> K
  S +/- K -> S
  K +/- S -> S
  S - S -> K

There are combinations that don't make sense, but aren't technically
illegal in the DWARF spec, so these will need to be handled
conservatively; for example:

  M + M -> M
  M * M -> M
  M + S -> M

You could have an expression like S - S + M [ = (S - S) + M = K + M ->
M ] -- admittedly unlikely, but the same can be said for Tom's example
that fooled the heuristic approach -- which should yield a memory
address, but from what I can tell will end up claiming it's a stack
address.

-cary


  parent reply	other threads:[~2009-09-15 20:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-10 23:21 Doug Evans
2009-09-11 18:48 ` Tom Tromey
2009-09-11 21:19   ` Doug Evans
2009-09-11 23:23     ` Doug Evans
2009-09-12  0:40       ` Doug Evans
2009-09-14 17:54       ` Tom Tromey
2009-09-14 23:04         ` Doug Evans
2009-09-15 16:05           ` Tom Tromey
2009-09-15 16:10             ` Joel Brobecker
2009-09-15 16:22               ` Doug Evans
2009-09-15 20:20           ` Cary Coutant [this message]
2009-09-15 20:36             ` Doug Evans
2009-09-15 20:47               ` Cary Coutant

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=c17be2b30909151320l7a4a5a0cnd7857e965249620a@mail.gmail.com \
    --to=ccoutant@google.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@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