* Problem with 32-bit negative return values
[not found] <452BD98F.8050602@us.ibm.com>
@ 2006-10-10 17:52 ` Frank Ch. Eigler
2006-10-10 18:28 ` Roland McGrath
2006-10-10 20:41 ` Mike Mason
0 siblings, 2 replies; 5+ messages in thread
From: Frank Ch. Eigler @ 2006-10-10 17:52 UTC (permalink / raw)
To: Mike Mason; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with 32-bit negative return values
2006-10-10 17:52 ` Problem with 32-bit negative return values Frank Ch. Eigler
@ 2006-10-10 18:28 ` Roland McGrath
2006-10-10 20:25 ` Frank Ch. Eigler
2006-10-10 20:41 ` Mike Mason
1 sibling, 1 reply; 5+ messages in thread
From: Roland McGrath @ 2006-10-10 18:28 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: Mike Mason, systemtap
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with 32-bit negative return values
2006-10-10 18:28 ` Roland McGrath
@ 2006-10-10 20:25 ` Frank Ch. Eigler
0 siblings, 0 replies; 5+ messages in thread
From: Frank Ch. Eigler @ 2006-10-10 20:25 UTC (permalink / raw)
To: Roland McGrath; +Cc: Mike Mason, systemtap
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem with 32-bit negative return values
2006-10-10 17:52 ` Problem with 32-bit negative return values Frank Ch. Eigler
2006-10-10 18:28 ` Roland McGrath
@ 2006-10-10 20:41 ` Mike Mason
1 sibling, 0 replies; 5+ messages in thread
From: Mike Mason @ 2006-10-10 20:41 UTC (permalink / raw)
To: Frank Ch. Eigler; +Cc: systemtap
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Problem with 32-bit negative return values
@ 2006-10-07 21:23 Mike Mason
0 siblings, 0 replies; 5+ messages in thread
From: Mike Mason @ 2006-10-07 21:23 UTC (permalink / raw)
To: SystemTAP
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-10-10 20:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <452BD98F.8050602@us.ibm.com>
2006-10-10 17:52 ` Problem with 32-bit negative return values Frank Ch. Eigler
2006-10-10 18:28 ` Roland McGrath
2006-10-10 20:25 ` Frank Ch. Eigler
2006-10-10 20:41 ` Mike Mason
2006-10-07 21:23 Mike Mason
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).