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

[Joel Brobecker <brobecker at adacore dot com>]

> I'm not seeing this as independent -- if GDB assumes unknown
> types are integers, then we won't need to support casting from
> unknown types to anything else in the first place, it just
> falls out of supporting conversion from integer to anything else.

Right. I forgot about those variables having a TYPE_CODE_ERROR.

> I actually pasted that part just for completeness.  The point I was
> really trying to convey is in the unquoted part.  I.e, that this is
> really a FAQ, that frequently users show up on IRC confused
> by GDB showing incorrect results they can't explain.

Ah, that's because that was the part that I was less convinced about ;-).
I can accept that less experienced users might be confused indeed.

> Thanks!  Hopefully it'll be a simple change to ada_evaluate_subexp's
> UNOP_CAST handling, mirroring the evaluate_subexp_for_cast in
> eval.c.  Let me know if you run into something odd.

That's pretty much it. There is still an unknown inside the "resolve"
part, but I spent most of yesterday trying to see if I could reuse
the standard code more. Couldn't find a better way, but let's take
it one bird at a time...

> > That got me to one piece of code in evaluate_subexp_for_cast:
> > 
> >       /* Don't allow e.g. '&(int)var_with_no_debug_info'.  */
> >       if (VALUE_LVAL (val) == lval_memory)
> >         {
> >           if (value_lazy (val))
> >             value_fetch_lazy (val);
> >           VALUE_LVAL (val) = not_lval;
> >         }
> > 
> > I was wondering why do we not want to allow someone get its
> > address? I checked the commit that introduced this change,
> > and it doesn't say.
> 
> 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?

>  (top-gdb) p s
>  $1 = 0x1ec6d00 "long_integer (e) = long_integer (&const__aint_global_gdb_e)"
> 
> Curious, I didn't know that "&" worked in Ada too.

Yes. We found that we could extend the expression interpreter to accept
some of the same syntaxes that are familiar to a C developer. It's
very convenient, because it's quite short :). That was before my time,
but I think that's also why we chose the "{TYPE}" syntax for Ada as
well, to mimic what is done in C.

-- 
Joel