Problem with 32-bit negative return values

Problem with 32-bit negative return values

[Frank Ch. Eigler]

Hi -

On Tue, Oct 10, 2006 at 10:34:07AM -0700, Mike Mason wrote:
> [...]
> I'm trying to use the return value from sock_recvmsg() to determine how 
> many bytes are received.  It ignores negative return values (errors).
> [...]
> But on x86_64, the negative values are interpreted and printed as large 
> positive values:
> RECV 1440
> RECV 4294967285
> [...]

It could easily be a typing/sign-extension bug in the loc2c-related
code.  Could you check the generated C code (-p3; look for the
_dwarf_tvar_get function)?

- FChE

Re: Problem with 32-bit negative return values

[Roland McGrath]

> It could easily be a typing/sign-extension bug in the loc2c-related
> code.  Could you check the generated C code (-p3; look for the
> _dwarf_tvar_get function)?

All loc2c-generated fetches use unsigned types of the target object size,
i.e. uint32_t here.  loc2c just fetches the bits.
Your general expression code that uses the fetched value should cast
appropriately for the signedness and size you want to calculate with.

Re: Problem with 32-bit negative return values

[Frank Ch. Eigler]

Roland McGrath <roland@redhat.com> writes:

> All loc2c-generated fetches use unsigned types of the target object
> size, i.e. uint32_t here.  loc2c just fetches the bits.  Your
> general expression code that uses the fetched value should cast
> appropriately for the signedness and size you want to calculate
> with.

D'oh.  This bug probably affects every access to values of other than
native sizeof(long) bit size.  The loc2c c_translate_fetch/store
functions assign to a given value name (e.g.  THIS->__retvalue).
Instead it seems necessary to use a temporary value, fetch into that,
then emit the needed casting.

- FChE

Re: Problem with 32-bit negative return values

[Mike Mason]

Frank Ch. Eigler wrote:
> Hi -
> 
> On Tue, Oct 10, 2006 at 10:34:07AM -0700, Mike Mason wrote:
>> [...]
>> I'm trying to use the return value from sock_recvmsg() to determine how 
>> many bytes are received.  It ignores negative return values (errors).
>> [...]
>> But on x86_64, the negative values are interpreted and printed as large 
>> positive values:
>> RECV 1440
>> RECV 4294967285
>> [...]
> 
> It could easily be a typing/sign-extension bug in the loc2c-related
> code.  Could you check the generated C code (-p3; look for the
> _dwarf_tvar_get function)?

Here's the suspect code generated with -p3:

      l->__tmp18 =
      ({

        if (unlikely (c->nesting+2 >= MAXNESTING)) {
          c->last_error = "MAXNESTING exceeded";
          c->last_stmt = "identifier '$return' at nettop3.stp:56:15";
        } else if (likely (! c->last_error)) {
          c->nesting ++;
          function__dwarf_tvar_get_return_8 (c);
          c->nesting --;
          if (c->last_error && ! c->last_error[0])
            c->last_error = 0;
        }
        c->locals[c->nesting+1].function__dwarf_tvar_get_return_8.__retvalue;
      });
      if (likely (! c->last_error)) {
        l->__tmp19 = 0;
        _stp_printf ("RECV %lld\n", l->__tmp18);
      }


> 
> - FChE

Problem with 32-bit negative return values

[Mike Mason]

I'm trying to use the return value from sock_recvmsg() to determine how 
many bytes are received.  It ignores negative return values (errors).

probe kernel.function("sock_recvmsg").return
{
         p = pid()
         execname[p] = execname()
         user[p] = uid()
         sk_pid[p] ++
         sk_rx[p] <<< $return > 0 ? $return : 0

         printf("RECV %d\n", $return)
}

On x86, the negative values are correctly interpreted and printed:

RECV 1368
RECV -11
RECV 1368
RECV -11
RECV 1368
RECV -11
RECV 1368
RECV -11

But on x86_64, the negative values are interpreted and printed as large 
positive values:

RECV 1440
RECV 4294967285
RECV 1440
RECV 4294967285
RECV 1440
RECV 4294967285

This completely messes up the sk_rx aggregation.  It looks like 32-bit 
negative integers are not being correctly cast to 64-bit negative integers. 
  Is this a bug or am I doing something wrong?

- Mike