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

[Pedro Alves <palves at redhat dot com>]

Hi Joel,

On 11/09/2017 01:25 AM, Joel Brobecker wrote:

> You recently made a change to require that minimal symbols be cast
> in order to be printed. This is causing some unexpected side-effects
> in Ada. The most visible is with exception catchpoints.
> 
> Consider any Ada program, trying to insert a catchpoint on a specific
> exception now fails:
> 
>     $ (gdb) catch exception constraint_error
>     warning: failed to reevaluate internal exception condition for catchpoint 0: 'constraint_error' has unknown type; cast it to its declared type
> 
> I suspect people using the version of GNAT produced by distribution
> makes such as RedHat probably cannot reproduce the issue, as I understand
> the compiler is built with a runtime with full debugging information,
> whereas the version AdaCore distributes only provides debugging info
> for the few units where we need it.
> 
> Another way to show the same issue is to just print constraint_error:
> 
>     (gdb) p constraint_error
>     'constraint_error' has unknown type; cast it to its declared type
> 
> And unfortunately, the Ada equivalent of casting does not work either:
> 
>     (gdb) print integer(constraint_error)
>     'constraint_error' has unknown type; cast it to its declared type

Shouldn't we just make that work, like it works for C?

> 
> But even if casting were working, should we really also require
> a case in a situation like this?

I'm not exactly sure which situation you're referring to here.

For "catch exception constraint_error", or in general?

For "catch exception", what is the expression that GDB is
trying to evaluate?

> 
>     (gdb) p constraint_error'address
>     $2 = (system.address) 0x62c960 <constraint_error>
> 
> Unlike C, 'address returns an object of type system.address,
> which is the equivalent of "void *" in C. For minimal symbols
> other that integers, the way people typically dump them is by
> doing something like that:
> 
>     (gdb) print {my_type} minsym'address
> 

The problem here is even knowing that you have to do that,
if GDB just prints it as an int.  For some symbols, it's
somewhat obvious GDB is printing something odd, but for others
not so much.

> I looked at the patch series that introduced that change, and
> I see where you are coming from, but I am wondering if we should
> be doing the same for Ada or not.

IMHO, we should.

Let me quote a conversation that happened on IRC just last week
(user name anonymized):

 <user>		Does anybody know what's going on: I do 1) `p malloc(128)` (now it's stored at $1), 2) `x/1x $1`. The last command results in error "0xfffffffff7f921a0:     Cannot access memory at address 0xfffffffff7f921a0"
 <user>		Why can't I access the memory I just malloc'ed?
 <palves>	what does ptype malloc say?
 <user>		type = int ()
 <palves>	ok, you don't have debug info for malloc, and so gdb assumes that it return int.
 <user>		Aaah
 <user>		Thank you!
 <user>		Ok, I'll just type-cast it, thank you very much!
 <user>		That said, I still don't understand. Even if gdb thinks that malloc returned int — but the "x" command accepts address. So it should just cast the argument to address, shouldn't it?
 <user>		And indeed, using `x/1x (void*)$1` results in the same error.
 <palves>	malloc probably returned a 64-bit address, while int is 32-bit.  so the upper 0xffffffff in "0xfffffffff7f921a0" are probably a bogus sign extension.
 <user>		Ah
 <user>		I see, thank you
 <palves>	you have to cast malloc to the right function pointer type, and then call that.
 <palves>	something like: p ((void * (*) (size_t )) malloc) (128)
 <palves>	in master, the simpler 'p (void*)malloc (128)' does the right thing.
 <palves>	(it infers the prototype from the type of the passed in arguments + the cast-to type)

> I think Ada users are a lot
> less used to casting (case in point, it took quite a while, even
> for myself, to remember what the syntax was), and I fear this is
> not going to be well received by the users.

You won't know without trying, of course.  :-)  

At least an Ada conversion/cast is Ada syntax.
The "print {my_type} minsym'address" syntax above looks like
the GDB syntax/extension that works with C too?
How do users discover that that gdb syntax extension is available
and that they need to use it?
For non-integer types, users must already do some casting to get at
the real data.  Why treat integers differently?

IMO, this could be tackled as well by better documentation.

Or even by improving the error message.  E.g., we could give a suggestion
of what the cast syntax looks like for the current language.

     (gdb) p constraint_error
     'constraint_error' has unknown type; cast it to its declared type:
          declared_type (symbol)

GDB knows the name of the variable/symbol that is missing type info,
so we could even include it in the suggestion:

     'constraint_error' has unknown type; cast it to its declared type:
          declared_type (constraint_error)

Or we could suggest the {} syntax, if you'd prefer.

Ultimately it's your call, but my vote would be to fix the casting
instead of going back to assuming integer, often incorrectly.

> What do you think? Attached is a prototype patch which implements
> the original behavior for Ada expressions. It fixes the failures
> in exception catchpoints without introducing any regresssion
> (x86_64-linux).

Thanks,
Pedro Alves