[uClibc]Problem in comments regarding crt0.s

AVENARD,JEAN-YVES (HP-Australia,ex2) jean-yves_avenard at hp.com
Thu Feb 8 06:55:28 UTC 2001


Dear all.

This is not so important but as I'm trying to port the uClibc to SH
platform, I've encountered the following inconsistency.

In both i386 and arm platform, the documentation for crt0.s and the
structure of the stack at the start of a program is:

"/*
    When we enter this piece of code, the program stack looks like this:
        argc            argument counter (integer)
        argv[0]         program name (pointer)
        argv[1...N]     program args (pointers)
        argv[argc-1]    end of args (integer)
        env[0...N]      environment variables (pointers)
        NULL
*/"

Based on this diagram, 
env = argv + argc * 4 (on 32 bits machine)

But, in both arm and Intel they do:
Arm:
	ldr     a4, .L3
	add     a3, a2, a1, lsl #2
	add     a3, a3, #4

Intel:
	movl %esp,%ebx  /* Store argv into ebx */
	movl %esp,%eax  /* Store argv into eax as well*/
	movl %ecx,%edx	/* Stick argc into %edx so we can do some math in a
sec */
	leal 4(%eax,%edx,4),%eax

Which is
env = argv + argc * 4 + 4. Or to simplify: env=(argc+1)*4+argv=&argv[argc+1]

In start.S (equivalent to crt0.S) in the glibc library, the stack diagram is
as follow:
   		0(sp)			argc
		4(sp)			argv[0]
		...
		(4*argc)(sp)		NULL
		(4*(argc+1))(sp)	envp[0]
		...
					NULL

Which is also confirmed by the little program:
main(int argc, void **argv, void **envp)
{
printf("argc=%d argv=%x envp=%x argv[argc]=%x",argc,argv,envp,argv[argc]);
}

>gcc x.c -o x
>./x

This will print (I'm using 0 for the address to make things easier):
argc=1 argv=0 envp=8 argv[argc]=0

Which confirms that between the arguments and the environment variables
there is a NULL pointer.

Knowing that both the arm and i386 crt0.S are doing the right calculation
but incorrectly comment is, shouldn't it be better to update the
documentation?. The wierd thing is that the m68k version doesn't care at all
about envp, does that mean that it's not supported by uCLibc on 68K
architecture ??

In any case, if you think I'm mistaking, thank you for telling me where I'm
wrong.

Thank you very much
Best regards
Jean-Yves







More information about the uClibc mailing list