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

[Mathieu Desnoyers]

----- 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 ?

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