Mailinglist Archive: opensuse-arm (69 mails)

< Previous Next >
Re: [opensuse-arm] ARM status
On Fri, November 25, 2011 2:48 am, Alexander Graf wrote:

On 24.11.2011, at 21:33, Alexander Graf wrote:


On 24.11.2011, at 20:49, Andrew Wafaa <awafaa@xxxxxxxxxxxx> 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!

I see that gmp has been build without any errors. :)
Great job,



Alex

--
To unsubscribe, e-mail: opensuse-arm+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-arm+owner@xxxxxxxxxxxx


Regards,

Joop.

--
To unsubscribe, e-mail: opensuse-arm+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-arm+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation