bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/29284] New: ld silently exits with empty input files with succes


From: jengelh at inai dot de
Subject: [Bug ld/29284] New: ld silently exits with empty input files with success
Date: Fri, 24 Jun 2022 21:31:52 +0000

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

            Bug ID: 29284
           Summary: ld silently exits with empty input files with success
           Product: binutils
           Version: 2.38
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: jengelh at inai dot de
  Target Milestone: ---

Maybe related: bug #10321

Observed:

sh$ >x.o
sh$ ld -r -o new.o x.o; echo $?
0

Expected:

$? == 1


Long rationale:

A parallel-unsafe Makefile could cause a race between two commands that then
concurrently write to the same .o file, leaving it truncated or otherwise
incomplete.

When that happens, ld is usually quick to point out that there is a problem
with the file. Synthetic example trigger:

sh$ echo 'int main(){}' >x.c
sh$ gcc -c x.c
sh$ ls -lgo x.o
-rw-r--r-- 1 1216 Jun 24 23:17 x.o
sh$ truncate -s 1215 x.o
sh$ ld -r -o new.o x.o; echo $?
x.o: file not recognized: file format not recognized
1

However, when that object file happens to be 0 bytes long, ld silently accepts
it.

sh$ truncate -s 0 x.o
sh$ ld -r -o new.o x.o; echo $?
0

Because of this, a project may even end up producing a shared library which is
incomplete and you would not necessarily know of if the symbols you believed
were included (but aren't) are not exercised by any executable.

sh$ gcc -shared -o new.so x.o y.o z.o; ldd -r new.so
        linux-vdso.so.1 (0x00007ffd816d9000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa7c2400000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa7c26e8000)

  “ No "undefined symbol", so everything is fine! ... Right? ”


I recognize that libbfd knows many object and archive file types, and that some
formats could potentially have legitimate 0-byte archives. Moreover, the ld(1)
manpage elaborates that """If the linker cannot recognize the format of an
object file, it will assume that it is a linker script.""" and, unfortunately,
0-sized scripts are legitimate scripts in many programming languages, which
makes it harder to detect accidentally truncated files  :-/

-- 
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]