mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Reformatting dynamic linker error mesages? (or, Bikeshed April 2015)
Date: Wed, 22 Apr 2015 02:15:28 -0400	[thread overview]
Message-ID: <20150422061527.GC6817@brightrain.aerifal.cx> (raw)
In-Reply-To: <20150422003740.GB1773@Sparta>

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


      reply	other threads:[~2015-04-22  6:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-18 22:54 Rich Felker
2015-04-22  0:37 ` Isaac Dunham
2015-04-22  6:15   ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150422061527.GC6817@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).