This is the mail archive of the
mailing list for the binutils project.
Re: Strange ARM issue: wrong exception table type?
- From: Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>
- To: "david dot hagood at gmail dot com" <david dot hagood at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 2 Feb 2012 10:44:45 +0000
- Subject: Re: Strange ARM issue: wrong exception table type?
- References: <35a37ea957466b2f7a770e7978aebfef.squirrel@localhost>
On Wed, Feb 01, 2012 at 04:40:29PM +0000, email@example.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
> 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.
Principal Engineer, PD Software, ARM Ltd.