Strange ARM issue: wrong exception table type?

Strange ARM issue: wrong exception table type?

[david.hagood]

I am having a strange issue with cross-compiling ARM programs. When I
build a C++ executable that throws exceptions, they don't work: no catch()
statements work, and all throw operations go straight to std::terminate().
My co-workers, who are using in theory the exact same tool chain, don't
see this (and I've checked the md5sum of their tools vs. mine and they
seem to match).

I've traced it down to the assembler: I can have them compile the C++ file
to a .s, and just assemble and link it, and it breaks. If they send me a
.o and I link that, it works. The assembler files they send me are the
same as the ones my compiler generates (verified via diff), but the
objects they produce vs. the objects I produce are different.

I've traced the point of difference to the .ARM.extab and .ARM.exidx
sections:

Contents of section .ARM.extab:
- 0000 00000080 84429b01 b0b0b083 ff002501  .....B........%.
+ 0000 00000000 84429b01 b0b0b083 ff002501  .....B........%.
  0010 1b1c9001 ac0101c0 01040000 dc013cac  ..............<.

Contents of section .ARM.exidx:
- 0000 00000080 00000080 7c010080 34000080  ........|...4...
- 0010 e0010080 40000080                    ....@...
+ 0000 00000000 00000000 7c010000 34000000  ........|...4...
+ 0010 e0010000 40000000                    ....@...

If I read the ARM EABI spec correctly, the difference is that my assembler
is generating the ARM Compact form (bit 31 set), and theirs are generating
the standard form. I assume that's preventing the run time library from
finding the catch() blocks.

What would cause my "as" to generate a different output than theirs for
the same input file? (and I've verified the MD5 of my "as" and theirs
match). And how can I fix this?

Re: Strange ARM issue: wrong exception table type?

[Matthew Gretton-Dann]

David,

On Wed, Feb 01, 2012 at 04:40:29PM +0000, david.hagood@gmail.com wrote:
> I am having a strange issue with cross-compiling ARM programs. When I
> build a C++ executable that throws exceptions, they don't work: no catch()
> statements work, and all throw operations go straight to std::terminate().
> My co-workers, who are using in theory the exact same tool chain, don't
> see this (and I've checked the md5sum of their tools vs. mine and they
> seem to match).

What toolchain are you using?  If it is not a current binutils can you try
with current HEAD?

> I've traced it down to the assembler: I can have them compile the C++ file
> to a .s, and just assemble and link it, and it breaks. If they send me a
> .o and I link that, it works. The assembler files they send me are the
> same as the ones my compiler generates (verified via diff), but the
> objects they produce vs. the objects I produce are different.
> 
> I've traced the point of difference to the .ARM.extab and .ARM.exidx
> sections:
> 
> Contents of section .ARM.extab:
> - 0000 00000080 84429b01 b0b0b083 ff002501  .....B........%.
> + 0000 00000000 84429b01 b0b0b083 ff002501  .....B........%.
>   0010 1b1c9001 ac0101c0 01040000 dc013cac  ..............<.
> 
> Contents of section .ARM.exidx:
> - 0000 00000080 00000080 7c010080 34000080  ........|...4...
> - 0010 e0010080 40000080                    ....@...
> + 0000 00000000 00000000 7c010000 34000000  ........|...4...
> + 0010 e0010000 40000000                    ....@...

If possible can you provide the assembler source and the output of readelf
-u on both object files?

> If I read the ARM EABI spec correctly, the difference is that my assembler
> is generating the ARM Compact form (bit 31 set), and theirs are generating
> the standard form. I assume that's preventing the run time library from
> finding the catch() blocks.
> 
> What would cause my "as" to generate a different output than theirs for
> the same input file? (and I've verified the MD5 of my "as" and theirs
> match). And how can I fix this?

Have you tried *exactly* the same as copied from one machine to another?

The symptoms you describe sound like a use of uninitialised memory bug.
However we need more information (as requested above) to be able to diagnose
the issue further.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.

Re: Strange ARM issue: wrong exception table type?

[david.hagood]

> David,
> What toolchain are you using?  If it is not a current binutils can you try
> with current HEAD?
I've tried both the CodeSourcery version and 2.2.0:

CodeSourcery versions:

