On 01/07/2016 08:18 PM, Peter Maydell wrote:
On 22 December 2015 at 21:37, Franz-Josef Haider
<franz-josef.hai...@student.uibk.ac.at> wrote:
This is a sarge installation. Executing apt-get update triggers the crash
for me.
OK, I've now been able to try that on my hardware.
(1) If I use your chroot, and the qemu binary you provide in the
tarball, then apt-get update does crash. More simply, so does:
chroot . ./usr/bin/qemu-i386 /bin/cp
(This is helpful, because it means we can easily run it under gdb:
gdb --args chroot . ./usr/bin/qemu-i386 /bin/cp
)
(2) If I build my own QEMU binary, it doesn't crash on either cp
or apt-get; that works fine. My guess is that something about
your build setup (maybe the libc you're linking against, or the
compiler) is different from mine in a way that means this only
causes an actual crash for your builds and not mine.
Unfortunately the binary you've supplied seems to have been stripped,
so it has absolutely no debug or symbol information that we could
use to figure out what's going on (beyond that the PC is in the
.text segment so it's a crash in the C code rather than in the
generated code, which we suspected anyway from the debug log).
Could you produce a QEMU binary that isn't stripped and which
provokes the problem and send it to me, along with the info about
which QEMU git commit you built it from, please? (QEMU's makefiles
only run strip on install so it should be sufficient to fish out
the unstripped binary from the build tree; or you can pass
configure --disable-strip. 'file qemu-i386' will tell you if
it's stripped or not.)
thanks
-- PMM
This would be a unstripped version of the qemu-i386 binary:
https://www.dropbox.com/s/s9f8pcn5co34khn/qemu-i386?dl=0, although i
think it is not worth trying to pursue this any further, because i have
updated GCC in my build chroot (scratchbox) to version 4.7.2 and libc to
2.5.1 (which were available in some third party repositories for my
device) which still seems ancient but far better than what i had
previously. The crash is gone now.
But i had to apply the attached patch in order for it to compile.
Seems like -Wno-sign-compare has to be after -Wall and std::abs has no
"long long int" version on this compiler.
Thanks for your time and effort!
diff --git a/disas/libvixl/Makefile.objs b/disas/libvixl/Makefile.objs
index d1e801a..bbe7695 100644
--- a/disas/libvixl/Makefile.objs
+++ b/disas/libvixl/Makefile.objs
@@ -6,6 +6,6 @@ libvixl_OBJS = vixl/utils.o \
# The -Wno-sign-compare is needed only for gcc 4.6, which complains about
# some signed-unsigned equality comparisons which later gcc versions do not.
-$(addprefix $(obj)/,$(libvixl_OBJS)): QEMU_CFLAGS := -I$(SRC_PATH)/disas/libvixl -Wno-sign-compare $(QEMU_CFLAGS)
+$(addprefix $(obj)/,$(libvixl_OBJS)): QEMU_CFLAGS := -I$(SRC_PATH)/disas/libvixl $(QEMU_CFLAGS) -Wno-sign-compare
common-obj-$(CONFIG_ARM_A64_DIS) += $(libvixl_OBJS)
diff --git a/disas/libvixl/vixl/a64/disasm-a64.cc b/disas/libvixl/vixl/a64/disasm-a64.cc
index 20caba4..25d33aa 100644
--- a/disas/libvixl/vixl/a64/disasm-a64.cc
+++ b/disas/libvixl/vixl/a64/disasm-a64.cc
@@ -2684,12 +2684,11 @@ void Disassembler::AppendRegisterNameToOutput(const Instruction* instr,
}
}
-
void Disassembler::AppendPCRelativeOffsetToOutput(const Instruction* instr,
int64_t offset) {
USE(instr);
char sign = (offset < 0) ? '-' : '+';
- AppendToOutput("#%c0x%" PRIx64, sign, std::abs(offset));
+ AppendToOutput("#%c0x%" PRIx64, sign, llabs(offset));
}
