This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: problems with minimal symbols (without a 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?

Of course. It's at the top of my list, and independent in my mind
of the discussion about forcing the cast. It was a convenient
work-around, however, allowing me to reduce the urgency to fix
this issue with casting.

That being said...

> Let me quote a conversation that happened on IRC just last week
> (user name anonymized):
[...]
>  <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 understand why GDB now behaves more naturally when using the casting
information to infer the symbol's type and how this is an improvement.
But wouldn't that part be orthogonal to the question whether GDB should
make this case mandatory or not?

This is probably a judgement call. And since I didn't comment on
the patch when it was proposed, I suppose it's fair that I try it
for Ada users as well, and see how they react. It'll keep the languages
consistent too, which is an advantage.

Just to answer some of your questions (therefore not in the spirit
of continuing a debate):

> 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?

Yes, this part is documented in the Ada section of the GDB manual.

> 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?

For me, this is because those minimal symbols are typically integral
types. So, for a non-trivial part of the times I use this feature,
it actually gives me the right answer. Therefore, for me, GDB lost
a small feature that didn't always work, but still did work for a good
chunk of the scenarios I was involved in.

I'll work on fixing the casting whenever I find some 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.

Thanks for the feedback,
-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]