bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/22419] New: binary format generated by LD is incorrect


From: hackish at gmail dot com
Subject: [Bug ld/22419] New: binary format generated by LD is incorrect
Date: Fri, 10 Nov 2017 18:06:09 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=22419

            Bug ID: 22419
           Summary: binary format generated by LD is incorrect
           Product: binutils
           Version: 2.30 (HEAD)
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: hackish at gmail dot com
  Target Milestone: ---

Created attachment 10579
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10579&action=edit
Test case

LD as shown in this example for the NEC V850 processor generates bogus jump
instructions resolving addresses when used to output in format=binary. The
object files are generated correctly, and the linker exhibits this behavior
only using binary mode. 

As the example shows, it generates correct code if the output is done in ELF,
then changed into a binary using objcopy. This example was run on 2.17.50, but
others also verified the problem in a variety of versions up to 2.30. The
example is for the NEC V850 processor, but others reported similar problems on
other architectures.

Extract the attached archive, and run:
gmake clean all

Expected output is:
rm -f one.o firmware.o a.out a.elf a.bin
v850-elf-as -mv850e1 -c firmware.s -o firmware.o
v850-elf-as -mv850e1 -c one.s -o one.o
v850-elf-ld -nostdlib --no-check-sections -Map=a.map -T one.lnk -o a.elf
v850-elf-ld -nostdlib --no-check-sections -Map=a.map --oformat binary -T
one.lnk -o a.bin
v850-elf-objcopy -O binary a.elf a.out
Results going direct to binary
hexdump -s 0x4E608 -n 28 a.bin
004e608 ffff ffff 3640 1234 3e40 5678 c784 fffb
004e618 3640 1234 3e40 5678 ffff ffff          
004e624
Results with elf as an intermediate:
hexdump -s 0x4E608 -n 28 a.out
004e608 ffff ffff 3640 1234 3e40 5678 ffbb c77c
004e618 3640 1234 3e40 5678 ffff ffff          
004e624
Result should have been:
004e608 ffff ffff 3640 1234 3e40 5678 ffbb c77c
004e618 3640 1234 3e40 5678 ffff ffff

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]