bug-binutils
[Top][All Lists]
Advanced

[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.



reply via email to

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