[lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Jérémie Galarneau]

On Sat, Oct 25, 2014 at 4:39 PM, Mathieu Desnoyers
<mathieu.desnoyers at efficios.com> wrote:
> ----- Original Message -----
>> From: "Jérémie Galarneau" <jeremie.galarneau at efficios.com>
>> To: "Philippe Proulx" <eeppeliteloop at gmail.com>
>> Cc: "Sebastien Boisvert" <boisvert at anl.gov>, lttng-dev at lists.lttng.org, "Mathieu Desnoyers"
>> <mathieu.desnoyers at efficios.com>
>> Sent: Saturday, October 25, 2014 3:24:38 PM
>> Subject: Re: [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)
>>
>> On Wed, Oct 22, 2014 at 7:07 PM, Philippe Proulx
>> <eeppeliteloop at gmail.com> wrote:
>> > On Wed, Oct 22, 2014 at 5:31 PM, Boisvert, Sebastien <boisvert at anl.gov>
>> > wrote:
>> >>> ________________________________________
>> >>> From: Philippe Proulx [eeppeliteloop at gmail.com]
>> >>> Sent: Wednesday, October 22, 2014 4:03 PM
>> >>> To: Boisvert, Sebastien
>> >>> Cc: lttng-dev at lists.lttng.org
>> >>> Subject: Re: [lttng-dev] Padding with Fs in babeltrace for a 32 bits
>> >>> field (ctf_integer_hex)
>> >>> On Wed, Oct 22, 2014 at 4:34 PM, Boisvert, Sebastien <boisvert at anl.gov>
>> >>> wrote:
>> >>> > I am using LTTng-UST (lttng 2.4.1-1.el6) and babeltrace (1.2.1-1.el6)
>> >>> > on CentOS 6.5 (using EPEL).
>> >>> >
>> >>> > I have 2 hexadecimal fields:
>> >>> >
>> >>> >       ctf_integer_hex(int, script, actor->script->identifier)
>> >>> >       ctf_integer_hex(int, action, message->action)
>> >>> >
>> >>> > One of them is printed with leading Fs (64 bits) while the other is
>> >>> > fine (32 bits), but both should be 32 bits wide.
>> >>> >
>> >>> > [14:52:27.416502837] (+0.000005124) silverclaw.novalocal
>> >>> > thorium_actor:receive_exit: { cpu_id = 6 }, { name = 1000452, script =
>> >>> > 0xFFFFFFFFEB3B39FD, action = 0x7724, count = 41 }
>> >>> >
>> >>> > I expect "script = 0xEB3B39FD" and not script = 0xFFFFFFFFEB3B39FD
>> >>> > since this is a int (sizeof(int) is 4).
>> >>> The issue is on the Babeltrace's ctf-text format side. When printing an
>> >>> integer with base 16 (ctf_integer_hex()):
>> >>> formats/ctf-text/types/integer.c:111:
>> >>>     case 16:
>> >>>     {
>> >>>         uint64_t v;
>> >>>         if (!integer_declaration->signedness)
>> >>>             v = integer_definition->value._unsigned;
>> >>>         else
>> >>>             v = (uint64_t) integer_definition->value._signed;
>> >>>         fprintf(pos->fp, "0x%" PRIX64, v);
>> >>>         break;
>> >>>     }
>> >>> When the integer is signed, it's casted to a 64-bit unsigned integer,
>> >>> hence the visible sign extension (all those Fs) in your case since the
>> >>> actual recorded value is -348440067 (if I'm still good at mental two's
>> >>> complement conversions ;-)).
>> >>> I believe this choice in Babeltrace is okay. It's always weird to
>> >>> represent a signed integer in hex base. How would you print it?
>> >>
>> >> The script identifier is found here:
>> >> [boisvert at bigmem biosal]$ grep 39fd genomics/* -R
>> >> genomics/assembly/unitig/unitig_visitor.h:#define SCRIPT_UNITIG_VISITOR
>> >> 0xeb3b39fd
>> >>
>> >> I would just print as it is: 0xeb3b39fd
>>
>> Makes sense to me. CC-ing Mathieu to see if there was a rationale
>> behind printing as 64-bit... Although it's probably just an oversight.
>
> Just an oversight. It does not make much difference when printing
> in base 10 with sign whether we print a 32 or 64-bit integer.
> Indeed, when printing as Hex, we should handle it more carefully.
> We should take into account every integer bit size in fact. What should
> we print if we print a signed 27-bit integer ?

I feel zero-extending to the next multiple of 4 bits (to fit hex
notation) would be the most intuitive behavior here.

Any comments?

Jérémie

>
> Thanks,
>
> Mathieu
>
>>
>> >>
>> >> $ cat foo.c
>> >>
>> >> #include <stdio.h>
>> >> #define SCRIPT_UNITIG_VISITOR 0xeb3b39fd
>> >>
>> >> int main(int argc, char **argv)
>> >> {
>> >>     int script;
>> >>     script = SCRIPT_UNITIG_VISITOR;
>> >>     printf("0x%x\n", script);
>> >>
>> >>     return 0;
>> >> }
>> >> $ gcc foo.c
>> >> $ ./a.out
>> >> 0xeb3b39fd
>> >
>> > Good point. So the integer's size should be checked instead of using PRI*
>> > conversion specifications systematically.
>> >
>> > I created a bug report for this: <http://bugs.lttng.org/issues/848>.
>>
>> Thanks for creating the bug report!
>>
>> Jérémie
>>
>> >
>> > Phil
>> >>
>> >>
>> >>> -0x14C4C603? I guess this would work too and could eventually be a
>> >>> format option passed to Babeltrace.
>> >>> Hope it helps, somehow,
>> >>> Phil
>> >>> >
>> >>> > Am I doing something wrong ?
>> >>> > _______________________________________________
>> >>> > lttng-dev mailing list
>> >>> > lttng-dev at lists.lttng.org
>> >>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> >
>> > _______________________________________________
>> > lttng-dev mailing list
>> > lttng-dev at lists.lttng.org
>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>
>>
>>
>> --
>> Jérémie Galarneau
>> EfficiOS Inc.
>> http://www.efficios.com
>>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com