Re: [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers

[Luis <luis.machado.foss@gmail.com>]

On 14/10/2025 01:56, Ezra Sitorus wrote:
> On Sat, Oct 11, 2025 at 02:10:11PM +0100, Luis wrote:
>> Hi Ezra,
>>
>> Given Pedro's input about the representation of fp8's, I'm not sure this is
>> the right path. Enabling these types for the registers would also make the
>> types visible to the rest of GDB. And users can operate on them via
>> arithmetic operators etc.
>>
>> Being integers, the ending result wouldn�t be correct.
>>
>> It might be viable to explore the python extension option to print the types
>> accordingly. We already make vector fields (neon or sve) available as 8, 16,
>> 32, 64 and 128 integers. Converting from that would therefore be easy.
>>
> 
> Fair! I think a python pretty printer is a good idea. However, would a pretty
> belong in the gdb project or the gcc project? The only examples in gdb are from
> testcases. The gdb docs references gdb.libstdcxx.v6, but this exists in gcc. In
> either scenario, I'm not too sure where the actual files would go to.
> 

Right, these pretty printers usually go with whoever is producing/using 
such types. So libraries/compilers etc.

With that said, we could also have a set of pretty-printers in gdb as 
well as reference implementation.

>> Also, I'm not too keen on expanding even further these neon/sve union types.
>> They are very hard to parse due to the multitude of representations. Ideally
>> we�d put together some pseudo-registers to do the job. That would also help
>> with remote debugging stub target description compatibility, as those
>> wouldn�t need to expose these internal details of gdb.
> 
> Your previous comment seems to suggest adding a pretty printer for the registers
> too but this one seems to suggest adding pseudo-registers instead. For pseudo-regs,

We should explore the python pretty-printers here. I don´t think we 
should add pseudo-registers in this case. But if we ever have a new 
representation, I think we should steer away from adding new union fields...


> would the approach be something like putting the new float formats in aarch64-tdep.c,
> and assigning the new pseudo regs' types to be the fp8 float formats?

... and then we´d have something like you describe above. Otherwise 
trying to print one of the vector registers produces a wall of text that 
is hard to parse.

> 
> Thanks!
> 
> Ezra