Reformatting dynamic linker error mesages? (or, Bikeshed April 2015)

Reformatting dynamic linker error mesages? (or, Bikeshed April 2015)

[Rich Felker]

One item on the roadmap that I want to work on is making the dynamic
linker error strings translatable. Since (unwritten, maybe) policy is
that we don't translate format strings in libc (it makes untrusted
locale files dangerous), this is going to require at least
restructuring of the code that generates the messages, and also calls
for restructuring of the actual text. I'm looking for ideas on how to
do this and make it the most legible and informative.

The errors we have to worry with are:

"Error relocating %s: %s: symbol not found"
"Error relocating %s: cannot allocate TLSDESC for %s",
"Error relocating %s: unsupported relocation type %d",
"Error loading shared library %s: %m (needed by %s)",
"Error relocating %s: RELRO protection failed: %m",
"cannot load %s: %m\n"
"%s: Not a valid dynamic program\n"
"Library %s is not already loaded"
"Error loading shared library %s: %m"
"Invalid library handle %p"
"Symbol not found: %s"
"Dynamic loading not supported"
"Unsupported request %d"

I think we should aim to separate it into a :-delimited form where
there's no grammatical relationship between fields, since making
grammar fit multiple natural languages is basically impossible.

Note that some of the above error messages are bad to begin with. We
don't necessarily need to preserve the content as-is; I'd much rather
make the error messages better at the same time.

For errors loading/mapping a library, I think we need to report the
cause, which could be:
- System-level errors opening/reading/etc.
- File-format errors
- Memory-allocation failure

It may also be useful, if the failing library is being loaded as a
dependency for another library, to report the library that needed it.

For errors during relocation, we need to report the library that could
not be relocated, and the reason, which could be:
- Missing symbol (need to show which symbol)
- Unknown/invalid relocation type
- Memory-allocation failure
- System-level failures (mprotect, etc.)

Everything else looks pretty straightforward.

It's also unclear to me whether we should aim to change the signature
of the error() function to take fixed fields, which error() is then
responsible for translating, or whether the caller should translate
fixed strings going in (in which case the caller has freedom to use
lots of different formats).

Rich

Re: Reformatting dynamic linker error mesages? (or, Bikeshed April 2015)

[Isaac Dunham]

On Sat, Apr 18, 2015 at 06:54:36PM -0400, Rich Felker wrote:
> One item on the roadmap that I want to work on is making the dynamic
> linker error strings translatable. Since (unwritten, maybe) policy is
> that we don't translate format strings in libc (it makes untrusted
> locale files dangerous), this is going to require at least
> restructuring of the code that generates the messages, and also calls
> for restructuring of the actual text. I'm looking for ideas on how to
> do this and make it the most legible and informative.
> 
> The errors we have to worry with are:

[reordered to make redundancy more obvious]

> "Symbol not found: %s"
> "Error relocating %s: %s: symbol not found"
> "Error relocating %s: cannot allocate TLSDESC for %s",
> "Error relocating %s: unsupported relocation type %d",
> "Error relocating %s: RELRO protection failed: %m",
> "Error loading shared library %s: %m (needed by %s)",
> "Error loading shared library %s: %m"
> "cannot load %s: %m\n"
> "%s: Not a valid dynamic program\n"
> "Library %s is not already loaded"
> "Invalid library handle %p"
> "Dynamic loading not supported"
> "Unsupported request %d"


It looks like there's a bit of redundancy here, where 2-5 share
"Error relocating %s", 6 and 7 share "Error loading shared library",
and 1 and 2 share (save capitalization) "symbol not found".
It would be nice to see that redundancy turned into shared submessages.

I also notice that there's a mix of two equivalent formats:
error("...%m...") and
dprintf(fd, "...%s...", strerror(errno))

which I find odd.

Do we want the calls to strerror(errno) converted to something localized?
If so, %m would seem to be harmful.
On the other hand...is localization set up this early?
 
> I think we should aim to separate it into a :-delimited form where
> there's no grammatical relationship between fields, since making
> grammar fit multiple natural languages is basically impossible.

Agreed.

> Note that some of the above error messages are bad to begin with. We
> don't necessarily need to preserve the content as-is; I'd much rather
> make the error messages better at the same time.
> 
> For errors loading/mapping a library, I think we need to report the
> cause, which could be:
> - System-level errors opening/reading/etc.
> - File-format errors
> - Memory-allocation failure
> 
> It may also be useful, if the failing library is being loaded as a
> dependency for another library, to report the library that needed it.

