From mboxrd@z Thu Jan 1 00:00:00 1970 From: eeppeliteloop@gmail.com (Philippe Proulx) Date: Sun, 26 Oct 2014 03:23:40 -0400 Subject: [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) In-Reply-To: <1590604559.2142.1414275301418.JavaMail.zimbra@efficios.com> References: <850061895.2069.1414269549796.JavaMail.zimbra@efficios.com> <1590604559.2142.1414275301418.JavaMail.zimbra@efficios.com> Message-ID: On Sat, Oct 25, 2014 at 6:15 PM, Mathieu Desnoyers wrote: > ----- Original Message ----- >> From: "J?r?mie Galarneau" >> To: "Mathieu Desnoyers" >> Cc: "Philippe Proulx" , "Sebastien Boisvert" , 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 >> 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? > > Yep, agreed. Agreed as well. The quick fix of using PRIx32 and PRIx64 at the right places (and their octal counterparts) would fix the vast majority of cases, at least regarding LTTng traces. Phil > > Thanks, > > Mathieu > >> >> 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 >> > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com