arm-none-linux-gnueabi-objdump --version; arm-none-linux-gnueabi-g++
--version; arm-none-linux-gnueabi-as --version
GNU objdump (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Copyright 2008 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) any later
version.
This program has absolutely no warranty.
arm-none-linux-gnueabi-g++ (Sourcery G++ Lite 2009q3-67) 4.4.1
Copyright (C) 2009 Free Software Foundation, 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.

GNU assembler (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Copyright 2008 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 later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-linux-gnueabi'.

Mainline versions:
arm-linux-gnueabi-objdump --version; arm-linux-gnueabi-g++ --version;
arm-linux-gnueabi-as --version
GNU objdump (GNU Binutils) 2.20.1.20100303
Copyright 2009 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) any later
version.
This program has absolutely no warranty.
arm-linux-gnueabi-g++ (GCC) 4.6.1
Copyright (C) 2011 Free Software Foundation, 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.

GNU assembler (GNU Binutils) 2.20.1.20100303
Copyright 2009 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 later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-linux-gnueabi'.

> If possible can you provide the assembler source and the output of readelf
> -u on both object files?
Sure - how best should I do this, as an attached tgz?

> Have you tried *exactly* the same as copied from one machine to another?
If by that you mean "copy the toolchain" - yes, the toolchains are
identical (at least the CodeSourcery chains are - the newer chain is part
of an ongoing, but currently stalled, project to bring the tools more up
to date).