> For errors during relocation, we need to report the library that could
> not be relocated, and the reason, which could be:
> - Missing symbol (need to show which symbol)
> - Unknown/invalid relocation type
> - Memory-allocation failure
> - System-level failures (mprotect, etc.)
> 
> Everything else looks pretty straightforward.
> 
> It's also unclear to me whether we should aim to change the signature
> of the error() function to take fixed fields, which error() is then
> responsible for translating, or whether the caller should translate
> fixed strings going in (in which case the caller has freedom to use
> lots of different formats).

Consider these strings:

> "Error loading shared library %s: %m (needed by %s)",
> "Error relocating %s: cannot allocate TLSDESC for %s",
> "Error relocating %s: %s: symbol not found"

Looking at the strings in question, it seems clear to me that we will
need to intermix translated and untranslateable strings to make the 
meaning clear. While the error message can be adjusted, it gets hard
to comprehend the error when data is not adjacent to its explanation.

Theoretically, you could stipulate that every other field is translated
and empty strings are skipped, but that sounds rather brittle.

Thanks,
Isaac Dunham

Re: Reformatting dynamic linker error mesages? (or, Bikeshed April 2015)

[Rich Felker]

On Wed, Apr 22, 2015 at 12:37:41AM +0000, Isaac Dunham wrote:
> On Sat, Apr 18, 2015 at 06:54:36PM -0400, Rich Felker wrote:
> > One item on the roadmap that I want to work on is making the dynamic
> > linker error strings translatable. Since (unwritten, maybe) policy is
> > that we don't translate format strings in libc (it makes untrusted
> > locale files dangerous), this is going to require at least
> > restructuring of the code that generates the messages, and also calls
> > for restructuring of the actual text. I'm looking for ideas on how to
> > do this and make it the most legible and informative.
> > 
> > The errors we have to worry with are:
> 
> [reordered to make redundancy more obvious]

Thanks.

> > "Symbol not found: %s"
> > "Error relocating %s: %s: symbol not found"
> > "Error relocating %s: cannot allocate TLSDESC for %s",
> > "Error relocating %s: unsupported relocation type %d",
> > "Error relocating %s: RELRO protection failed: %m",
> > "Error loading shared library %s: %m (needed by %s)",
> > "Error loading shared library %s: %m"
> > "cannot load %s: %m\n"
> > "%s: Not a valid dynamic program\n"
> > "Library %s is not already loaded"
> > "Invalid library handle %p"
> > "Dynamic loading not supported"
> > "Unsupported request %d"

Here's a first try at making these reasonable for localization (still
left as format strings for clarity even though they can't actually
be):

"Symbol not found: %s"

"Error relocating library: %s: Symbol not found: %s"
"Error relocating library: %s: Unsupported relocation type: %d"
"Error relocating library: %s: Memory protection failure: %m"
"Error relocating library: %s: Out of memory"
and all of the above with:
"Error relocating main program:"
instead of library.

"Error loading dependency: %s (%s): %m"
"Error loading library: %s: %m"

"Error loading file: %s: %m"

"Library not already loaded: %s"
"Invalid library handle: %p"
"Dynamic loading not supported"
"Unsupported request: %d"

The %m's are also something of a fiction since there are a few cases
where we would want a message that doesn't come from errno (e.g.
invalid ELF headers). That's mildly ugly but definitely solvable.

> It looks like there's a bit of redundancy here, where 2-5 share
> "Error relocating %s", 6 and 7 share "Error loading shared library",
> and 1 and 2 share (save capitalization) "symbol not found".
> It would be nice to see that redundancy turned into shared submessages.

Yes. For example with symbol-not-found, the actual format would be
something like:

"%s: %s: %s: %s", _("Error relocating library"), name, _("Symbol not found"), sym

and:

"%s: %s", _("Symbol not found"), sym

Note that I'm using the GNU gettext _() notation for translation just
to make this simple to write in email; I don't endorse this in code.
:-)

> I also notice that there's a mix of two equivalent formats:
> error("...%m...") and
> dprintf(fd, "...%s...", strerror(errno))
> 
> which I find odd.

I believe this is because the error function was originally unsuitable
for some of those places, but I may be wrong. I think it could be used
now.

> Do we want the calls to strerror(errno) converted to something localized?
> If so, %m would seem to be harmful.

strerror already returns a translated message. So does %m.

> On the other hand...is localization set up this early?

At first the messages would only be available via dlerror after
setlocale. However I think it may make sense to have the dynamic
linker setlocale(LC_ALL, "") on the first error. Since the main
program will never be invoked if there are errors, this would not
affect program semantics at all.

Rich