Re: [PATCH V3] pickles: ctf: add new pickle ctf-dump.pk for dumping CTF section

[Jose E. Marchesi]

>>> I would like to point out that although the intent is that the output of
>>> these dump routines to look similar to that output by objdump --ctf=.ctf
>>> <objfile>, there are bound to be some stark differences. objdump can do a
>>> better job as it can look beyond the current type at hand and keep more
>>> state which allows it to print a more well-formed output.
>> Hmmm, I see you are passing a CTF_Dictionary to most of the ctf_dump_*
>> functions.  What prevents these functions to look beyond the current
>> type by accessing the dictionary?
>> Regardless of future improvements the pickle is good and useful
>> already,
>> so this patch is OK for master.
>> Thanks!
>> 
>
> Sorry I was loose in my words about what I wrote above. Nothing
> prevents the ctf-dump.pk pickle to look beyond the current type. And
> in fact, some of the dump_* functions need to and do access a CTF type
> lying before the type being dumped. They do access dict.types[XX] when
> necessary.
>
> What I thought (and what I meant to say) was that the pickle
> ctf-dump.pk needed some support of the likes of sprintf () to get its
> output close to that of objdump. This will help strings to be massaged
> / concatenated easily in the desired order. For example, for slices,
> the desirable output is to print the type first followed by the
> bitfield information like -
>
>     _Bool [slice 0x0:0x1]
>
> Where _Bool comes from the vlen bytes after the CTF type (slice). In
> ctf-dump.pk, the usual flow is to print the CTF Type followed by the 
> text related to vlen bytes.
>
> There could be more cases other than slices... In any case, I can try
> to improve the output in subsequent patches, atleast for the cases
> which clearly can do without sprintf () or such.

Yes, a `format' statement is on the works, that will allow composing
strings much like sprintf.

It is in the TODO, scheduled for 2.x :)

> For now, I will push this patch then!

Thanks!