mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Some questions
Date: Sun, 29 Apr 2018 23:16:53 -0400	[thread overview]
Message-ID: <20180430031653.GI1392@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAEg67GnETczuxhKNZfGASq62+BQqxib1GqHzj2zNZgPHaUd1Dw@mail.gmail.com>

On Mon, Apr 30, 2018 at 12:52:06PM +1000, Patrick Oppenlander wrote:
> Hi,
> 
> while working on another project I've been looking through quite a bit
> of the musl code and have come up with a few minor questions I think
> worth raising:
> 
> - Is there a way that spinlocks could be disabled or bypassed on
> uniprocessor systems?

Whether locks are needed is a matter of whether there are multiple
threads, not whether it's uniprocessor or multiprocessor. For some
things where it's likely to matter (stdio, malloc, some other
internals), locks are already optimized out when there is only one
thread. In other cases it was deemed either too costly/difficult or
irrelevant to overall performance.

> - sigisemptyset uses bss. Could be implemented in a similar fashion to
> sigemptyset, save bss & would probably be faster.

Ahh, yes. I wonder if gcc has any way to force const zero objects into
rodata rather than bss..? In any case memcmp is not an efficient way
to implement this, so maybe it should be changed.

> - getcwd returned buffer size can be incorrect. If you call
> getcwd(NULL, 1234) the returned buffer is sized to match the path
> length but should be 1234 to be compatible with the glibc extension.

I'll look at this. It seems like a worse behavior for most callers,
but maybe it should match.

> - Are there any plans to support static linking with LTO?

It should be possible, but gcc mishandles the crt files when doing
LTO. I think if you suppress LTO for them it works. Someone posted
results experimenting with it either on the list or IRC channel
recently. I'll see if I can find anything useful.

Rich


  reply	other threads:[~2018-04-30  3:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-30  2:52 Patrick Oppenlander
2018-04-30  3:16 ` Rich Felker [this message]
2018-04-30  3:55   ` Patrick Oppenlander
2018-04-30 15:35     ` Rich Felker
2018-05-01  2:35       ` Patrick Oppenlander
2018-05-01 21:03         ` Rich Felker
2018-05-01 22:14           ` Patrick Oppenlander
2018-04-30  5:17   ` Patrick Oppenlander
2018-04-30 15:29     ` Rich Felker
2018-05-01  2:32       ` Patrick Oppenlander
2018-04-30  5:29   ` Patrick Oppenlander
2018-04-30 15:31     ` Rich Felker
2018-05-01  2:34       ` Patrick Oppenlander
2018-05-01 15:52         ` Rich Felker
2018-05-01 17:35           ` Rich Felker
2018-05-01 21:49             ` Andre McCurdy
2018-05-01 22:14               ` Szabolcs Nagy
2018-05-02 13:42                 ` Rich Felker
2018-05-01  0:10   ` Patrick Oppenlander
2018-05-01 14:19     ` Szabolcs Nagy
2018-05-01 21:05     ` Rich Felker

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=20180430031653.GI1392@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).