----- Original Message -----
> From: "Jérémie Galarneau" <[email protected]>
> To: "Philippe Proulx" <[email protected]>
> Cc: "Sebastien Boisvert" <[email protected]>, [email protected],
> "Mathieu Desnoyers"
> <[email protected]>
> 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
> <[email protected]> wrote:
> > On Wed, Oct 22, 2014 at 5:31 PM, Boisvert, Sebastien <[email protected]>
> > wrote:
> >>> ________________________________________
> >>> From: Philippe Proulx [[email protected]]
> >>> Sent: Wednesday, October 22, 2014 4:03 PM
> >>> To: Boisvert, Sebastien
> >>> Cc: [email protected]
> >>> 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 <[email protected]>
> >>> 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@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
> >>> > [email protected]
> >>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> >
> > _______________________________________________
> > lttng-dev mailing list
> > [email protected]
> > 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
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
