> Date: Tue, 24 Jan 2017 15:39:49 +1000
> From: Philip Guenther <[email protected]>
> 
> So right now, ld.so simply exits iun various error cases, like unknown 
> relocation.  This isn't great, as it's a normal exit when a linking 
> failure really should be an abnormal exit as from a fatal signal.  If 
> "grep" has a linking failure I want it to *die* instead of meekly 
> returning non-zero.
> 
> Diff below adds three functions to make fatal error handling simpler:
>  - _dl_diedie()
>    This makes the process kill itself with SIGKILL via thrkill(2).  It 
>    might be nicer to do SIGABRT, but that can be caught so it would need
>    to be prepared to use sigaction and suddenly it seems like overkill.
> 
>  - _dl_die(fmt, ...)
>    This is a printf-like function that prints a prefix of
>       "ld.so: progname: "
>    then the provided format, and finally it adds a newline and calls 
>    _dl_diedie().  Makes reporting fatal errors trivial.
>    
>  - _dl_oom()
>    Like _dl_die("out of memory"), for use in the common case of a
>    failed malloc/etc
> 
> 
> The rest of the diff then converts the existing "_dl_printf()+_dl_exit()" 
> and "_dl_printf() + forced segfault" cases into calls to _dl_die() or 
> _dl_oom() as appropriate.  Only places which already used _dl_exit() or 
> tried to trigger a segfault have been changed to use these.
> 
> Tested on amd64, armv7, loongson, macppc, and sparc64 by building a 
> version of libc with the 'vis' line removed from Symbols.list, then 
> running 'vis' against that .so and verifying the output is something 
> like:
>       vis:vis: undefined symbol 'vis'
>       ld.so: vis: lazy binding failed!
>       Killed
> 
> Test results for other archs?  oks?

Looks ok to me.  However:

> @@ -57,6 +57,8 @@ int _dl_getcwd(char *, size_t);
>  int  _dl_utrace(const char *, const void *, size_t);
>  int  _dl_getentropy(char *, size_t);
>  int  _dl_sendsyslog(const char *, size_t, int);
> +__dead
> +void _dl_thrkill(pid_t, int, void *);

Doesn't make sense to have __dead on a separate line here.  There are
a couple of those throughout the diff.

Reply via email to