Re: [PATCH v2 2/4] Use field_string in more places

Tom Tromey
2019-07-09T15:21:23Z

>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:

>> + current_uiout->field_string ("event_status",
>> + hex_string_custom (event_status, 4));

Andrew> I don't know if it matters, but this will reduce the number of 0s that
Andrew> are printed, if 'event_status = 1' then phex (event_status, 4) will
Andrew> return '00000001' while hex_string_custom will return '0001'.

Andrew> I'm not an SPU user so have no opinion either way...

I don't know either. I looked into this a bit and it seems like a messy
area of gdb:

* hex_string and hex_string_custom take a signed argument, which IMO
doesn't make sense.

* hex_string is basically phex_nz with the 0x prefix; but
hex_string_custom differs in its truncation behavior from phex.

* core_addr_to_string and core_addr_to_string_nz exist; though some
spots choose to print a CORE_ADDR using one of the hex_string
functions; and of course there is paddress and (I just learned this
one) print_core_address.

* paddress probably should be renamed paddress_nz and print_core_address
to paddress, but of course this would be super confusing; and anyway
it seems like it would make more sense to standardize on a single way
to print addresses, or maybe at least a user- (rather than
patch-writer-) configurable one.

Faced with this I chose to flee, and I'm dropping the SPU bits from my
patch. Also I felt this made sense because the SPU code is slated to be
removed.

Tom