[PATCH 1/3] PIE support for arm

[PATCH 1/3] PIE support for arm

[Timo Teräs]

---
Originally based on the glibc's implementation, but as this is
very short function (of which only maybe 10 lines are from the
original work), and the rest is modified to suit musl. I believe
we could just place on public domain.

 crt/arm/Scrt1.s | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 crt/arm/Scrt1.s

diff --git a/crt/arm/Scrt1.s b/crt/arm/Scrt1.s
new file mode 100644
index 0000000..b8fdfda
--- /dev/null
+++ b/crt/arm/Scrt1.s
@@ -0,0 +1,34 @@
+.weak _init
+.weak _fini
+.text
+.global _start
+_start:
+        mov fp,#0
+        mov lr,#0
+
+        pop { a2 }
+        mov a3, sp
+        push { a3 }
+        push { a1 }
+
+        ldr sl, .L_GOT
+        adr a4, .L_GOT
+        add sl, sl, a4
+        ldr ip, .L_GOT+4
+        ldr ip, [sl, ip]
+        push { ip }
+        ldr a4, .L_GOT+8
+        ldr a4, [sl, a4]
+        ldr a1, .L_GOT+12
+        ldr a1, [sl, a1]
+
+        bl __libc_start_main(PLT)
+1:      b 1b
+
+        .align 2
+.L_GOT:
+        .word _GLOBAL_OFFSET_TABLE_ - .L_GOT
+        .word _fini(GOT)
+        .word _init(GOT)
+        .word main(GOT)
+
-- 
1.8.3.2

[PATCH 2/3] Unwind support for ARM EABI

[Timo Teräs]

ARM EABI does not use the .eh_frame and .eh_frame_hdr for unwinding.
Instead the ABI specifies it's own way to unwind using .ARM.exidx and
.ARM.extab.

libgcc uses __gnu_Unwind_Find_exidx (libc must implement this) when
unwinding using exidx. This function is implemented here.
---
 arch/arm/src/find_exidx.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 arch/arm/src/find_exidx.c

diff --git a/arch/arm/src/find_exidx.c b/arch/arm/src/find_exidx.c
new file mode 100644
index 0000000..ffbea1f
--- /dev/null
+++ b/arch/arm/src/find_exidx.c
@@ -0,0 +1,44 @@
+#define _GNU_SOURCE
+#include <link.h>
+
+typedef unsigned _Unwind_Ptr;
+
+struct find_exidx_data {
+	_Unwind_Ptr pc, exidx_start;
+	int exidx_len;
+};
+
+static int find_exidx(struct dl_phdr_info *info, size_t size, void *ptr)
+{
+	struct find_exidx_data *data = ptr;
+	const ElfW(Phdr) *phdr = info->dlpi_phdr;
+	_Unwind_Ptr addr;
+	int match = 0, i;
+
+	for (i = info->dlpi_phnum; i > 0; i--, phdr++) {
+		addr = info->dlpi_addr + phdr->p_vaddr;
+		switch (phdr->p_type) {
+		case PT_LOAD:
+			match |= data->pc >= addr && data->pc < addr + phdr->p_memsz;
+			break;
+		case PT_ARM_EXIDX:
+			data->exidx_start = addr;
+			data->exidx_len = phdr->p_memsz;
+			break;
+		}
+	}
+	return match;
+}
+
+_Unwind_Ptr __gnu_Unwind_Find_exidx(_Unwind_Ptr pc, int * pcount)
+{
+	struct find_exidx_data data;
+
+	data.pc = pc;
+	data.exidx_start = 0;
+	if (dl_iterate_phdr(find_exidx, &data) <= 0)
+		return 0;
+	*pcount = data.exidx_len / 8;
+	return data.exidx_start;
+}
+
-- 
1.8.3.2

[PATCH 3/3] [FYI] fix dynamic linker dso loading

[Timo Teräs]

The phdr entries need to be allocated from heap, so later calls
to dl_iterate_phdr work properly. Make sure the ARM unwind info
is not freed.
---
This is not exactly intended to be committed, but shows clearly
what is wrong with the current implementation.

The reclamation fix should be probably something better, as I believe
the same applies to GNU_EH_FRAME phdr.

 src/ldso/dynlink.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/ldso/dynlink.c b/src/ldso/dynlink.c
