On 24.11.2011, at 21:33, Alexander Graf wrote:
On 24.11.2011, at 20:49, Andrew Wafaa <awafaa@opensuse.org> wrote:
On Thu, 2011-11-24 at 19:45 +0100, Alexander Graf wrote:
I have good and bad news here :).
I managed to have a small reproducably failing test case. Every time I compile this small c++ program on a pandaboard it generates invalid unwind tables and the program fails executing.
However with the exact same compiler and system binaries executed on a different machine through qemu-arm, the program compiles properly!
So my guess is that gcc is using uninitialized memory somewhere. Unfortunately, valgrind is missing some thumb instructions which I have to report upstream now. But things are progressing...
Have you tried reproducing it on one of the Efikas?
For what purpose? It doesn't depend on the machine type.
What are the differences between our gcc and that of Linaro's, if that is indeed the cause?
The Linaro gcc behaves the same depending on the machine, so I'm fairly sure it's uninitialized memory.
Ok, so I debugged it down to gas which uses uninitialized memory in its unwind table generation: ==2009== Syscall param write(buf) points to uninitialised byte(s) ==2009== at 0x48EE56C: write (in /lib/libc-2.14.1.so) ==2009== by 0x48B51BB: _IO_file_write@@GLIBC_2.4 (fileops.c:1281) ==2009== by 0x48B510F: new_do_write (fileops.c:535) ==2009== by 0x48B5E1D: _IO_do_write@@GLIBC_2.4 (fileops.c:508) ==2009== by 0x48B6907: _IO_switch_to_get_mode (genops.c:189) ==2009== by 0x48B52D3: _IO_file_seekoff@@GLIBC_2.4 (fileops.c:991) ==2009== by 0x48AF0AB: _IO_seekoff_unlocked (ioseekoff.c:71) ==2009== by 0x48B4031: fseeko64 (fseeko64.c:42) ==2009== by 0x73A79: bfd_seek (bfdio.c:315) ==2009== by 0x5CB6F: _bfd_elf_write_object_contents (elf.c:5217) ==2009== by 0x4099F: bfd_close (opncls.c:701) ==2009== by 0x16E51: output_file_close (output-file.c:65) ==2009== Address 0x4d500d7 is not stack'd, malloc'd or (recently) free'd ==2009== Uninitialised value was created by a heap allocation ==2009== at 0x482F694: malloc (vg_replace_malloc.c:263) ==2009== by 0x7F353: xmalloc (xmalloc.c:147) ==2009== by 0x48BE1D7: _obstack_begin (obstack.c:186) ==2009== by 0x1C3E9: subseg_set_rest (subsegs.c:110) ==2009== by 0x1C50D: subseg_force_new (subsegs.c:195) ==2009== by 0x3B257: obj_elf_change_section (obj-elf.c:583) ==2009== by 0x25A47: start_unwind_section (tc-arm.c:19828) ==2009== by 0x3240D: create_unwind_entry (tc-arm.c:19857) ==2009== by 0x1B59D: read_a_source_file (read.c:919) ==2009== by 0xAEC1: main (as.c:1089) I sent a mail to the binutils ML and pushed a quick hacky fix (just always memset(0) xmalloc'ed memory) to openSUSE:Factory:ARM so we can actually build something. Let's hope this solves the exception and unwind mysteries! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org