On 06/04/2015 08:27 AM, Jan Kratochvil wrote:
On Thu, 04 Jun 2015 16:00:18 +0200, Jeff Law wrote:
But my assertion is that stuff like what you've shown above simply isn't
important to handle. What we need to look at are the common cases and I
haven't seen a strong argument that the common case
On Thu, 04 Jun 2015 16:00:18 +0200, Jeff Law wrote:
> But my assertion is that stuff like what you've shown above simply isn't
> important to handle. What we need to look at are the common cases and I
> haven't seen a strong argument that the common cases can't be handled by
> gdb.
If we target
On 06/04/2015 01:36 AM, Jan Kratochvil wrote:
On Thu, 04 Jun 2015 09:24:36 +0200, Manuel López-Ibáñez wrote:
On 3 June 2015 at 22:58, Jan Kratochvil wrote:
In general parsing LHS vs. RHS is not so trivial:
*array1@10
expression wrapped into ->
(*array2+"a@c"[1]+'@'+
On Thu, 04 Jun 2015 10:55:59 +0200, Jakub Jelinek wrote:
> (gdb) p *(int (*)[4])&a[0]
> $1 = {1, 2, 3, 4}
> (gdb) p *(char (*)[4])&b[1]
> $2 = "bcde"
>
> Though, admittedly that is more typing than a[0]@4 or b[1]@4 .
I forgot during this discussion about the C style cast, you are right.
For some
On Thu, Jun 04, 2015 at 10:36:46AM +0200, Manuel López-Ibáñez wrote:
> On 4 June 2015 at 09:36, Jan Kratochvil wrote:
> > On Thu, 04 Jun 2015 09:24:36 +0200, Manuel López-Ibáñez wrote:
> >> On 3 June 2015 at 22:58, Jan Kratochvil wrote:
> > These two expressions are equivalent for all operations
On Thu, 04 Jun 2015 10:36:46 +0200, Manuel López-Ibáñez wrote:
> except for printing a memory
> region, and for that purpose one only needs to parse LHS@RHS and only
> one @ makes sense within the same print command.
Yes, just LHS or RHS can be pretty complicated containing the '@' character at
le
On 4 June 2015 at 09:36, Jan Kratochvil wrote:
> On Thu, 04 Jun 2015 09:24:36 +0200, Manuel López-Ibáñez wrote:
>> On 3 June 2015 at 22:58, Jan Kratochvil wrote:
> These two expressions are equivalent for all operations except of sizeof():
> pointer
> (*pointer@ANYTHING)
>
Sure,
On Thu, 04 Jun 2015 09:24:36 +0200, Manuel López-Ibáñez wrote:
> On 3 June 2015 at 22:58, Jan Kratochvil wrote:
>
> > In general parsing LHS vs. RHS is not so trivial:
> > *array1@10
> > expression wrapped into ->
> > (*array2+"a@c"[1]+'@'+'\''@(*array1@10)[5])[2]
> >
>
>
On 3 June 2015 at 22:58, Jan Kratochvil wrote:
> In general parsing LHS vs. RHS is not so trivial:
> *array1@10
> expression wrapped into ->
> (*array2+"a@c"[1]+'@'+'\''@(*array1@10)[5])[2]
>
Is this a real case? I cannot understand what this means, but it could
simply be
On Wed, 03 Jun 2015 16:55:24 +0200, Jeff Law wrote:
> On 05/30/2015 03:47 AM, Jan Kratochvil wrote:
> > > So I guess at some level it's not clear to me why we need to support the @
> > > operator in libcc1. So perhaps starting with a justification for
> > > wanting/needed that capability would be
Manuel> It should be possible to arrange the inferior code in
Manuel> such a way that GCC parses each side of @ independently and gives the
Manuel> info necessary to GDB such that it can interpret what @ means or give
Manuel> a reasonable error.
Only if this can be done without requiring gdb to le
On 03/06/15 18:30, Jeff Law wrote:
It's common to have something like the struct hack where the length of
the array is stored in the struct. Then when scripting gdb one can
write:
print s.array[0] @ s.length
Which is case that I've had use for a non-constant RHS as well. I just
haven't
On 06/03/2015 09:29 AM, Tom Tromey wrote:
I did not realize that myself before. I do not think there is an
easy fix for the GCC patch, is it?
It seems like a VLA would work.
Right. It doesn't seem like a big stretch to me either.
Jeff> 99% of the time I've used a constant with the @ synta
>> I did not realize that myself before. I do not think there is an
>> easy fix for the GCC patch, is it?
It seems like a VLA would work.
Jeff> 99% of the time I've used a constant with the @ syntax in gdb.
I use a non-constant argument to @ quite a bit.
It's common to have something like the
On 05/30/2015 03:47 AM, Jan Kratochvil wrote:
So I guess at some level it's not clear to me why we need to support the @
operator in libcc1. So perhaps starting with a justification for
wanting/needed that capability would be helpful.
It is not a simple /@[0-9]+$/ regex, the expression can be
On Sat, 30 May 2015 07:42:35 +0200, Jeff Law wrote:
> We're still digging out a
> bit from the patches queued while preparing for the gcc5 release.
gcc6
> So I guess at some level it's not clear to me why we need to support the @
> operator in
On 04/17/2015 09:17 AM, Jan Kratochvil wrote:
Hi,
ping:
[gcc patch] libcc1: '@' GDB array operator
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01451.html
Message-ID: <20150327163646.ga16...@host1.jankratochvil.net>
Jan
Sorry this has taken so long to get back to...
17 matches
Mail list logo
