Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Philippe Proulx]

On Wed, Oct 22, 2014 at 4:34 PM, Boisvert, Sebastien <boisvert@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?
-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@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Boisvert, Sebastien]

> ________________________________________
> From: Philippe Proulx [eeppeliteloop@gmail.com]
> Sent: Wednesday, October 22, 2014 4:03 PM
> To: Boisvert, Sebastien
> Cc: lttng-dev@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@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@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

$ 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


> -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@lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Philippe Proulx]

On Wed, Oct 22, 2014 at 5:31 PM, Boisvert, Sebastien <boisvert@anl.gov> wrote:
>> ________________________________________
>> From: Philippe Proulx [eeppeliteloop@gmail.com]
>> Sent: Wednesday, October 22, 2014 4:03 PM
>> To: Boisvert, Sebastien
>> Cc: lttng-dev@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@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@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
>
> $ 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>.

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@lists.lttng.org
>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Jérémie Galarneau]

On Wed, Oct 22, 2014 at 7:07 PM, Philippe Proulx
<eeppeliteloop@gmail.com> wrote:
> On Wed, Oct 22, 2014 at 5:31 PM, Boisvert, Sebastien <boisvert@anl.gov> wrote:
>>> ________________________________________
>>> From: Philippe Proulx [eeppeliteloop@gmail.com]
>>> Sent: Wednesday, October 22, 2014 4:03 PM
>>> To: Boisvert, Sebastien
>>> Cc: lttng-dev@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@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@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.

>>
>> $ 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@lists.lttng.org
>>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Mathieu Desnoyers]

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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Jérémie Galarneau]

On Sat, Oct 25, 2014 at 4:39 PM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> ----- Original Message -----
>> From: "Jérémie Galarneau" <jeremie.galarneau@efficios.com>
>> To: "Philippe Proulx" <eeppeliteloop@gmail.com>
>> Cc: "Sebastien Boisvert" <boisvert@anl.gov>, lttng-dev@lists.lttng.org, "Mathieu Desnoyers"
>> <mathieu.desnoyers@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@gmail.com> wrote:
>> > On Wed, Oct 22, 2014 at 5:31 PM, Boisvert, Sebastien <boisvert@anl.gov>
>> > wrote:
>> >>> ________________________________________
>> >>> From: Philippe Proulx [eeppeliteloop@gmail.com]
>> >>> Sent: Wednesday, October 22, 2014 4:03 PM
>> >>> To: Boisvert, Sebastien
>> >>> Cc: lttng-dev@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@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@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@lists.lttng.org
>> >>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> >
>> > _______________________________________________
>> > lttng-dev mailing list
>> > lttng-dev@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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Mathieu Desnoyers]

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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Philippe Proulx]

On Sat, Oct 25, 2014 at 6:15 PM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> ----- Original Message -----
>> From: "Jérémie Galarneau" <jeremie.galarneau@efficios.com>
>> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>> Cc: "Philippe Proulx" <eeppeliteloop@gmail.com>, "Sebastien Boisvert" <boisvert@anl.gov>, lttng-dev@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@efficios.com> wrote:
>> > ----- Original Message -----
>> >> From: "Jérémie Galarneau" <jeremie.galarneau@efficios.com>
>> >> To: "Philippe Proulx" <eeppeliteloop@gmail.com>
>> >> Cc: "Sebastien Boisvert" <boisvert@anl.gov>, lttng-dev@lists.lttng.org,
>> >> "Mathieu Desnoyers"
>> >> <mathieu.desnoyers@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@gmail.com> wrote:
>> >> > On Wed, Oct 22, 2014 at 5:31 PM, Boisvert, Sebastien <boisvert@anl.gov>
>> >> > wrote:
>> >> >>> ________________________________________
>> >> >>> From: Philippe Proulx [eeppeliteloop@gmail.com]
>> >> >>> Sent: Wednesday, October 22, 2014 4:03 PM
>> >> >>> To: Boisvert, Sebastien
>> >> >>> Cc: lttng-dev@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@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@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@lists.lttng.org
>> >> >>> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>> >> >
>> >> > _______________________________________________
>> >> > lttng-dev mailing list
>> >> > lttng-dev@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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Mathieu Desnoyers]

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

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Padding with Fs in babeltrace for a 32 bits field (ctf_integer_hex)

[Boisvert, Sebastien]

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).

Am I doing something wrong ?