From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: "Jeff Law" <law@redhat.com>,
"Manuel López-Ibáñez" <lopezibanez@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Phil Muldoon <pmuldoon@redhat.com>,
Alexandre Oliva <aoliva@redhat.com>,
Tom Tromey <tom@tromey.com>
Subject: Re: ping: [gcc patch] libcc1: '@' GDB array operator
Date: Wed, 03 Jun 2015 21:08:00 -0000 [thread overview]
Message-ID: <20150603205742.GA5676@host1.jankratochvil.net> (raw)
In-Reply-To: <556F430F.7060807@gmail.com> <556F155C.1030300@redhat.com>
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
next prev parent reply other threads:[~2015-06-03 20:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 16:36 Jan Kratochvil
2015-04-17 15:17 ` ping: " Jan Kratochvil
2015-05-30 8:33 ` Jeff Law
2015-05-30 12:12 ` Jan Kratochvil
2015-05-31 19:52 ` [gcc patchv2] " Jan Kratochvil
2015-06-03 15:09 ` ping: [gcc patch] " Jeff Law
2015-06-03 15:34 ` Tom Tromey
2015-06-03 16:31 ` Jeff Law
2015-06-03 18:38 ` Manuel López-Ibáñez
2015-06-03 18:55 ` Tom Tromey
2015-06-03 21:08 ` Jan Kratochvil [this message]
2015-06-04 7:36 ` Manuel López-Ibáñez
2015-06-04 8:17 ` Jan Kratochvil
2015-06-04 8:42 ` Manuel López-Ibáñez
2015-06-04 8:56 ` Jan Kratochvil
2015-06-04 9:15 ` Jakub Jelinek
2015-06-04 13:36 ` Jan Kratochvil
2015-06-04 14:03 ` Jeff Law
2015-06-04 14:37 ` Jan Kratochvil
2015-06-04 14:43 ` Jeff Law
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=20150603205742.GA5676@host1.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=aoliva@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=law@redhat.com \
--cc=lopezibanez@gmail.com \
--cc=pmuldoon@redhat.com \
--cc=tom@tromey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).