I happened to run across a problem with current gvfsd-sftp in x86_64 Fedora 18 that is apparently due to bad code generated by GCC.
The function
void g_vfs_read_channel_send_seek_offset (GVfsReadChannel *read_channel, goffset offset) { GVfsDaemonSocketProtocolReply reply; GVfsChannel *channel;
channel = G_VFS_CHANNEL (read_channel);
reply.type = g_htonl (G_VFS_DAEMON_SOCKET_PROTOCOL_REPLY_SEEK_POS); reply.seq_nr = g_htonl (g_vfs_channel_get_current_seq_nr (channel)); reply.arg1 = g_htonl (offset & 0xffffffff); reply.arg2 = g_htonl (offset >> 32);
g_vfs_channel_send_reply (channel, &reply, NULL, 0); }
in /usr/src/debug/gvfs-1.14.2/daemon/gvfsreadchannel.c shall split the signed 64 bit goffset offset into reply.arg1 and reply.arg2. What happens though is that reply.arg2 erroneously contains the same (byte-swapped, due to g_htonl) low-order 32 bits as reply.arg1. The generated code is
0x0000000000421c90 <+0>: push %rbp 0x0000000000421c91 <+1>: mov %rsi,%rbp 0x0000000000421c94 <+4>: push %rbx 0x0000000000421c95 <+5>: mov %rdi,%rbx 0x0000000000421c98 <+8>: sub $0x18,%rsp 0x0000000000421c9c <+12>: callq 0x415cf0 <g_vfs_channel_get_type> 0x0000000000421ca1 <+17>: mov %rbx,%rdi 0x0000000000421ca4 <+20>: mov %rax,%rsi 0x0000000000421ca7 <+23>: callq 0x4093b0 g_type_check_instance_cast@plt 0x0000000000421cac <+28>: mov %rax,%rdi 0x0000000000421caf <+31>: mov %rax,%rbx 0x0000000000421cb2 <+34>: movl $0x2000000,(%rsp) 0x0000000000421cb9 <+41>: callq 0x416ab0 <g_vfs_channel_get_current_seq_nr> 0x0000000000421cbe <+46>: mov %ebp,%esi 0x0000000000421cc0 <+48>: mov $0x20,%ecx 0x0000000000421cc5 <+53>: bswap %eax 0x0000000000421cc7 <+55>: sar %cl,%esi
^^^^^^^^^^^^^^
0x0000000000421cc9 <+57>: mov %eax,0x4(%rsp) 0x0000000000421ccd <+61>: mov %ebp,%eax 0x0000000000421ccf <+63>: bswap %esi 0x0000000000421cd1 <+65>: bswap %eax 0x0000000000421cd3 <+67>: mov %rbx,%rdi 0x0000000000421cd6 <+70>: mov %esi,0xc(%rsp) 0x0000000000421cda <+74>: xor %ecx,%ecx 0x0000000000421cdc <+76>: mov %rsp,%rsi 0x0000000000421cdf <+79>: xor %edx,%edx 0x0000000000421ce1 <+81>: mov %eax,0x8(%rsp) 0x0000000000421ce5 <+85>: callq 0x416210 <g_vfs_channel_send_reply> 0x0000000000421cea <+90>: add $0x18,%rsp 0x0000000000421cee <+94>: pop %rbx 0x0000000000421cef <+95>: pop %rbp 0x0000000000421cf0 <+96>: retq
where sar %cl,%esi with %ecx=$0x20 is a nop, as the "processor masks the upper three bits of the [%cl] count operand" [AMD64 Architecture Programmer’s Manual Volume 3: General Purpose and System Instructions].
Is this a known problem with (Fedora 18's) GCC?
Stephan
On 03/15/2013 04:23 PM, Stephan Bergmann wrote:
I happened to run across a problem with current gvfsd-sftp in x86_64 Fedora 18 that is apparently due to bad code generated by GCC.
The function
void g_vfs_read_channel_send_seek_offset (GVfsReadChannel *read_channel, goffset offset) { GVfsDaemonSocketProtocolReply reply; GVfsChannel *channel;
channel = G_VFS_CHANNEL (read_channel);
reply.type = g_htonl (G_VFS_DAEMON_SOCKET_PROTOCOL_REPLY_SEEK_POS); reply.seq_nr = g_htonl (g_vfs_channel_get_current_seq_nr (channel)); reply.arg1 = g_htonl (offset & 0xffffffff); reply.arg2 = g_htonl (offset >> 32);
g_vfs_channel_send_reply (channel, &reply, NULL, 0); }
in /usr/src/debug/gvfs-1.14.2/daemon/gvfsreadchannel.c shall split the signed 64 bit goffset offset into reply.arg1 and reply.arg2. What happens though is that reply.arg2 erroneously contains the same (byte-swapped, due to g_htonl) low-order 32 bits as reply.arg1. The generated code is
[...]
Is this a known problem with (Fedora 18's) GCC?
Grr, sorry for the noise; appears to be rather a bug in glib2-devel-2.34.2-2.fc18.x86_64, where /usr/include/glib-2.0/glib/gtypes.h
# define GUINT32_SWAP_LE_BE(val) ((guint32) __builtin_bswap32 ((gint32) val))
misses parentheses around "val", so the above
reply.arg2 = g_htonl (offset >> 32);
ultimately expands to
reply.arg2 = ((((guint32) __builtin_bswap32 ((gint32) offset >> 32))));
(and building gvfs with -Werror would have nicely given it away, "warning: right shift count >= width of type [enabled by default]").
Stephan
On 03/15/2013 05:06 PM, Stephan Bergmann wrote:
Grr, sorry for the noise; appears to be rather a bug in glib2-devel-2.34.2-2.fc18.x86_64
See https://bugzilla.gnome.org/show_bug.cgi?id=695925 "GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses."
Stephan
On Fri, Mar 15, 2013 at 10:24 AM, Stephan Bergmann sbergman@redhat.com wrote:
On 03/15/2013 05:06 PM, Stephan Bergmann wrote:
Grr, sorry for the noise; appears to be rather a bug in glib2-devel-2.34.2-2.fc18.x86_64
See https://bugzilla.gnome.org/show_bug.cgi?id=695925 "GUINT32/64_SWAP_LE_BE macros do not enclose val argument in parentheses."
Stephan
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yes this is a glib2 issue. glib2 changes in 19 caused a lot of packages to change behavior/code. After we rushed to fix compilation issues we are now noticing the code behaving differently than it used to across distros. It sucks but such is life.
Dan