From: Jakub Jelinek <jakub@redhat.com>
To: Tom Tromey <tromey@redhat.com>, Cary Coutant <ccoutant@google.com>
Cc: Ulrich Weigand <uweigand@de.ibm.com>, gdb-patches@sourceware.org
Subject: Re: RFC: implement typed DWARF stack
Date: Tue, 17 May 2011 08:35:00 -0000 [thread overview]
Message-ID: <20110517083521.GZ17079@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <m3iptah607.fsf@fleche.redhat.com>
On Mon, May 16, 2011 at 12:09:28PM -0600, Tom Tromey wrote:
> CCing Jakub.
>
> Ulrich> So just to clarify: in the discussion a while back, you said:
>
> Sorry for any confusion. I hope this email will clear it up.
>
> During our discussion I was convinced that DW_OP_shr should generally
> use the sign of any explicit type to decide what to do (with a special
> case for implicit type). However, Jakub informed me that GCC relied on
> 'shr' always zero-filling, even for explicit types. So, I changed the
> code back. What is now in the tree implements the same semantics that
> GCC assumes.
My point is that we have two right shift operations, DW_OP_shr{,a}, so
it is IMHO better to just keep them as two operations even for typed
stack. The type in that case is used only for the size of the shift,
whether the upper bits are filled with 0s or msb is determined by the
operation. DW_OP_mod or DW_OP_div are different, there is just one
operation, so it has some default for untyped arguments (unsigned for
mod, signed for div) and for typed operands both type's size and signedness
matter.
If DW_OP_shr{,a} was the same, the producer would often need to add
additional DW_OP_convert ops.
OT, DW_OP_mod should be documented as:
"This operation operates only on integral values."
and DW_OP_const_type description uses "The second operand" twice, where
"The third operand" should be used in the second occurrence.
Jakub
next prev parent reply other threads:[~2011-05-17 8:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 20:48 Tom Tromey
2011-05-05 16:47 ` Tom Tromey
2011-05-05 18:07 ` Ulrich Weigand
2011-05-05 18:38 ` Tom Tromey
2011-05-05 20:15 ` Tom Tromey
2011-05-09 22:02 ` Ulrich Weigand
2011-05-10 14:15 ` Tom Tromey
2011-05-11 0:15 ` Ulrich Weigand
2011-05-11 14:59 ` Tom Tromey
2011-05-11 19:44 ` Tom Tromey
2011-05-12 0:03 ` Ulrich Weigand
2011-05-12 16:33 ` Tom Tromey
2011-05-13 7:52 ` Regression: " Jan Kratochvil
2011-05-13 15:44 ` Tom Tromey
2011-05-15 8:26 ` gdbindex crash: " Jan Kratochvil
2011-05-16 17:37 ` Tom Tromey
2011-05-17 17:01 ` Tom Tromey
2011-05-13 17:17 ` Tom Tromey
2011-05-13 17:34 ` Jan Kratochvil
2011-05-12 19:32 ` Tom Tromey
2011-05-16 15:50 ` Ulrich Weigand
2011-05-16 18:09 ` Tom Tromey
2011-05-17 8:35 ` Jakub Jelinek [this message]
2011-06-03 13:52 ` Tom Tromey
2011-05-10 16:39 ` Tom Tromey
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=20110517083521.GZ17079@tyan-ft48-01.lab.bos.redhat.com \
--to=jakub@redhat.com \
--cc=ccoutant@google.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
--cc=uweigand@de.ibm.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