From mboxrd@z Thu Jan 1 00:00:00 1970 From: jeremie.galarneau@efficios.com (=?UTF-8?Q?J=C3=A9r=C3=A9mie_Galarneau?=) Date: Sat, 25 Oct 2014 17:09:10 -0400 Subject: [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) In-Reply-To: <850061895.2069.1414269549796.JavaMail.zimbra@efficios.com> References: <850061895.2069.1414269549796.JavaMail.zimbra@efficios.com> Message-ID: On Sat, Oct 25, 2014 at 4:39 PM, Mathieu Desnoyers wrote: > ----- Original Message ----- >> From: "J?r?mie Galarneau" >> To: "Philippe Proulx" >> Cc: "Sebastien Boisvert" , lttng-dev at lists.lttng.org, "Mathieu Desnoyers" >> >> 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 >> wrote: >> > On Wed, Oct 22, 2014 at 5:31 PM, Boisvert, Sebastien >> > wrote: >> >>> ________________________________________ >> >>> From: Philippe Proulx [eeppeliteloop@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 >> >>> 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 >> >> #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: . >> >> 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