Bug 12771 - internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on armel
Summary: internal error in value_from_output_section, at ../../gold/reloc.cc:1508 on a...
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: Ian Lance Taylor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-17 09:36 UTC by Jonathan Nieder
Modified: 2011-10-31 04:39 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
testcase (14.89 KB, application/x-xz)
2011-05-17 09:36 UTC, Jonathan Nieder
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Nieder 2011-05-17 09:36:45 UTC
Created attachment 5730 [details]
testcase

Hi,

Timo Lindfors found that running "ld.gold allcodecs.o" with this object file on his sheevaplug produces

ld.gold: internal error in value_from_output_section, at ../../gold/reloc.cc:1508

and an exit status of 1.  It's reproducible with real hardware but not with qemu (on qemu one instead gets the expected bunch of "error: undefined reference" errors for objects not passed on the command line).  Tests so far have been with 2.21.51.20110421-4 from Debian sid but presumably it shouldn't be hard to check with the latest from git://sources.redhat.com/git/binutils.git if that's useful.

http://bugs.debian.org/616715 has details. Any hints for tracking this down?

Thanks for gold :)
Jonathan
Comment 1 Jonathan Nieder 2011-06-04 00:50:11 UTC
Logs from other ARM machines exhibiting the same problem can be found at <https://buildd.debian.org/status/package.php?p=chromium-browser>. E.g., alwyn and alain produce the same internal error.  Example log:

 https://buildd.debian.org/status/fetch.php?pkg=chromium-browser&arch=armel&ver=11.0.696.71~r86024-1&stamp=1306431361

Information about alwyn is at <http://db.debian.org/machines.cgi?host=alwyn>; I guess the relevant detail would be its processor (Marvell Feroceon CPU @ 1GHz on a Marvell DB-78x00-BP Development Board (ARM v5)).

If I had access to a physical ARM to try on, I'd be glad to investigate further.
Comment 2 Timo Juhani Lindfors 2011-06-06 12:37:33 UTC
Well hmm, I could try to arrange you access to some ARM box. Can you attach your SSH public key?
Comment 3 Jonathan Nieder 2011-06-17 07:43:57 UTC
timo.lindfors at iki dot fi wrote:

> Well hmm, I could try to arrange you access to some ARM box. Can you attach
> your SSH public key?

I replied by private email but now it occurs to me that maybe it would
be useful to make it public (in case another hero with an ARM wants to
provide ssh access).  So here it is again, for reference (sorry for
the noise).

 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC2CPcCDuUxAkYrpHDbwZXqBbCCSAPSR08WkBbiXAiw9/1+Cgqej7pHdsknVzZmrasOxyUzBpaXrJJ+/3Bgl8uQDfA570CZah7LKxMQ8sDaKyAfJzrz20egGIz8fdLzoFfgOsX+3HPj7ugujzsMxUr+CPxi6Hly3MeOQUL4Tc7UhIaoX7ircqhUC9PuCzZKMtGPx66AgOFRMILUvnVlF8NvPBn35Ml0Ct/fhNuSH9jAwnzLC9drkzbxeENmszDdG6pe6FGG8rf3AVt5RdtsmrKhzPXGTvEWpVmN3X3a1OZmNuHIE+LsXf4k2fcha31i81Uk7WyQKGR+Nu/xYvVfiaun jrn@elie
Comment 4 Ian Lance Taylor 2011-06-17 15:07:45 UTC
It sounds like you are saying that gold, compiled and running on an ARM system, crashes, whereas gold, compiled and running on an ARM simulator, does not crash.

In general gold should do the same thing whether it is run natively or run as a cross-linker.  I tried this test case as a cross-linker, and I get a bunch of "undefined reference" errors but no crash.  I checked a linker built in both 32-bit and 64-bit mode.

While this clearly needs further investigation by somebody who can recreate the problem, it seems moderately unlikely to be a bug in gold.
Comment 5 Jonathan Nieder 2011-06-17 21:10:19 UTC
Hi Ian,

ian at airs dot com wrote:

> It sounds like you are saying that gold, compiled and running on an ARM system,
> crashes, whereas gold, compiled and running on an ARM simulator, does not
> crash.

