mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: Dominic Chen <d.c.ddcc@gmail.com>
Subject: Re: [musl] SIGSEGV with TEXTREL
Date: Fri, 25 Sep 2020 14:58:34 -0400	[thread overview]
Message-ID: <20200925185834.GN3265@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200925093733.GJ2947641@port70.net>

On Fri, Sep 25, 2020 at 11:37:33AM +0200, Szabolcs Nagy wrote:
> * Dominic Chen <d.c.ddcc@gmail.com> [2020-09-24 23:50:19 -0400]:
> > Please CC me on replies.
> > 
> > I recently discovered that musl doesn't support DT/DF_TEXTREL in the
> > main executable, which can result in the dynamic loader crashing with
> > SIGSEGV and SEGV_ACCERR while processing relocations. I spent a few days
> > trying to fix this in the toolchain, but because it is a prototype based
> > on Clang/LLVM 4.0.0 that adds runtime instrumentation built using the
> > x64 large code model, so it's not easy to fix. Also, glibc does support
> > this behavior.
> 
> there are no existing libcs that fully support textrels
> (since for that not just dynamic relocs but static relocs
> need to be supported too).
> 
> glibc only supports a small set of textrels and of course
> [...]

Indeed, textrels are intentionally not supported as part of the
philosophy of having a dynamic linker that's universal rather than
arch-specific for each arch. Dynamic relocations are pretty much the
same on all archs but each arch has its own (often giant) set of
possible textrels based on the encoding of addresses in its
instruction set.

For legacy reasons, a limited number of textrel types are supported,
only on some archs (basically just i386 and x86_64), in shared library
code. At least at one point, there was still a decent amount of x86
asm that was not PIC-ready, especially in graphics code. I think that
time is actually past now, but it doesn't make sense to remove
something that didn't need any special support to begin with.

On the other hand, there's no compelling reason to support textrels in
the main program since the main program can just be linked as non-PIE
if you have object files (e.g. due to asm source files or static
libraries you don't have source to) that are not PIC-compatible.

Rich

  reply	other threads:[~2020-09-25 18:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25  3:50 Dominic Chen
2020-09-25  9:37 ` Szabolcs Nagy
2020-09-25 18:58   ` Rich Felker [this message]
2020-09-25 20:13   ` Dominic Chen
2020-09-25 20:49     ` Markus Wichmann
2020-09-25 22:46     ` Rich Felker
2020-09-26  0:32       ` Dominic Chen
2020-09-26  4:14         ` Fangrui Song
2020-09-26  9:09           ` Szabolcs Nagy

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=20200925185834.GN3265@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=d.c.ddcc@gmail.com \
    --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).