ping: [gcc patch] libcc1: '@' GDB array operator

[Jan Kratochvil]

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 helpful.
> > 
> > It is not a simple /@[0-9]+$/ regex, the expression can be for example
> > 	(*vararray@(3+1))
> > Parentheses still could be parsed by GDB, though.
> Is your assertion here that you want to be able to handle more complex
> operands on the LHS/RHS of the @ and that adding a general expression parser
> to GDB for that would be painful/wasteful?

Yes.


> > But a statement expression could not be parsed by GDB:
> > 	compile print ({ __auto_type ptr=vararray+1; *ptr@3; })
> But how important is this kind of usage?

Currently it is not because it does not work as I wrote.

Otherwise I think it could have some (marginal) use so that some custom
printing command can accept arbitrary expression and executing such ({...})
code with the given expression.

But nothing too important.


> > I have found now GDB can do also
> > 	*vararray@somevar
> Yea.  I've used this occasionally, but...
[...]
> Accepting the syntax where the RHS doesn't fold down to a constant is easy.

OK, I would extend the patch for non-constant RHS, in the case this patch
would be approved in general.


> 99% of the time I've used a constant with the @ syntax in gdb.  Doesn't this
> conflict with the goal of supporting an arbitrary C expression on the
> LHS/RHS of the @?  If most uses for the RHS are just constants, then why do
> we need the enhancement?

In general parsing LHS vs. RHS is not so trivial:
	*array1@10
	expression wrapped into ->
	(*array2+"a@c"[1]+'@'+'\''@(*array1@10)[5])[2]


> My worry is that without the copy_node we're changing things inside op0.
> ISTM that we should be generating a new node (ie, a new VAR_DECL) using the
> type returned by build_array_type_nelts as its type.

OK, thanks for the advice.  I would update the patch in the case this patch
would be approved in general.


On Wed, 03 Jun 2015 20:10:23 +0200, Manuel López-Ibáñez wrote:
> It should be possible to arrange the inferior code in such a way that GCC
> parses each side of @ independently

As I illustrate above I do not find it completely trivial and personally
I find more clean the patch to GCC than such a parsing in GDB.  In the end the
GCC patch is very short.

But sure everything is possible.  While for most of use cases it is probably
enough to just strrchr(expression,'@'), still compared to current c-exp.y
parsing it would mean for 'compile code' a regression for the remaining few
possible use cases.  So it means to parse strings, backslashes, parentheses.


> Parsing correctly arbitrary programs that may contain @ at arbitrary places
> seems a can full of gigantic were-worms.

Currently GCC parses '@' only for objc and I think it is OK for GCC/GDB to
make array@size syntax unsupported for objc.  So I do not see gigantic
were-worms anywhere myself.


Jan