[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/19013] New: Section corrupted with elf64-x86-64 input -> elf32-i
From: |
toni at famkaufmann dot info |
Subject: |
[Bug ld/19013] New: Section corrupted with elf64-x86-64 input -> elf32-i386 output |
Date: |
Mon, 28 Sep 2015 02:51:41 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=19013
Bug ID: 19013
Summary: Section corrupted with elf64-x86-64 input ->
elf32-i386 output
Product: binutils
Version: 2.26 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: toni at famkaufmann dot info
Target Milestone: ---
Host: x86_64-linux-gnu
Target: elf32-i386
Build: x86_64-linux-gnu
Created attachment 8641
--> https://sourceware.org/bugzilla/attachment.cgi?id=8641&action=edit
Simplified test case
I'm linking elf64-x86-64 files together and outputting an elf32-i386 executable
(long story, involving a mix of 32 bit and 64 bit code running bare metal). Now
I noticed that some of my string constants were getting corrupted during
linking, truncated mostly. From what I can tell, what happens is that the
section contens from an input file gets truncated. I've tried to reduce this to
a minimal example to show what happens (tested with debian's 2.25.1 and a
recent git version):
> $ bash testcase.sh
> + cat
> + as -o a.o a.s
> + ld --oformat elf32-i386 -o b a.o
> ld: warning: cannot find entry symbol _start; defaulting to 0000000000400054
> + objdump -s -j .rodata.str1.1 a.o
>
> a.o: file format elf64-x86-64
>
> Contents of section .rodata.str1.1:
> 0000 00000203 00414243 4400 .....ABCD.
> + objdump -s -j .rodata b
>
> b: file format elf32-i386
>
> Contents of section .rodata:
> 400054 00000203 00414243 .....ABC
The expected behavior would obviously be to have the full section contents in
the executable. If I change the output format to a 64 bit elf this does not
seem to happen. Also I admit that my setting is weird, so I guess there might
be something inherently preventing this from working correctly but even then
I'd expect a warning/error instead of corrupted section contents.
The attached script contains my simplified testcase.
Thanks
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/19013] New: Section corrupted with elf64-x86-64 input -> elf32-i386 output,
toni at famkaufmann dot info <=