Tom> I have since changed this. For explicitly-typed values, I tried
Tom> DW_OP_shr and DW_OP_shra identically. The type encodes the desired
Tom> operation.
Jakub pinged me on irc to say that this is not what GCC actually emits.
So, I am going to change GDB to follow. That is, GDB will pick a
s
Just for the record...
Tom> What my patch does now is that it generally uses a signed integer type
Tom> of the appropriate width for "legacy" DWARF values. Then, for mod, if
Tom> the value's type is this special type, it converts it to an
Tom> identically-sized unsigned type, and converts back af
On Tue, May 3, 2011 at 6:33 AM, H.J. Lu wrote:
> On Sat, Apr 16, 2011 at 1:11 AM, Jakub Jelinek wrote:
>> On Fri, Mar 25, 2011 at 12:32:37PM +0100, Jakub Jelinek wrote:
>>> As I said in my GCC Summit talk, currently we just give up on
>>> any floating point/_Decimal*/__int128 and for 32-bit targe
> "Jakub" == Jakub Jelinek writes:
Tom> Should DW_OP_bra be restricted to integral types? Several other opcodes
Jakub> Yes. If you want to test other types, just compare them against 0
Jakub> using DW_OP_ne etc.
Great, thanks.
Tom> Currently, the comparison operators are all defined as p
On Wed, May 04, 2011 at 12:04:40PM -0600, Tom Tromey wrote:
> Should DW_OP_bra be restricted to integral types? Several other opcodes
Yes. If you want to test other types, just compare them against 0
using DW_OP_ne etc.
> Currently, the comparison operators are all defined as performing signed
> Should DW_OP_bra be restricted to integral types? Several other opcodes
> are restricted in this way, and it seems like an oversight to me that
> DW_OP_bra is lacking this restriction. (I've added this restriction in
> GDB.)
Yes, that was an oversight.
> Currently, the comparison operators ar
> "Jakub" == Jakub Jelinek writes:
Jakub> This patch on top of
Jakub> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01224.html
Jakub> and
Jakub> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01723.html
Jakub> implements parts of Cary's typed DWARF stack proposal:
Jakub> http://www.dwarfstd.org/
On Sat, Apr 16, 2011 at 1:11 AM, Jakub Jelinek wrote:
> On Fri, Mar 25, 2011 at 12:32:37PM +0100, Jakub Jelinek wrote:
>> As I said in my GCC Summit talk, currently we just give up on
>> any floating point/_Decimal*/__int128 and for 32-bit targets even
>> long long expressions, as those can't be r
On 04/16/2011 04:11 AM, Jakub Jelinek wrote:
+ case dw_val_class_const_double:
+ {
+ unsigned HOST_WIDE_INT first, second;
+ l = 2 * HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR;
+
+ dw2_asm_output_data (1, l, NULL);
+ if (WORDS_BIG
On Fri, Mar 25, 2011 at 09:44:40AM -0700, Roland McGrath wrote:
> It's been a while since I read Cary's proposal, and I am no longer
> likely to do much work of my own in this area. So I'll just respond at
> the high level.
>
> I like very much the essential notion of the stack being of typed
> e
> This patch on top of
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01224.html
> and
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01723.html
> implements parts of Cary's typed DWARF stack proposal:
> http://www.dwarfstd.org/doc/040408.1.html
I haven't looked at the patch yet, but this sounds g
It's been a while since I read Cary's proposal, and I am no longer
likely to do much work of my own in this area. So I'll just respond at
the high level.
I like very much the essential notion of the stack being of typed
entities with no specification of how the consumer actually implements
it. I
12 matches
Mail list logo