For completeness, I should mention that gold, compiled on an ARM
system and running on an ARM simulator, also does not crash.
Comment 6 Ian Lance Taylor 2011-06-29 15:01:33 UTC
This seems far more likely to be a problem in the tools used to build gold, rather than a problem in gold itself.  I'm going to close this out.  Please reopen if you have some reason to believe that there is a problem in gold itself.
Comment 7 Jonathan Nieder 2011-06-29 15:35:40 UTC
(In reply to comment #6)
> This seems far more likely to be a problem in the tools used to build gold,
> rather than a problem in gold itself.  I'm going to close this out.  Please
> reopen if you have some reason to believe that there is a problem in gold
> itself.

Just for completeness: did you test on a non-emulated ARM system?

The triggered failed assertion says

  bool found = object->merge_map()->get_output_offset(NULL, input_shndx,
                                                      input_offset,
                                                      &output_offset);

  // If this assertion fails, it means that some relocation was
  // against a portion of an input merge section which we didn't map
  // to the output file and we didn't explicitly discard.  We should
  // always map all portions of input merge sections.
  gold_assert(found);

That doesn't immediately scream "code generation bug" to me --- it could be a use of uninitialized memory or some other portability problem.  If I wanted to pin it on something other than gold this early, I'd be more likely to blame libstdc++ than the code generation, but it's hard to learn anything without hardware to investigate on.
Comment 8 Ian Lance Taylor 2011-06-30 06:00:32 UTC
OK, I looked at this a bit more.  It's possible that this is being caused by an unaligned access.  I see that on ARM an unaligned access will load rotated bytes.  Does this happen on the emulator?

This object file has unaligned R_ARM_ABS32 relocations against the .debug_info section.  When the linker fetches the addend for those relocations, it will do an unaligned read.

Try changing the function Arm_relocate_functions::abs32 around line 3284 of arm.cc to this:

  // R_ARM_ABS32: (S + A) | T
  static inline typename This::Status
  abs32(unsigned char* view,
	const Sized_relobj_file<32, big_endian>* object,
	const Symbol_value<32>* psymval,
	Arm_address thumb_bit)
  {
    typedef typename elfcpp::Swap<32, big_endian>::Valtype Valtype;
    Valtype addend = elfcpp::Swap_unaligned<32, big_endian>::readval(view);
    Valtype x = psymval->value(object, addend) | thumb_bit;
    elfcpp::Swap_unaligned<32, big_endian>::writeval(view, x);
    return This::STATUS_OKAY;
  }

If that change fixes the crash, then it is indeed an unaligned access problem.

The ARM ELF ABI does suggest that there is no required alignment for relocations, so it does seem that much of the code in Arm_relocation_functions needs to use Swap_unaligned rather than Swap.
Comment 9 Doug Kwan 2011-06-30 06:51:00 UTC
Thanks for fix that.  I will submit a patch later to convert to
unaligned swaps as needed.

-Doug

On Wed, Jun 29, 2011 at 11:01 PM, ian at airs dot com
<sourceware-bugzilla@sourceware.org> wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12771
>
> Ian Lance Taylor <ian at airs dot com> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|RESOLVED                    |REOPENED
>                 CC|                            |dougkwan at google dot com,
>                   |                            |ian at airs dot com
>         Resolution|WORKSFORME                  |
>
> --- Comment #8 from Ian Lance Taylor <ian at airs dot com> 2011-06-30 06:00:32 UTC ---
> OK, I looked at this a bit more.  It's possible that this is being caused by an
> unaligned access.  I see that on ARM an unaligned access will load rotated
> bytes.  Does this happen on the emulator?
>
> This object file has unaligned R_ARM_ABS32 relocations against the .debug_info
> section.  When the linker fetches the addend for those relocations, it will do
> an unaligned read.
>
> Try changing the function Arm_relocate_functions::abs32 around line 3284 of
> arm.cc to this:
>
>  // R_ARM_ABS32: (S + A) | T
>  static inline typename This::Status
>  abs32(unsigned char* view,
>    const Sized_relobj_file<32, big_endian>* object,
>    const Symbol_value<32>* psymval,
>    Arm_address thumb_bit)
>  {
>    typedef typename elfcpp::Swap<32, big_endian>::Valtype Valtype;
>    Valtype addend = elfcpp::Swap_unaligned<32, big_endian>::readval(view);
>    Valtype x = psymval->value(object, addend) | thumb_bit;
>    elfcpp::Swap_unaligned<32, big_endian>::writeval(view, x);
>    return This::STATUS_OKAY;
>  }
>
> If that change fixes the crash, then it is indeed an unaligned access problem.
>
> The ARM ELF ABI does suggest that there is no required alignment for
> relocations, so it does seem that much of the code in Arm_relocation_functions
> needs to use Swap_unaligned rather than Swap.
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 10 HectorOron 2011-07-01 00:01:13 UTC
Hello,

  I also got bitten by this problem.

$ echo "int main () { ; return 0; }" > test.c
$ gcc -fno-strict-aliasing -g -g -O2   test.c
/usr/bin/ld: internal error in value_from_output_section, at ../../gold/reloc.cc:1519
collect2: ld returned 1 exit status

$ ld.gold -v
GNU gold (GNU Binutils for Debian 2.21.52.20110606) 1.11

If using ld.bfd instead of gold, it works

(In reply to comment #8)
> Try changing the function Arm_relocate_functions::abs32 around line 3284 of
> arm.cc to this:

Anyway, I went ahead and applied Ian suggestion:
~/binutils-2.21.52.20110606$ diff -Naur gold/arm.cc.orig gold/arm.cc
--- gold/arm.cc.orig    2011-06-30 16:51:57.000000000 +0000
+++ gold/arm.cc 2011-06-30 16:54:49.000000000 +0000
@@ -3297,10 +3297,9 @@
        Arm_address thumb_bit)
   {
     typedef typename elfcpp::Swap<32, big_endian>::Valtype Valtype;
-    Valtype* wv = reinterpret_cast<Valtype*>(view);
-    Valtype addend = elfcpp::Swap<32, big_endian>::readval(wv);
+    Valtype addend = elfcpp::Swap_unaligned<32, big_endian>::readval(view);
     Valtype x = psymval->value(object, addend) | thumb_bit;
-    elfcpp::Swap<32, big_endian>::writeval(wv, x);
+    elfcpp::Swap_unaligned<32, big_endian>::writeval(view, x);
     return This::STATUS_OKAY;
   }
 
Which produces a successful linkage:
$ gcc -B sandbox/usr/bin/ -Wl,-debug -fno-strict-aliasing -g -g -O2   test.c
Convert string 'sandbox/usr/bin/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/' into prefixes, separator = ':'
  - add prefix: sandbox/usr/bin/
  - add prefix: /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/
  - add prefix: /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/
  - add prefix: /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/
  - add prefix: /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/
  - add prefix: /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/
Convert string '/home/zumbi/bin:/home/zumbi/bin:/usr/local/bin:/usr/bin:/bin:/usr/games' into prefixes, separator = ':'
  - add prefix: /home/zumbi/bin/
  - add prefix: /home/zumbi/bin/
  - add prefix: /usr/local/bin/
  - add prefix: /usr/bin/
  - add prefix: /bin/
  - add prefix: /usr/games/
Looking for 'real-ld'
Looking for 'collect-ld'
Looking for 'ld'   
Looking for 'gnm'  
Looking for 'gnm'  
Looking for 'nm'   
Looking for 'gstrip'
Looking for 'gstrip'
Looking for 'strip'
Looking for 'gcc'  
Looking for 'gcc'  
collect2 version 4.6.1 (ARM GNU/Linux with ELF)
ld_file_name        = sandbox/usr/bin/ld
c_file_name         = /usr/bin/gcc
nm_file_name        = sandbox/usr/bin/nm
strip_file_name     = sandbox/usr/bin/strip
c_file              = /tmp/ccQzTD6a.c
o_file              = /tmp/ccYHgcZb.o
COLLECT_GCC_OPTIONS = '-B' 'sandbox/usr/bin/' '-fno-strict-aliasing' '-g' '-g' '-O2'
COLLECT_GCC         = gcc
COMPILER_PATH       = sandbox/usr/bin/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/
LIBRARY_PATH        = sandbox/usr/bin/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/../../../:/lib/:/usr/lib/:/usr/lib/arm-linux-gnueabi/

sandbox/usr/bin/ld --build-id --no-add-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X --hash-style=both -m armelf_linux_eabi /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/../../../crt1.o /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/../../../crti.o /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o -Lsandbox/usr/bin -L/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1 -L/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/../../.. -L/usr/lib/arm-linux-gnueabi /tmp/ccEn0jEp.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/crtend.o /usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/../../../crtn.o
[Leaving /tmp/ccQzTD6a.c]
[Leaving /tmp/ccYHgcZb.o]

$ ls sandbox/usr/bin/ld -l
lrwxrwxrwx 1 zumbi Debian 7 Jun 30 23:58 sandbox/usr/bin/ld -> ld.gold

Best regards and have a nice day,
  -- Hector Oron
Comment 11 Timo Juhani Lindfors 2011-07-03 15:58:34 UTC
I tested the patch but the original testcase still fails with it.

$ ld.gold -o allcodecs.so allcodecs.o
/usr/bin/ld.gold.real: internal error in value_from_output_section, at ../../gold/reloc.cc:1519
$ dpkg-query -W binutils-gold
binutils-gold 2.21.52.20110606-2lindi0
$ cat /proc/cpuinfo
Processor           : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS            : 1192.75
Features            : swp half thumb fastmult edsp
CPU implementer     : 0x56
CPU architecture: 5TE
CPU variant       : 0x2
CPU part          : 0x131
CPU revision      : 1

Hardware          : Marvell eSATA SheevaPlug Reference Board
Revision          : 0000
Serial              : 0000000000000000

The patched packages and their source is at

http://lindi.iki.fi/lindi/chromium/bug616715/
Comment 12 Ian Lance Taylor 2011-07-03 16:56:18 UTC
There is no doubt that the patch is incomplete.  That just fixed a single instance of code that must be fixed in a number of different places.
Comment 13 Doug Kwan 2011-07-06 07:00:26 UTC
(In reply to comment #12)
> There is no doubt that the patch is incomplete.  That just fixed a single
> instance of code that must be fixed in a number of different places.

I have a patch for doing unaligned accesses for all static data relocations.  I will post it when it is ready.
Comment 14 Doug Kwan 2011-07-06 07:48:56 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > There is no doubt that the patch is incomplete.  That just fixed a single
> > instance of code that must be fixed in a number of different places.
> 
> I have a patch for doing unaligned accesses for all static data relocations.  I
> will post it when it is ready.

Done.  Please see the patch in:

http://sourceware.org/ml/binutils/2011-07/msg00075.html
Comment 15 Timo Juhani Lindfors 2011-07-06 10:13:00 UTC
Thanks to Riku Voipio I now have access to hardware that can be used to debug this. Will take some time for me to find a compatible power supply and install the OS though.
Comment 16 cvs-commit@gcc.gnu.org 2011-07-06 17:58:44 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	dougkwan@sourceware.org	2011-07-06 17:58:42

Modified files:
	gold           : ChangeLog arm.cc 
	gold/testsuite : Makefile.am Makefile.in 
Added files:
	gold/testsuite : arm_unaligned_reloc.s arm_unaligned_reloc.sh 

Log message:
	2011-07-05  Doug Kwan  <dougkwan@google.com>
	
	PR gold/12771
	* arm.cc (Arm_relocate_functions::abs8): Use int32_t for addend and
	Arm_Address type for relocation result.
	(Arm_relocate_functions::abs16): Use unaligned access.  Also fix
	overflow check.
	(Arm_relocate_functions::abs32): Use unaligned access.
	(Arm_relocate_functions::rel32): Ditto.
	(Arm_relocate_functions::prel31): Ditto.
	(Arm_exidix_cantunwind::do_fixed_endian_write): Ditto.
	* testsuite/Makefile.am: Add new test arm_unaligned_reloc for unaligned
	static data relocations.
	* testsuite/Makefile.in: Regnerate.
	* testsuite/arm_unaligned_reloc.{s,sh}: New files.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/ChangeLog.diff?cvsroot=src&r1=1.789&r2=1.790
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/arm.cc.diff?cvsroot=src&r1=1.137&r2=1.138
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/arm_unaligned_reloc.s.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/arm_unaligned_reloc.sh.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.am.diff?cvsroot=src&r1=1.171&r2=1.172
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/testsuite/Makefile.in.diff?cvsroot=src&r1=1.180&r2=1.181
Comment 17 Doug Kwan 2011-07-06 18:20:05 UTC
I checked a fix in the trunk.
Comment 18 Timo Juhani Lindfors 2011-07-06 21:00:19 UTC
I can confirm that

http://sourceware.org/ml/binutils/2011-07/msg00075.html

works for me on sheevaplug.

Thanks a lot!
Comment 19 Ian Lance Taylor 2011-10-31 04:39:31 UTC
*** Bug 13362 has been marked as a duplicate of this bug. ***