Re: How to implement '@' GDB-like operator for libcc1

[Manuel López-Ibáñez <lopezibanez at gmail dot com>]

On 16 March 2015 at 10:58, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> If it is really difficult to implement '@' in GCC then yes, that's the other
> way.  I expected to learn GCC parser on this IMO-simpler case so one can later
> implement for example the '{TYPE} ADDR' GDB extension, dropping C++ class
> protections, FILE::VARIABLE or FUNCTION::VARIABLE notations etc.  So there are
> more topics for the C/C++ parser but I tried this one first.

I cannot speak for the C/C++ FE maintainers, so I hope they will speak
up on this and give you much more useful advice than mine. But I have
seen this happen a lot of times before and it kills me it it were to
happen to GDB. The story goes like this: Someone wants to use GCC for
something it was not designed for. They go modifying GCC following
what they think is the most straightforward way to achieve exactly
what they need. They end up with a huge patch or a fork that is not
very useful for anyone else apart from them. The GCC devs say "sorry,
we think this is not the right way, we think you could try this or
that", which means basically starting from scratch and with a
different set of requirements. Thus, they are forced to maintain a
patch/fork for eternity, which cannot keep up with the rate of change
in GCC, thus it ends up only working for GCC last version- 1, -2, -3
until the authors just give up.

That said, you did the right thing asking here now. Please, if you
don't get the answers that you want, just don't give up: insist and
chase people before going on your own.

Now, from my own limited perspective of GDB but my better picture of
how GCC works, I think your chances of success will be much better if
you really limit what @ can do. The only use-case I see for @ is to
print memory regions. For that, one does not need to parse arbitrary
expression containing @, just arbitrary expressions to the left and to
the right of @. I would go as far as forbidding parentheses around the
@ expression. (Using GCC statement expressions, the left and right
sides of @ can contain almost anything).

>> I think there are more options: GDB could also convert @ to something
>> that GCC can understand, like a function call, or a cast to a
>> gdb-defined type, and that will trigger the generation of the desired
>> DWARF.
>
> I do not see how GDB could properly parse the expression with proper operator
> priorities/association.

But you are forcing GCC to parse something that is not C/C++. I see a
lot of potential to mess things up. It should be clear to GDB users
that @ is not C/C++, thus they should not expect to work as such. If
you want to embed @ in arbitrary C/C++ programs, you would need to
define what @ means in every point of a C/C++ program, including
promotions, precedence relations, etc. Down that path I see the abyss
gazing back into us.

>> > Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB will
>> > pass the boolean flag '__gdb_expr_take_address' to handle arrays correctly, one
>> > can see it for:
>>
>> Would it be possible for GDB to generate code such that this trick is
>> generated for @? Perhaps by creating a dummy array variable, then
>> applying typeof(dummy) like you do below.
>
> Sorry I do not get it.  GDB does not know how many elements the array should
> have without parsing the expression on its own - and only GCC can parse C/C++.

Given, lexp@rexp, you could pass both lexp and rexp to GCC for
evaluation and finding their types. This is all you need, no?

Yes, it is more limited than accepting @ within arbitrary C/C++
programs, do you really need that? What does *a@3 + 1 mean? or *a@3 *
b@4 ?

Cheers,

Manuel.