public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: gcc@gcc.gnu.org, GLIBC Devel <libc-alpha@sourceware.org>
Subject: Re: [RFC] builtin functions and `-ffreestanding -nostartfies` with static binaries
Date: Fri, 10 Jan 2020 16:55:00 -0000	[thread overview]
Message-ID: <alpine.LNX.2.20.13.2001101947560.9842@monopod.intra.ispras.ru> (raw)
In-Reply-To: <129c8494-bfd0-87f0-ddb5-e56f6d4a6e0c@gotplt.org>

On Fri, 10 Jan 2020, Siddhesh Poyarekar wrote:

> I spent some time thinking about this and while it's trivial to fix by
> disabling ifuncs for static glibc, I wanted a solution that wasn't such
> a big hammer.  The other alternative I could think of is to have an
> exported alias (called __builtin_strlen for example instead of strlen)
> of a default implementation of the builtin function in glibc that gcc
> generates a call to if freestanding && nostartfiles && static.

In the Linaro bugreport you mention,

> Basically, IFUNCs and freestanding don't mix.

but really any libc (Glibc included) and -nostartfiles don't mix: stdio
won't be initialized, TLS won't be setup, and pretty much all other
libc-internal datastructures won't be properly setup. Almost no libc functions
are callable, because for example if they try to access 'errno', they crash.

Looking at the opening comment of the failing kselftest source:

 * This program tries to be as small as possible itself, to
 * avoid perturbing the system memory utilization with its
 * own execution.  It also attempts to have as few dependencies
 * on kernel features as possible.
 *
 * It should be statically linked, with startup libs avoided.
 * It uses no library calls, and only the following 3 syscalls:
 *   sysinfo(), write(), and _exit()

so in fact allowing it to link with libc strlen would be contrary to its intent.
The fix is simple: add -nodefaultlibs next to -nostartfiles in its Makefile, and
write a trivial loop in place of __builtin_strlen.

Alexander

  reply	other threads:[~2020-01-10 16:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 16:21 Siddhesh Poyarekar
2020-01-10 16:55 ` Alexander Monakov [this message]
2020-01-11  3:53   ` Siddhesh Poyarekar
2020-01-11 13:25 ` Segher Boessenkool
2020-01-11 13:32   ` Siddhesh Poyarekar

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=alpine.LNX.2.20.13.2001101947560.9842@monopod.intra.ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=siddhesh@gotplt.org \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).