New "portable" crt1.c

New "portable" crt1.c

[Rich Felker]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

Hi all,

I've been experimenting with an idea for eliminating most of the asm
from the "crt" start files. The basic concept is to have a tiny
file-scope __asm__ statement, pulled in from arch/$(ARCH)/crt1.h or
similar, which does nothing but calling a portable C version of
_start, contained in crt1.c, with the right arguments.

The benefits:
- We get regular (crt1.o) and PIE (Scrt1.o) versions for free.
- Porting to new archs is simpler.
- Applying the same technique to crti.o/crtn.o, we can support the
  new-style init_array/fini_array on all archs without lots of new
  per-arch asm.

Attached is a demo for i386 showing how well this approach works (size
increase is less than 16 bytes).

I'm open to comments, but my feeling is that we should keep the
existing crt asm for archs where it already exists, but replace the
empty crt1.c with a version based on this approach, and encourage
using the new approach on all new ports. In the future, if maintaining
the current asm becomes a burden (e.g. if new requirements are
introduced) we could remove the existing asm and switch to the C for
all ports.

Rich

[-- Attachment #2: newcrt.c --]
[-- Type: text/plain, Size: 621 bytes --]

__asm__("\
.global _start\n\
_start:\n\
	xor %ebp,%ebp\n\
	mov %esp,%eax\n\
	and $-16,%esp\n\
	push %eax\n\
	push %eax\n\
	push %edx\n\
	push %eax\n\
	call ___start\n\
");

__attribute__((__noreturn__)) int __libc_start_main(
	int (*)(int, char **, char **), int, char **,
	int (*)(int, char **, char **), void (*)(void),
	void (*)(void));

int main();
int _init() __attribute__((__weak__,__visibility__("hidden")));
void _fini() __attribute__((__weak__,__visibility__("hidden")));

void ___start(long *p, void *q)
{
	int argc = p[0];
	char **argv = (void *)p[1];
	__libc_start_main(main, argc, argv, _init, _fini, q);
}

Re: New "portable" crt1.c

[Rob Landley]

On 07/18/2013 09:17:26 PM, Rich Felker wrote:
> I'm open to comments, but my feeling is that we should keep the
> existing crt asm for archs where it already exists, but replace the
> empty crt1.c with a version based on this approach, and encourage
> using the new approach on all new ports. In the future, if maintaining
> the current asm becomes a burden (e.g. if new requirements are
> introduced) we could remove the existing asm and switch to the C for
> all ports.

The wiki page on porting to new architectures needs some updating. :)

> Rich

Rob

Re: New "portable" crt1.c

[Rich Felker]

On Thu, Jul 25, 2013 at 02:38:08AM -0500, Rob Landley wrote:
> On 07/18/2013 09:17:26 PM, Rich Felker wrote:
> >I'm open to comments, but my feeling is that we should keep the
> >existing crt asm for archs where it already exists, but replace the
> >empty crt1.c with a version based on this approach, and encourage
> >using the new approach on all new ports. In the future, if maintaining
> >the current asm becomes a burden (e.g. if new requirements are
> >introduced) we could remove the existing asm and switch to the C for
> >all ports.
> 
> The wiki page on porting to new architectures needs some updating. :)

Well I have to actually finish and add it first.

Rich