Description of problem: eu-strip fails on binaries linked by ld.gold, without any special options specified. Version-Release number of selected component (if applicable): 0.160 How reproducible: always Steps to Reproduce: 1. Create simple testcase: # echo ' int main(void) { return 12; }' > a.c 2. Compile and link it with gold: # gcc a.c -o a -fuse-ld=gold 3. Check that binary really works: # ./a # echo $? 12 4. Run eu-strip on it: # eu-strip -g -f a.debug a eu-strip: while writing 'a': cannot write data to file Actual results: The binary is not stripped with eu-strip. Expected results: The binary is stripped with eu-strip. Additional info: # gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7l-tizen-linux-gnueabi/4.9/lto-wrapper Target: armv7l-tizen-linux-gnueabi Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++ --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.9 --enable-ssp --disable-libssp --disable-bootstrap --disable-libvtv --disable-plugin --with-bugurl=http://bugs.tizen.org/ --with-pkgversion=Tizen --disable-libquadmath --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.9 --program-prefix=armv7l-tizen-linux-gnueabi- --target=armv7l-tizen-linux-gnueabi --disable-nls --with-sysroot=/usr/armv7l-tizen-linux-gnueabi --with-build-sysroot=/ --with-build-time-tools=/usr/arm-tizen-linux-gnueabi/bin --with-arch=armv7-a --with-tune=cortex-a8 --with-float=softfp --with-fpu=vfpv3 --with-mode=thumb --disable-sjlj-exceptions --build=i586-tizen-linux --host=i586-tizen-linux Thread model: posix gcc version 4.9.2 (Tizen) # ld.gold --version GNU gold (GNU Binutils; devel:arm_toolchain:Mobile:Tizen_Common / arm-wayland 2.24.90.20141014-24) 1.11 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. # eu-strip --version strip (elfutils) 0.160 Copyright (C) 2012 Red Hat, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Ulrich Drepper. The error was obtained during ld.gold enabling for Tizen:Common project. https://build.tizen.org/project/show?project=devel%3Aarm_toolchain%3AMobile%3ATizen_Common Fail detected on systemd bootctl binary, then reduced to the testcase shown above. [ 666s] + /usr/lib/rpm/find-debuginfo.sh /home/abuild/rpmbuild/BUILD/systemd-216 [ 666s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/systemd-216-9.2.aarch64/usr/bin/bootctl [ 666s] eu-strip: while writing '/home/abuild/rpmbuild/BUILDROOT/systemd-216-9.2.aarch64/usr/bin/bootctl': cannot write data to file [ 666s] error: Bad exit status from /var/tmp/rpm-tmp.1NRd9H (%install) [ 666s] eu-strip is used during final stage of RPM creation.
Please, when you try to reproduce the error, make sure that ld.gold (not ld.bfd) is used. If compiler fails to find ld.gold, it will run ld.bfd and eu-strip will not fail on the produced binary. So, the error happens only with gold-linked binaries, not with bfd-linked ones.
Could you please attach the 'a' binary from step 2. It should be testable on non-aarch64 if one has the aarch64 ELF file available. Thanks.
Created attachment 969057 [details] a.c from testcase described in bug report, compiled with GCC and linked with ld.gold for armv7l Attached a.c from testcase described in bug report, compiled with GCC and linked with ld.gold for armv7l.
Created attachment 969076 [details] a.c from testcase described in bug report, compiled with GCC and linked with ld.gold for aarch64 Attached a.c from testcase described in bug report, compiled with GCC and linked with ld.gold for aarch64
(In reply to Mark Wielaard from comment #2) > Could you please attach the 'a' binary from step 2. I've attached 2 binaries: compiled for arvm7l and for aarch64: - a.arvm7l - a.aarch64
Sorry. I've built elfutils outside Tizen buildroot and checked eu-strip on attached files. It works. So the problem is actually in our environment.
Thanks for letting us know. I hadn't had a chance to test myself yet. If you figure out what went wrong with the build inside the Tizen buildroot please do make a note here in case it is something that could happen to others. Maybe we can change something in the build setup so that the issue is more easily detected. Note that "cannot write data to file" is ELF_E_WRITE_ERROR which is only set when pwrite, fstat, ftruncate or fchmod fail.
(In reply to Mark Wielaard from comment #7) > Note that "cannot write data to file" is ELF_E_WRITE_ERROR which is only set > when pwrite, fstat, ftruncate or fchmod fail. I've tried to debug the testcase with GDB. Here is the block of code where the error is set to ELF_E_WRITE_ERROR: ssize_t n = pwrite_retry (elf->fildes, buf, dl->data.d.d_size, last_offset); if (unlikely ((size_t) n != dl->data.d.d_size)) { if (buf != dl->data.d.d_buf && buf != tmpbuf) free (buf); __libelf_seterrno (ELF_E_WRITE_ERROR); return 1; } The error happens in pwrite_retry, which calls pwrite64: static inline ssize_t __attribute__ ((unused)) pwrite_retry (int fd, const void *buf, size_t len, off_t off) { ssize_t recvd = 0; do { ssize_t ret = TEMP_FAILURE_RETRY (pwrite (fd, buf + recvd, len - recvd, off + recvd)); if (ret <= 0) return ret < 0 ? ret : recvd; recvd += ret; } while ((size_t) recvd < len); return recvd; }
Does pwrite_retry returns a negative value? If so what does errno say?
(In reply to Mark Wielaard from comment #9) > Does pwrite_retry returns a negative value? If so what does errno say? After erroneous call to pwrite, the errno is set to 14 (EFAULT), that means "bad address", according to "man errno". During this call pwrite_retry was called with the following arguments: (off=2288, len=0, buf=0x0, fd=5) Here is the full backtrace: #0 0x0000004000958cf4 in pwrite64 () from /home/ilya/obs/buildroots/systemd.aarch64/usr/lib64/libc-2.20.so #1 0x00000040008424ac in pwrite_retry (off=2288, len=0, buf=0x0, fd=5) at ../lib/system.h:79 #2 __elf64_updatefile (elf=elf@entry=0x4276b0, change_bo=change_bo@entry=0, shnum=shnum@entry=33) at elf32_updatefile.c:728 #3 0x000000400083eda4 in write_file (shnum=33, change_bo=0, size=7096, elf=0x4276b0) at elf_update.c:92 #4 elf_update (elf=0x4276b0, cmd=<optimized out>) at elf_update.c:192 #5 0x0000000000405478 in handle_elf () #6 0x0000000000406b60 in process_file () #7 0x0000000000402e58 in main () It means that pwrite was called with the same arguments (at least first time), and it was called only once. Moreover, we have found that on armv7l target machine eu-strip works correctly. In Tizen buildroot eu-strip is run under qemu-arm. So it seems to be a qemu bug. IMO qemu erroneously processes call with buf = 0. How do you think?
The error was in the fact that qemu implementation of syscall pwrite64 does not handle the case when the length of buffer is = 0. I've submitted a patch to qemu-devel that fixes this: http://lists.gnu.org/archive/html/qemu-devel/2014-12/msg02702.html See also official POSIX.1-2001. specification of pread64 and pwrite64 at http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html
Wow, good you dug deeper and produced that patch for qemu. Nice find. Thanks for sharing the result. All pread/[p]write calls in elfutils should normally go through the lib/system.h pread/[p]write_retry wrappers. Those all do the following: ssize_t recvd = 0; do { ssize_t ret = TEMP_FAILURE_RETRY (write (fd, buf + recvd, len - recvd)); if (ret <= 0) return ret < 0 ? ret : recvd; recvd += ret; } while ((size_t) recvd < len); return recvd; Flipping the "do-while" loop to a "while" loop should be a workaround for this issue because it would skip the system call when len == 0.
Hi, I am still able to reproduce the issue with elfutils master (e8b9832af19e5975fb2a9dbe729eaba0373c781f) and qemu 2.11.2
(In reply to Matwey V. Kornilov from comment #13) > I am still able to reproduce the issue with elfutils master > (e8b9832af19e5975fb2a9dbe729eaba0373c781f) and qemu 2.11.2 It looks like Ilya's patch from comment #11 was never applied to qemu.
There is now a similar fix to Ilya Palachev's patch upstream: commit 2bd3f8998e1e7dcd9afc29fab252fb9936f9e956 Author: Peter Maydell <peter.maydell> Date: Tue Jan 8 18:49:00 2019 +0000 linux-user: make pwrite64/pread64(fd, NULL, 0, offset) return 0 Linux returns success if pwrite64() or pread64() are called with a zero length NULL buffer, but QEMU was returning -TARGET_EFAULT. This is the same bug that we fixed in commit 58cfa6c2e6eb51b23cc9 for the write syscall, and long before that in 38d840e6790c29f59 for the read syscall. Fixes: https://bugs.launchpad.net/qemu/+bug/1810433 Signed-off-by: Peter Maydell <peter.maydell> Reviewed-by: Laurent Vivier <laurent> Reviewed-by: Philippe Mathieu-Daudé <philmd> Message-Id: <20190108184900.9654-1-peter.maydell> Signed-off-by: Laurent Vivier <laurent>
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
qemu-3.1.0-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0664c7724d
qemu-3.1.0-6.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-0664c7724d
qemu-3.1.0-6.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0664c7724d
qemu-3.1.0-6.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.