This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange ARM issue: wrong exception table type?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]