On 7 January 2013 22:43, Richard Weinberger <richard@nod.at> wrote:
Am Mon, 7 Jan 2013 17:55:29 -0800
schrieb Tristan Schmelcher <tschmelcher@google.com>:

> Hello,
>
> I am using UML as part of a hermetic build system and I have
> encountered an odd file corruption problem with the GNU Gold linker.
> When linking a binary inside a UML VM with Gold, if the output path
> is on a hostfs mount then all bytes in the output file produced by
> Gold are zero. However, the size of the output file is correct and
> the debugging output from running gold with --debug suggests that
> everything is working, so it seems like the content is being produced
> by Gold correctly but the file ends up containing all zeros instead.
> It has happened 100% of the time so far and it seems to be
> independent of the linker command line or input files.
>
> Are there any known issues where hostfs file content could end up as
> all zeros?

Is the file corrupted or does it *always* contain zeros?

It's always all zeros. Not "corruption" in the normal sense.
 
If yes, the write command seems to fail.

I'm wondering how gold writes a file.
Can you find out the system call sequence? (E.g using strace).

Certainly.

Outside UML: http://pastebin.com/rJRL4guJ
Inside UML writing to hostfs: http://pastebin.com/HyykiKfq

The output file that gets the all-zero content is out/Debug/libvpx_obj_int_extract. Looks like gold uses posix_fallocate but that isn't implemented on hostfs, and glibc falls back to forcing blocks to be allocated via pwrite. Then it mmap's the file, presumably writes the content to the mmap'ed region, and closes.

Hmm, maybe gold doesn't write anything to the mmap'ed region? Nope, it does: http://pastebin.com/nAzAibFv

Hmm, maybe the EOPNOTSUPP code path in glibc is broken? Nope, works outside UML even if EOPNOTSUPP is forced: http://pastebin.com/nS90fB6t

Perhaps there is a race in hostfs that causes the pwrite'ed pages to be written out after the mmap'ed data is written out?
 

Thanks,
//richard