similar to: [lld][ELF] Add option to make .dynamic read only

Your understanding is correct. It saves a small number of physical pages. It's strictly better even if it's only a little bit better. On Tue, May 16, 2017, 5:14 PM Rui Ueyama <ruiu at google.com> wrote: > Hi Jake, > > Thank you for sending this to llvm-dev! > > If I understand correctly, your motivation to add an option to make > .dynamic sections read-only is to

The motivation is not only memory savings but also security: can-never-be-written is strictly better than RELRO in all cases. The biggest win is when .dynamic is the sole reason for having a writable segment at all. The distinction is fairly small for exploitability, but not negligible. LLD already has several command-line options that are not supported by or are different from ld or gold, so

On Wed, May 17, 2017 at 1:32 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 17, 2017 at 1:11 PM, Petr Hosek <phosek at chromium.org> wrote: > >> The motivation is not only memory savings but also security: >> can-never-be-written is strictly better than RELRO in all cases. The >> biggest win is when .dynamic is the sole reason

Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org> writes: > One of the design principles we're trying to follow is to make everything > read-only, unless it has be writable. The only reason for .dynamic to be > writable is DT_DEBUG which is something we never intend to support. FWIW in > Fuchsia all we need is a read-only .dynamic without emitting DT_DEBUG > altogether,

On Mon, Dec 8, 2014 at 8:39 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 12/8/2014 11:09 AM, Joerg Sonnenberger wrote: >> >> On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: >>> >>> The DT_INIT/DT_FINI correspond to one initializer function,where as >>> DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one

On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: > The DT_INIT/DT_FINI correspond to one initializer function,where as > DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one > initalizer function/finalizer function respectively. This is not true. The difference is that the DT_INIT / DT_FINI function is responsible for calling into the .init / .fini block and

On 3/21/23 18:28, Eric Blake wrote: > it is indeed a bug in busybox now that POSIX is moving towards > standardizing realpath, so I've filed it: > https://bugs.busybox.net/show_bug.cgi?id=15466 I've found another busybox bug. The "/bin/sh" utility is provided by busybox as well (via the usual symlinking). Per POSIX, if execvp(file, { argv[0], argv[1], ..., NULL })

On Tue, Mar 21, 2023 at 03:56:22PM +0100, Laszlo Ersek wrote: > > $ podman build -f ci/containers/alpine-edge.Dockerfile -t libnbd-alpine-edge > > $ podman run -it --rm --userns=keep-id -v .:/repo:z -w /repo libnbd-alpine-edge bash > > $ ./configure > > $ make check > > $ grep tmpd= lib/test-suite.log > > + tmpd=/tmp/tmp.EMgKeF > > $ /tmp/tmp.EMgKeF/bin/f

I have managed to compile llvm and clang against musl, but it behaves really strange: At first I tried to launch the compiler with musl dynamic loader: $ LD_LIBRARY_PATH=/path/to/musl/lib /path/to/musl/lib/ld-musl-x86_64.so.1 /path/to/llvm/bin/clang -v clang version 4.0.0 (https://github.com/llvm-mirror/clang 40adebeca0f99006d407508653c2cbd270a1a51c) (https://github.com/llvm-mirror/llvm

Alpine linux is a distribution that uses musl libc instead glibc. Here are my steps to reproduce: On Alpine linux, download LLVM, Clang, LLD 6.0.0 from releases.llvm.org, and build them from source. $ clang -c hello_world.c $ ld.lld --gc-sections -m elf_x86_64 -o hello_world /usr/lib/gcc/x86_64-alpine-linux-musl/6.4.0/../../../../lib/Scrt1.o

Can you add `--reproduce=repro` to lld command line? That generates repro.tar in your current directory which contains all input files. And then please compress and upload it somewhere so that we can take a look. On Mon, Apr 2, 2018 at 9:18 AM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alpine linux is a distribution that uses musl libc instead glibc. Here are

https://superjoe.s3.amazonaws.com/temp/repro.tar.xz On Mon, Apr 2, 2018 at 1:26 PM, Rui Ueyama <ruiu at google.com> wrote: > Can you add `--reproduce=repro` to lld command line? That generates > repro.tar in your current directory which contains all input files. And > then please compress and upload it somewhere so that we can take a look. > > > On Mon, Apr 2, 2018 at

Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once

On Fri, Aug 04, 2017 at 04:40:44PM -0600, Jonathan Roelofs wrote: > Might be a helpful exercise for you to try building vanilla clang with > runtimes for the host, before worrying about how to build everything for > your baremetal case: > http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary So I did. :o) It was fun realizing how much Release type reduces LD

There is incompatibility between R strptime and musl libc. I posted about it on their mailing list, but they need more information I can't provide, so I'm forwarding the message here in hope R developers can help. Thanks. ---------- Forwarded message ---------- From: Rich Felker <dalias at libc.org> Date: Thu, Feb 4, 2016 at 2:07 PM Subject: Re: [musl] strptime() question To: Alba

For example, I execute the following command sequences: H:\CI\bld\compilers\musl\src\math\i386>type sqrt.s #.globl _sqrt .global sqrt #.type sqrt, at function #_sqrt: sqrt: fldl 4(%esp) fsqrt fstsw %ax sub $12,%esp fld %st(0) fstpt (%esp) mov (%esp),%ecx and $0x7ff,%ecx cmp $0x400,%ecx jnz 1f and $0x200,%eax

2015-03-11 16:22 GMT-05:00 Richard Gorton < rcgorton at cognitive-electronics.com>: > I can confirm that musl builds and works correctly with clang/llvm. We > are using musl as a libc for our architecture. > It has a much smaller code footprint than newlib or glibc. > I successfully cross-compile the must-libc using clang, with the configuration: C=clang

> ELLCC (http://ellcc.org), my clang/LLVM based cross development tool chain for > ARM, Microblaze, Mips, Power PC, and X86, now incorporates musl > (http://www.etalabs.net/musl) as its standard C library for Linux. musl is a > MIT licensed, highly POSIX compliant library offering high performance and a > small foot print. I spent several weeks evaluating musl before deciding to use

Here's what I did. svn checkout https://svn.r-project.org/R/trunk/ cd ./trunk aclocal -I m4 && autoconf tools/rsync-recommended cd .. mkdir build cd build ../trunk/configure make make check On make check it gives an error. Here's the log. http://pastebin.com/raw/1qfjqQY2 On Mon, Feb 1, 2016 at 1:53 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote: > > On Feb

Hi Folks, I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say