[lttng-dev] 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 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?
-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