Re: RFC: problems with minimal symbols (without a type)

[Pedro Alves <palves@redhat.com>]

On 11/15/2017 06:52 PM, Joel Brobecker wrote:

>> This is to follow usual language rules.  A cast expression isn't
>> an lvalue, so you can't take its address:
> 
> Ah, ok.
> 
> My philosophy is been that it's OK, and sometimes good, to allow
> in the debugger something that's not allowed in the language, if
> it makes it easier for the user to do his debugging. Would allowing
> this as an extension be introducing possible confusion?

Sorry, somehow I missed this question.  I agree that sometimes
extensions are OK, but IMO, they need to have some clear advantage.
Since there's a just-as-easy way to do the same thing within the
language, IMO, we shouldn't add such an extension.  I think that yes,
it can introduce confusion, and I could see someone reporting a bug
if they notice "&(int)global" works.

Extending the language always has risk of conflicting with future
revisions of the language, or running into cases that we can't make
work, kind of painting ourselves into an odd corner.  For example, 
consider the case of the "compile" command, when we pass the 
expression to a real compiler to parse.  Ideally we'll teach the
gcc C/C++ frontends about all our syntax extensions somehow (e.g, behind
some special "#pragma GCC gdb_extensions" or something in the code we
hand over to the compiler), so that "compile print" can become a strict
superset of "print".  IMO we'd even ditch our internal
C/C++ parser and always go via the compiler (though we're still far
from being able to do that).  This extension sounds like the kind that
would run into implementation difficulties and maybe
"language-lawer-ish"-resistance in GCC.

In this case, taking the address of an rvalue expression never worked,
even with debug info for the symbol at hand, so IMO adding such
a feature would/should be considered as an orthogonal enhancement.

Thanks,
Pedro Alves