[lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Sat Oct 25 18:15:01 EDT 2014
----- Original Message -----
> From: "Jérémie Galarneau" <jeremie.galarneau at efficios.com>
> To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> Cc: "Philippe Proulx" <eeppeliteloop at gmail.com>, "Sebastien Boisvert" <boisvert at anl.gov>, lttng-dev at lists.lttng.org
> Sent: Saturday, October 25, 2014 5:09:10 PM
> Subject: Re: [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)
>
> 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?
Yep, agreed.
Thanks,
Mathieu
>
> 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
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list