>
> The symptoms you describe sound like a use of uninitialised memory bug.
> However we need more information (as requested above) to be able to
> diagnose
> the issue further.
>
That may be (I assume you mean "uninitialized memory bug in the
assembler"), but it's odd that it is so consistently wrong on my machine
and so consistently right on my coworkers.

Re: Strange ARM issue: wrong exception table type?

[Matthew Gretton-Dann]

On Thu, Feb 02, 2012 at 03:31:15PM +0000, david.hagood@gmail.com wrote:
> > David,
> > What toolchain are you using?  If it is not a current binutils can you try
> > with current HEAD?
> I've tried both the CodeSourcery version and 2.2.0:
> 
> CodeSourcery versions:
> 
> arm-none-linux-gnueabi-objdump --version; arm-none-linux-gnueabi-g++
> --version; arm-none-linux-gnueabi-as --version
> GNU objdump (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
> Copyright 2008 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) any later
> version.
> This program has absolutely no warranty.
> arm-none-linux-gnueabi-g++ (Sourcery G++ Lite 2009q3-67) 4.4.1
> Copyright (C) 2009 Free Software Foundation, 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.
> 
> GNU assembler (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
> Copyright 2008 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 later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `arm-none-linux-gnueabi'.
> 
> Mainline versions:
> arm-linux-gnueabi-objdump --version; arm-linux-gnueabi-g++ --version;
> arm-linux-gnueabi-as --version
> GNU objdump (GNU Binutils) 2.20.1.20100303
> Copyright 2009 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) any later
> version.
> This program has absolutely no warranty.
> arm-linux-gnueabi-g++ (GCC) 4.6.1
> Copyright (C) 2011 Free Software Foundation, 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.
> 
> GNU assembler (GNU Binutils) 2.20.1.20100303
> Copyright 2009 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 later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `arm-linux-gnueabi'.
> 

Can you try latest trunk or binutils 2.22?

> > If possible can you provide the assembler source and the output of readelf
> > -u on both object files?
> Sure - how best should I do this, as an attached tgz?

If it is very large please open a bug in BugZilla to attach the files to and
track this issue better: http://sourceware.org/bugzilla/

> 
> > Have you tried *exactly* the same as copied from one machine to another?
> If by that you mean "copy the toolchain" - yes, the toolchains are
> identical (at least the CodeSourcery chains are - the newer chain is part
> of an ongoing, but currently stalled, project to bring the tools more up
> to date).

OK.

> 
> >
> > The symptoms you describe sound like a use of uninitialised memory bug.
> > However we need more information (as requested above) to be able to
> > diagnose
> > the issue further.
> >
> That may be (I assume you mean "uninitialized memory bug in the
> assembler"), but it's odd that it is so consistently wrong on my machine
> and so consistently right on my coworkers.

I agree that the behaviour is odd - its why I need a bit more info please.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.

Re: Strange ARM issue: wrong exception table type?

[david.hagood]

> David,
> If possible can you provide the assembler source and the output of readelf
> -u on both object files?
Send via direct mail so that I don't get yelled at for sending a tarball
to the list.

You've suggested trying the latest head - is there an already built
version you'd like me to try - because I've had a devil of a time building
the full toolchain from the head tarballs of GCC and binutils.

Re: Strange ARM issue: wrong exception table type?

[Matthew Gretton-Dann]

On Thu, Feb 02, 2012 at 04:27:58PM +0000, david.hagood@gmail.com wrote:
> > David,
> > If possible can you provide the assembler source and the output of readelf
> > -u on both object files?
> Send via direct mail so that I don't get yelled at for sending a tarball
> to the list.
> 
> You've suggested trying the latest head - is there an already built
> version you'd like me to try - because I've had a devil of a time building
> the full toolchain from the head tarballs of GCC and binutils.

OK.  I have seen your example from gcc-help@gcc.gnu.org.  Unfortunately, for
you, I see the behaviour your colleagues see.

Using tip of binutils-2_20-branch I get the following valgrind report:

==31548== Syscall param write(buf) points to uninitialised byte(s)
==31548==    at 0x511C500: __write_nocancel (syscall-template.S:82)
==31548==    by 0x50B7132: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1276)
==31548==    by 0x50B8784: _IO_do_write@@GLIBC_2.2.5 (fileops.c:530)
==31548==    by 0x50B8E36: _IO_switch_to_get_mode (genops.c:189)
==31548==    by 0x50B77A7: _IO_file_seekoff@@GLIBC_2.2.5 (fileops.c:986)
==31548==    by 0x50B0B29: fseeko (fseeko.c:40)
==31548==    by 0x4C1116: real_fseek (bfdio.c:61)
==31548==    by 0x4C1ED8: cache_bseek (cache.c:246)
==31548==    by 0x4C18B6: bfd_seek (bfdio.c:407)
==31548==    by 0x490D2B: _bfd_elf_write_object_contents (elf.c:4981)
==31548==    by 0x4557B8: bfd_close (opncls.c:692)
==31548==    by 0x4163E1: output_file_close (output-file.c:62)
==31548==  Address 0x40221df is not stack'd, malloc'd or (recently) free'd

On current trunk the valgrind report has gone.  This may or may not be
related to your problem (in my case the uninitialised bytes are in the
.rel.text section).

I think the next step is to try and reproduce this on current HEAD.

Follow the instructions at http://sourceware.org/binutils on how to checkout
binutils.

I then configure and make using something like the following sequence of
runes:

# Assuming you checked out doing:
# cvs co -z9 -d :pserver:anoncvs@sourceware.org:/cvs/src co binutils
$ mkdir build
$ cd build
$ ../binutils/configure \
  --target=arm-none-linux-gnueabi \
  --prefix=$HOME/install --with-sysroot=$HOME/sysroot \
  --disable-sid --disable-utils --disable-rda
$ make all-gas

The resultant gas will be build/gas/as-new which you can run from there
without having to do a make install-gas.

Can you try building gas and then seeing whether your problem has been
fixed please?

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.

Re: Strange ARM issue: wrong exception table type?

[david.hagood]

> Can you try building gas and then seeing whether your problem has been
> fixed please?

The good, the bad, and the ugly.
The good: the head build of gas works.
The bad: that means I'm going to have to move at least part way to the new
tool chain.
The ugly: why is this so damn repeatable on my system and nowhere else?

Still - I have identified the problem, I have identified the solution, I
can move on. Thanks for your help.

And at least this is captured on-line so if anybody else experiences this
weirdness, they won't be stuck in http://xkcd.com/979/

Thank you.

Re: Strange ARM issue: wrong exception table type?

[Guido Piasenza]

I also saw this problem, arm-gcc on my machine spits out code which can't catch
exceptions, whereas the very same compiler on a colleague's machine works 
perfectly.

I eventually found out that this is triggered by these environment variables on
my machine:

MALLOC_CHECK_=3
MALLOC_PERTURB_=69

without these variables I can compile nicely.

So I'd say there is a bug in arm-gcc which is just waiting to show up, and
MALLOC_PERTURB_ makes it come out from the shadows. Other conditions might
trigger the same problem, but for the time being I unset these variables and
hope for the best.

Guido