Page MenuHomeFreeBSD

1) Add new rtld option to display error messages

Authored by peterj on Jan 26 2017, 7:24 AM.


Group Reviewers

The runtime linker internally saves details of errors it encounters but
these are are only exposed if dlerror(3) is called. Setting LD_PRINT_ERROR
to a non-empty string will automatically print all errors detected by the
runtime linker to stderr.

MFC after: 1 week

Test Plan

Compile the following code and execute with and without LD_PRINT_ERROR set
to a non-empty string. Note that the error is printed twice, apparently
because there's a second attempt to resolve the missing symbol during the
program cleanup.

#include <dlfcn.h>
#include <err.h>
#include <stdio.h>

int main(int argc, char **argv)

if (dlsym(NULL, "symbol_missing") != NULL)
    errx(1, "Found unexpected symbol");
return (0);


Diff Detail

rS FreeBSD src repository - subversion
Lint OK
No Unit Test Coverage
Build Status
Buildable 7031
Build 7211: arc lint + arc unit

Event Timeline

peterj retitled this revision from to 1) Add new rtld option to display error messages.
peterj updated this object.
peterj edited the test plan for this revision. (Show Details)
peterj added reviewers: kib, jhb.

I must note that for my whole-time usage of FreeBSD, I never needed such functionality. Rather, when I needed anything close to the proposed patch, I needed much more information, enabled by the LD_DEBUG knob. The only complication with LD_DEBUG is that we still do not compile rtld in this mode by default, but recompilation is trivial.

Also I am not convinced that adding a verbose features to the userspace runtime components is safe, the printing depends on too many assumptions about the program environment, like that the fd 2 is stderr, printing into it is safe etc.

Wouldn't utrace patch enough to diagnose ?


Compare your usage of the LD prefix wrapping and the same usage one line above.

wblock added inline comments.

Is this still valid if we make it more active?

to print error messages that are available to the application from

(Also avoiding "via", which only seems valid to me when given with a network or highway-type map.)

Based on kib's comments, I'll withdraw this revision. r312984 is similar functionality.


That's what I get for forward-porting a patch and not adequately verifying changes.