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

[Indu Bhagat]

On 2/27/21 12:39 AM, Jose E. Marchesi wrote:
> Hi Indu!
>
> > 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.

For now, I will push this patch then!
Thanks