Re: [RFC PATCH 0/3] Pretty-printing for errno

[Phil Muldoon <pmuldoon@redhat.com>]

On 22/06/17 23:44, Zack Weinberg wrote:
> I say 'attempts' because it only _almost_ works, but the remaining
> problems appear to be GDB bugs.  The most important of these is that
> if error_t is a typedef name for int,
> 
> (gdb) p (error_t) 1
> 
> will _not_ invoke the pretty-printer for error_t.  Bizarrely, the same
> pretty-printer _does_ get invoked when you print an _array_ of error_t
> quantities.

Zack,

I found some time to look at this and I wanted to make sure this is
(or is not) a GDB bug. I cooked up a really simple testcase:

typedef int test_i;

int main ()
{
  test_i i = 1;

  return 0;
}

ptype shows i as type int.
whatis shows i as type test_i.

(gdb) ptype i
type = int
(gdb) whatis i
type = test_i

Both are correct as ptype always unrolls types.

I looked at the pretty printer registration and lookup mechanics in
GDB and looked at the value and type coming into the lookup
function. I wanted to make sure the type is not being unrolled before
being searched through the printers. It is not. In printers.py in the
class RegexpCollectionPrettyPrinter and invoked through the __call__
function we see the typename as so (this is just output from a
temporary print statement):

('typename: ', 'test_i')

So the printer registered against a typedef type should get
called.  But similar to your experience, I get
this for a value cast on the command line:

(gdb) p (test_i) 1
$1 = ('typename: ', 'int')

Which again is odd. I thought it might have something to do with
temporary values (i.e. 1 exists for a moment, but is not in the
inferior). So I tried:

(gdb) p (test_i) i
$2 = ('typename: ', 'int')

Which is most puzzling.

In summary, typedefs are accounted for normal and non-casting
operations in pretty printing (i.e. print i). The typedef error_t
should trigger the error_t pretty printer as registered. The situation
for casting operations on the command line reverting to an unrolled
type is puzzling to me and hopefully somebody can explain why this is
so.

I'll hack on this for a little bit and
see if there are other things I can find.

Cheers

Phil