index 7031d03..a956b39 100644
--- a/src/ldso/dynlink.c
+++ b/src/ldso/dynlink.c
@@ -293,7 +293,7 @@ static void reclaim(unsigned char *base, size_t start, size_t end)
 static void reclaim_gaps(unsigned char *base, Phdr *ph, size_t phent, size_t phcnt)
 {
 	for (; phcnt--; ph=(void *)((char *)ph+phent)) {
-		if (ph->p_type!=PT_LOAD) continue;
+		if (ph->p_type != PT_LOAD && ph->p_type != PT_ARM_EXIDX) continue;
 		if ((ph->p_flags&(PF_R|PF_W))!=(PF_R|PF_W)) continue;
 		reclaim(base, ph->p_vaddr & -PAGE_SIZE, ph->p_vaddr);
 		reclaim(base, ph->p_vaddr+ph->p_memsz,
@@ -327,7 +327,8 @@ static void *map_library(int fd, struct dso *dso)
 		eh->e_phoff = sizeof *eh;
 	}
 	ph = (void *)((char *)buf + eh->e_phoff);
-	dso->phdr = ph;
+	dso->phdr = malloc(phsize);
+	memcpy(dso->phdr, ph, phsize);
 	dso->phnum = eh->e_phnum;
 	for (i=eh->e_phnum; i; i--, ph=(void *)((char *)ph+eh->e_phentsize)) {
 		if (ph->p_type == PT_DYNAMIC)
@@ -338,7 +339,7 @@ static void *map_library(int fd, struct dso *dso)
 			dso->tls_len = ph->p_filesz;
 			dso->tls_size = ph->p_memsz;
 		}
-		if (ph->p_type != PT_LOAD) continue;
+		if (ph->p_type != PT_LOAD && ph->p_type != PT_ARM_EXIDX) continue;
 		if (ph->p_vaddr < addr_min) {
 			addr_min = ph->p_vaddr;
 			off_start = ph->p_offset;
@@ -365,7 +366,7 @@ static void *map_library(int fd, struct dso *dso)
 	base = map - addr_min;
 	ph = (void *)((char *)buf + eh->e_phoff);
 	for (i=eh->e_phnum; i; i--, ph=(void *)((char *)ph+eh->e_phentsize)) {
-		if (ph->p_type != PT_LOAD) continue;
+		if (ph->p_type != PT_LOAD && ph->p_type != PT_ARM_EXIDX) continue;
 		/* Reuse the existing mapping for the lowest-address LOAD */
 		if ((ph->p_vaddr & -PAGE_SIZE) == addr_min) continue;
 		this_min = ph->p_vaddr & -PAGE_SIZE;
@@ -651,7 +652,7 @@ static void find_map_range(Phdr *ph, size_t cnt, size_t stride, struct dso *p)
 {
 	size_t min_addr = -1, max_addr = 0;
 	for (; cnt--; ph = (void *)((char *)ph + stride)) {
-		if (ph->p_type != PT_LOAD) continue;
+		if (ph->p_type != PT_LOAD && ph->p_type != PT_ARM_EXIDX) continue;
 		if (ph->p_vaddr < min_addr)
 			min_addr = ph->p_vaddr;
 		if (ph->p_vaddr+ph->p_memsz > max_addr)
-- 
1.8.3.2

Re: [PATCH 3/3] [FYI] fix dynamic linker dso loading

[Rich Felker]

On Wed, Jul 10, 2013 at 04:39:01PM +0300, Timo Teräs wrote:
> The phdr entries need to be allocated from heap, so later calls
> to dl_iterate_phdr work properly. Make sure the ARM unwind info
> is not freed.

I am confused about the motivation for this patch. The program headers
are part of the mapping and are never freed.

> This is not exactly intended to be committed, but shows clearly
> what is wrong with the current implementation.

Not so clear. :)

> The reclamation fix should be probably something better, as I believe
> the same applies to GNU_EH_FRAME phdr.

It definitely does not apply to GNU_EH_FRAME.

Rich

Re: [PATCH 3/3] [FYI] fix dynamic linker dso loading

[Timo Teras]

On Wed, 10 Jul 2013 11:00:03 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Wed, Jul 10, 2013 at 04:39:01PM +0300, Timo Teräs wrote:
> > The phdr entries need to be allocated from heap, so later calls
> > to dl_iterate_phdr work properly. Make sure the ARM unwind info
> > is not freed.
> 
> I am confused about the motivation for this patch. The program headers
> are part of the mapping and are never freed.

static void *map_library(int fd, struct dso *dso)
{
	Ehdr buf[(896+sizeof(Ehdr))/sizeof(Ehdr)];
...
	ssize_t l = read(fd, buf, sizeof buf);
...
	ph = (void *)((char *)buf + eh->e_phoff);
...
	dso->phdr = ph;

So no, the program headers are not part of the mapping. At least they
are not setup that way currently.

Instead dso->phdr points to stack and gets messed up. That's why the:
-	dso->phdr = ph;
+	dso->phdr = malloc(phsize);
+	memcpy(dso->phdr, ph, phsize);

Perhaps the proper fix would be to map them instead then.

> > This is not exactly intended to be committed, but shows clearly
> > what is wrong with the current implementation.
> 
> Not so clear. :)

Hope the above explains the root problem.

> 
> > The reclamation fix should be probably something better, as I
> > believe the same applies to GNU_EH_FRAME phdr.
> 
> It definitely does not apply to GNU_EH_FRAME.

Seems I misunderstood in hurry what the reclaim_gaps really does.
Probably one of the reasons why it has the "huge hack" comment.. :)

I believe the "ph->p_type != PT_ARM_EXIDX" additions are not needed
after all.

- Timo

Re: [PATCH 3/3] [FYI] fix dynamic linker dso loading

[Richard Felker]

On Wed, Jul 10, 2013 at 06:47:25PM +0300, Timo Teras wrote:
> On Wed, 10 Jul 2013 11:00:03 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > On Wed, Jul 10, 2013 at 04:39:01PM +0300, Timo Teräs wrote:
> > > The phdr entries need to be allocated from heap, so later calls
> > > to dl_iterate_phdr work properly. Make sure the ARM unwind info
> > > is not freed.
> > 
> > I am confused about the motivation for this patch. The program headers
> > are part of the mapping and are never freed.
> 
> static void *map_library(int fd, struct dso *dso)
> {
> 	Ehdr buf[(896+sizeof(Ehdr))/sizeof(Ehdr)];
> ....
> 	ssize_t l = read(fd, buf, sizeof buf);
> ....
> 	ph = (void *)((char *)buf + eh->e_phoff);
> ....
> 	dso->phdr = ph;
> 
> So no, the program headers are not part of the mapping. At least they
> are not setup that way currently.

Indeed, this is purely my fault for failing to review this part of the
patch when it was committed. I was not aware that dso->phdr was being
pointed to the wrong memory; presumably it "happened to work" for some
tests I did at the time. I will fix it.

> Instead dso->phdr points to stack and gets messed up. That's why the:
> -	dso->phdr = ph;
> +	dso->phdr = malloc(phsize);
> +	memcpy(dso->phdr, ph, phsize);
> 
> Perhaps the proper fix would be to map them instead then.

They are already mapped anyway; the pointer into the right offset of
the map is just not setup.

> > > The reclamation fix should be probably something better, as I
> > > believe the same applies to GNU_EH_FRAME phdr.
> > 
> > It definitely does not apply to GNU_EH_FRAME.
> 
> Seems I misunderstood in hurry what the reclaim_gaps really does.
> Probably one of the reasons why it has the "huge hack" comment.. :)
> 
> I believe the "ph->p_type != PT_ARM_EXIDX" additions are not needed
> after all.

Indeed, all that's needed is the correct pointer value. I'll get a
patch committed soon that should fix the issue; please let me know if
other issues persist.

Rich

Re: [PATCH 2/3] Unwind support for ARM EABI

[Timo Teras]

On Wed, 10 Jul 2013 16:39:00 +0300
Timo Teräs <timo.teras@iki.fi> wrote:

> ARM EABI does not use the .eh_frame and .eh_frame_hdr for unwinding.
> Instead the ABI specifies it's own way to unwind using .ARM.exidx and
> .ARM.extab.
> 
> libgcc uses __gnu_Unwind_Find_exidx (libc must implement this) when
> unwinding using exidx. This function is implemented here.
> ---
>  arch/arm/src/find_exidx.c | 44
> ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44
> insertions(+) create mode 100644 arch/arm/src/find_exidx.c
> 
> diff --git a/arch/arm/src/find_exidx.c b/arch/arm/src/find_exidx.c
> new file mode 100644
> index 0000000..ffbea1f
> --- /dev/null
> +++ b/arch/arm/src/find_exidx.c
> @@ -0,0 +1,44 @@
> +#define _GNU_SOURCE
> +#include <link.h>
> +
> +typedef unsigned _Unwind_Ptr;

As noted on #musl, this has  __attribute__((pointer)) in the original
definition. But trying to avoid the #include <unwind.h> on GCC's
headers, and the GCCisms. 

Would uintptr_t be more suitable here then?

> +struct find_exidx_data {
> +	_Unwind_Ptr pc, exidx_start;
> +	int exidx_len;
> +};
> +
> +static int find_exidx(struct dl_phdr_info *info, size_t size, void
> *ptr) +{
> +	struct find_exidx_data *data = ptr;
> +	const ElfW(Phdr) *phdr = info->dlpi_phdr;
> +	_Unwind_Ptr addr;
> +	int match = 0, i;
> +
> +	for (i = info->dlpi_phnum; i > 0; i--, phdr++) {
> +		addr = info->dlpi_addr + phdr->p_vaddr;
> +		switch (phdr->p_type) {
> +		case PT_LOAD:
> +			match |= data->pc >= addr && data->pc < addr
> + phdr->p_memsz;
> +			break;
> +		case PT_ARM_EXIDX:
> +			data->exidx_start = addr;
> +			data->exidx_len = phdr->p_memsz;
> +			break;
> +		}
> +	}
> +	return match;
> +}

The above function has a slight bug in it, so I'll fix that for next
send. Basically it can return other dso's exidx data if the matching
dso did not have PT_ARM_EXIDX at all.

- Timo

Re: Re: [PATCH 2/3] Unwind support for ARM EABI

[Rich Felker]

On Wed, Jul 10, 2013 at 08:35:18PM +0300, Timo Teras wrote:
> > diff --git a/arch/arm/src/find_exidx.c b/arch/arm/src/find_exidx.c
> > new file mode 100644
> > index 0000000..ffbea1f
> > --- /dev/null
> > +++ b/arch/arm/src/find_exidx.c
> > @@ -0,0 +1,44 @@
> > +#define _GNU_SOURCE
> > +#include <link.h>
> > +
> > +typedef unsigned _Unwind_Ptr;
> 
> As noted on #musl, this has  __attribute__((pointer)) in the original
> definition. But trying to avoid the #include <unwind.h> on GCC's
> headers, and the GCCisms. 
> 
> Would uintptr_t be more suitable here then?

Yes. unsigned "works" but only because this code is ARM-specific and
ARM is 32-bit.

> > +struct find_exidx_data {
> > +	_Unwind_Ptr pc, exidx_start;
> > +	int exidx_len;
> > +};
> > +
> > +static int find_exidx(struct dl_phdr_info *info, size_t size, void
> > *ptr) +{
> > +	struct find_exidx_data *data = ptr;
> > +	const ElfW(Phdr) *phdr = info->dlpi_phdr;
> > +	_Unwind_Ptr addr;
> > +	int match = 0, i;
> > +
> > +	for (i = info->dlpi_phnum; i > 0; i--, phdr++) {
> > +		addr = info->dlpi_addr + phdr->p_vaddr;
> > +		switch (phdr->p_type) {
> > +		case PT_LOAD:
> > +			match |= data->pc >= addr && data->pc < addr
> > + phdr->p_memsz;
> > +			break;
> > +		case PT_ARM_EXIDX:
> > +			data->exidx_start = addr;
> > +			data->exidx_len = phdr->p_memsz;
> > +			break;
> > +		}
> > +	}
> > +	return match;
> > +}
> 
> The above function has a slight bug in it, so I'll fix that for next
> send. Basically it can return other dso's exidx data if the matching
> dso did not have PT_ARM_EXIDX at all.

OK, I'll wait for your next version of this patch.

Rich

[PATCH v2] Unwind support for ARM EABI

[Timo Teräs]

ARM EABI does not use the .eh_frame and .eh_frame_hdr for unwinding.
Instead the ABI specifies it's own way to unwind using .ARM.exidx and
.ARM.extab.

libgcc uses __gnu_Unwind_Find_exidx (libc must implement this) when
unwinding using exidx. This function is implemented here.
---
 arch/arm/src/find_exidx.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 arch/arm/src/find_exidx.c

diff --git a/arch/arm/src/find_exidx.c b/arch/arm/src/find_exidx.c
new file mode 100644
index 0000000..8ba9f30
--- /dev/null
+++ b/arch/arm/src/find_exidx.c
@@ -0,0 +1,46 @@
+#define _GNU_SOURCE
+#include <link.h>
+#include <stdint.h>
+
+typedef uintptr_t _Unwind_Ptr;
+
+struct find_exidx_data {
+	_Unwind_Ptr pc, exidx_start;
+	int exidx_len;
+};
+
+static int find_exidx(struct dl_phdr_info *info, size_t size, void *ptr)
+{
+	struct find_exidx_data *data = ptr;
+	const ElfW(Phdr) *phdr = info->dlpi_phdr;
+	_Unwind_Ptr addr, exidx_start = 0;
+	int i, match = 0, exidx_len = 0;
+
+	for (i = info->dlpi_phnum; i > 0; i--, phdr++) {
+		addr = info->dlpi_addr + phdr->p_vaddr;
+		switch (phdr->p_type) {
+		case PT_LOAD:
+			match |= data->pc >= addr && data->pc < addr + phdr->p_memsz;
+			break;
+		case PT_ARM_EXIDX:
+			exidx_start = addr;
+			exidx_len = phdr->p_memsz;
+			break;
+		}
+	}
+	if (match) {
+		data->exidx_start = exidx_start;
+		data->exidx_len = exidx_len;
+	}
+	return match;
+}
+
+_Unwind_Ptr __gnu_Unwind_Find_exidx(_Unwind_Ptr pc, int *pcount)
+{
+	struct find_exidx_data data;
+	data.pc = pc;
+	if (dl_iterate_phdr(find_exidx, &data) <= 0)
+		return 0;
+	*pcount = data.exidx_len / 8;
+	return data.exidx_start;
+}
-- 
1.8.3.2

Re: [PATCH 1/3] PIE support for arm (copyright...)

[Isaac]

On Wed, Jul 10, 2013 at 04:38:59PM +0300, Timo Ter??s wrote:
> ---
> Originally based on the glibc's implementation, but as this is
> very short function (of which only maybe 10 lines are from the
> original work), and the rest is modified to suit musl. I believe
> we could just place on public domain.

(Disclaimer: IANAL)

Ick. Don't do that.
At least, not without review from a regular glibc contributor/maintainer, 
Eben Moglen, the author, or another authority who could state that it is
the FSF's position that this does not infringe.

While it seems minimal, there are other considerations:
(0) If a court disagrees and rules that it is copyright infringement, 
what happens?

(1) If it gets publicized, the potential for FUD is huge.

(2) Even if it's fair use/de minimis, there is still a risk of legal action.
And that alone is a big problem.
In fact, the perception of a risk is a problem.
Isaac Dunham.

> 
>  crt/arm/Scrt1.s | 34 ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>  create mode 100644 crt/arm/Scrt1.s

Re: [PATCH 1/3] PIE support for arm (copyright...)

[Rich Felker]

On Wed, Jul 10, 2013 at 12:23:29PM -0700, Isaac wrote:
> On Wed, Jul 10, 2013 at 04:38:59PM +0300, Timo Ter??s wrote:
> > ---
> > Originally based on the glibc's implementation, but as this is
> > very short function (of which only maybe 10 lines are from the
> > original work), and the rest is modified to suit musl. I believe
> > we could just place on public domain.
> 
> (Disclaimer: IANAL)
> 
> Ick. Don't do that.
> At least, not without review from a regular glibc contributor/maintainer, 
> Eben Moglen, the author, or another authority who could state that it is
> the FSF's position that this does not infringe.
> 
> While it seems minimal, there are other considerations:
> (0) If a court disagrees and rules that it is copyright infringement, 
> what happens?
> 
> (1) If it gets publicized, the potential for FUD is huge.
> 
> (2) Even if it's fair use/de minimis, there is still a risk of legal action.
> And that alone is a big problem.
> In fact, the perception of a risk is a problem.

Agreed. There is no reason to even look at, much less copy, glibc code
to do this. All that's needed for Scrt1.s is to make crt1.s
position-independent.

Rich

[PATCH v3] Unwind support for ARM EABI

[Timo Teräs]

ARM EABI does not use the .eh_frame and .eh_frame_hdr for unwinding.
Instead the ABI specifies it's own way to unwind using .ARM.exidx and
.ARM.extab.

libgcc uses __gnu_Unwind_Find_exidx (libc must implement this) when
unwinding using exidx. This function is implemented here.
---
v3 changes per discussion at #musl:
- removed Unwind_Ptr (using uintptr_t directly)
- removed the redundant "if (match)" for data->exidx_* assignment

 arch/arm/src/find_exidx.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 arch/arm/src/find_exidx.c

diff --git a/arch/arm/src/find_exidx.c b/arch/arm/src/find_exidx.c
new file mode 100644
index 0000000..77c4472
--- /dev/null
+++ b/arch/arm/src/find_exidx.c
@@ -0,0 +1,42 @@
+#define _GNU_SOURCE
+#include <link.h>
+#include <stdint.h>
+
+struct find_exidx_data {
+	uintptr_t pc, exidx_start;
+	int exidx_len;
+};
+
+static int find_exidx(struct dl_phdr_info *info, size_t size, void *ptr)
+{
+	struct find_exidx_data *data = ptr;
+	const ElfW(Phdr) *phdr = info->dlpi_phdr;
+	uintptr_t addr, exidx_start = 0;
+	int i, match = 0, exidx_len = 0;
+
+	for (i = info->dlpi_phnum; i > 0; i--, phdr++) {
+		addr = info->dlpi_addr + phdr->p_vaddr;
+		switch (phdr->p_type) {
+		case PT_LOAD:
+			match |= data->pc >= addr && data->pc < addr + phdr->p_memsz;
+			break;
+		case PT_ARM_EXIDX:
+			exidx_start = addr;
+			exidx_len = phdr->p_memsz;
+			break;
+		}
+	}
+	data->exidx_start = exidx_start;
+	data->exidx_len = exidx_len;
+	return match;
+}
+
+uintptr_t __gnu_Unwind_Find_exidx(uintptr_t pc, int *pcount)
+{
+	struct find_exidx_data data;
+	data.pc = pc;
+	if (dl_iterate_phdr(find_exidx, &data) <= 0)
+		return 0;
+	*pcount = data.exidx_len / 8;
+	return data.exidx_start;
+}
-- 
1.8.3.2

Re: [PATCH 1/3] PIE support for arm (copyright...)

[Rich Felker]

On Wed, Jul 10, 2013 at 03:28:44PM -0400, Rich Felker wrote:
> On Wed, Jul 10, 2013 at 12:23:29PM -0700, Isaac wrote:
> > On Wed, Jul 10, 2013 at 04:38:59PM +0300, Timo Ter??s wrote:
> > > ---
> > > Originally based on the glibc's implementation, but as this is
> > > very short function (of which only maybe 10 lines are from the
> > > original work), and the rest is modified to suit musl. I believe
> > > we could just place on public domain.
> > 
> > (Disclaimer: IANAL)
> > 
> > Ick. Don't do that.
> > At least, not without review from a regular glibc contributor/maintainer, 
> > Eben Moglen, the author, or another authority who could state that it is
> > the FSF's position that this does not infringe.
> > 
> > While it seems minimal, there are other considerations:
> > (0) If a court disagrees and rules that it is copyright infringement, 
> > what happens?
> > 
> > (1) If it gets publicized, the potential for FUD is huge.
> > 
> > (2) Even if it's fair use/de minimis, there is still a risk of legal action.
> > And that alone is a big problem.
> > In fact, the perception of a risk is a problem.
> 
> Agreed. There is no reason to even look at, much less copy, glibc code
> to do this. All that's needed for Scrt1.s is to make crt1.s
> position-independent.

I just wrote and committed my own Scrt1.s; it seems to be working. I
believe the approach is slightly different, avoiding GOT slots for
symbols which must be defined in the main program. (Note that main
need not be defined in the main program; it can be defined in a shared
library!)

Rich