* [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) [not found] ` <850061895.2069.1414269549796.JavaMail.zimbra@efficios.com> @ 2014-10-25 21:09 ` Jérémie Galarneau 2014-10-25 22:15 ` Mathieu Desnoyers 0 siblings, 1 reply; 4+ messages in thread From: Jérémie Galarneau @ 2014-10-25 21:09 UTC (permalink / raw) 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@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@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? 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) 2014-10-25 21:09 ` [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) Jérémie Galarneau @ 2014-10-25 22:15 ` Mathieu Desnoyers 2014-10-26 7:23 ` Philippe Proulx 0 siblings, 1 reply; 4+ messages in thread From: Mathieu Desnoyers @ 2014-10-25 22:15 UTC (permalink / raw) ----- Original Message ----- > From: "J?r?mie Galarneau" <jeremie.galarneau@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@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@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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) 2014-10-25 22:15 ` Mathieu Desnoyers @ 2014-10-26 7:23 ` Philippe Proulx 2014-10-26 12:49 ` Mathieu Desnoyers 0 siblings, 1 reply; 4+ messages in thread From: Philippe Proulx @ 2014-10-26 7:23 UTC (permalink / raw) On Sat, Oct 25, 2014 at 6:15 PM, Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote: > ----- Original Message ----- >> From: "J?r?mie Galarneau" <jeremie.galarneau@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@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@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. 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 <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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) 2014-10-26 7:23 ` Philippe Proulx @ 2014-10-26 12:49 ` Mathieu Desnoyers 0 siblings, 0 replies; 4+ messages in thread From: Mathieu Desnoyers @ 2014-10-26 12:49 UTC (permalink / raw) ----- Original Message ----- > From: "Philippe Proulx" <eeppeliteloop@gmail.com> > To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com> > Cc: "J?r?mie Galarneau" <jeremie.galarneau at efficios.com>, "Sebastien Boisvert" <boisvert at anl.gov>, > lttng-dev at lists.lttng.org > Sent: Sunday, October 26, 2014 3:23:40 AM > Subject: Re: [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) > > On Sat, Oct 25, 2014 at 6:15 PM, Mathieu Desnoyers > <mathieu.desnoyers at efficios.com> wrote: > > ----- Original Message ----- > >> From: "J?r?mie Galarneau" <jeremie.galarneau@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@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@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. > > 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. If we fix it, we should do it thoroughly, because I doubt we'll revisit the issue later on. Thanks, Mathieu > > Phil > > > > 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 > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-26 12:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <E949C1E351B4914B87A26A5F96E06A9286B328@PAYTON.anl.gov>
[not found] ` <CAB4xu_3NMhkgL8AsVC7o65sVByYutuNoRu0WvzL+UKMOzsU7ag@mail.gmail.com>
[not found] ` <E949C1E351B4914B87A26A5F96E06A9286B387@PAYTON.anl.gov>
[not found] ` <CAB4xu_0L8eucgrr+hSxB_4NGmEfSsUeHfZLL0mjBys1Q_V9fcw@mail.gmail.com>
[not found] ` <CA+jJMxv1gzHRi3Zq7tX+ACGoEMfq0CfGMTYV0xOPkuHH=JWWwA@mail.gmail.com>
[not found] ` <850061895.2069.1414269549796.JavaMail.zimbra@efficios.com>
2014-10-25 21:09 ` [lttng-dev] Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex) Jérémie Galarneau
2014-10-25 22:15 ` Mathieu Desnoyers
2014-10-26 7:23 ` Philippe Proulx
2014-10-26 12:49 ` Mathieu Desnoyers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox