Project

General

Profile

Bug #2186

ELF files with libc.so.1 as interpreter report errors badly

Added by Rich Lowe over 8 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
lib - userland libraries
Start date:
2012-02-26
Due date:
% Done:

0%

Estimated time:
Difficulty:
Expert
Tags:
needs-triage
Gerrit CR:

Description

As mentioned in #1487, if libc is the interpretter for a given ELF executable (GNU binutils does this, it seems), and errors occur when mapping the runtime linker the reported error information is not entirely forthcoming, and is also misformed.

There are a few problems here.

  • We pass the name of the executable to f.PANIC, but we newer call write() to display it, we just display s.ERROR. This is why the error in #1487 has a leading colon. The program name should have been before there. There's a missing call f.WRITE which should have output.
  • In certain cases, the messages which are reported aren't useful. They assume that the problem is with ld.so.1, which it will be in about 99% of cases, but there are two cases, the open and mmap of /dev/zero, which don't. These being what #1487 ran directly into.

Anyone fixing this should be aware that this code runs, by definition, prior to runtime linking. Relocation has not been performed, functions not carefully defined may not be called, data requiring relocation may not be accessed. Everything is very, very carefully arranged and (obviously) must remain so.

In the simplest case you would:

  • Define a new string, in the style of s.ERROR, to complain about /dev/zero instead
  • Write a new, f.PANIC-like function to display this error

It is possible less simple in practice.


Related issues

Related to illumos gate - Bug #1487: some binaries fail to work in a chroot environment.Rejected2011-09-09

Actions

Also available in: Atom PDF