argv dereference in crt1.S for m68k

Rick Garcia rick at liveoaklogic.com
Thu Nov 16 18:56:04 UTC 2006


I'm looking at the CVS version of uClibc/libc/sysdeps/linux/m68k/crt1.S 
for all this.

...working on a m68knommu system :

I noticed this with static binaries (no shared libs) - on 2.4.31 
uClinux.  When I execute an app, the stack looks like this upon hitting 
_start :

%sp : argc
%sp(4) : argv[0]
...
%sp(argc): null
%sp(argc+1): environ

so when crt1.S starts the stack preparation for __uClibc_main() :
...
	/* Extract the arguments as encoded on the stack and set up the
	   arguments for `main': argc, argv.  envp will be determined
	   later in __libc_start_main.  */
	move.l (%sp)+, %d0	/* Pop the argument count.  */
#ifndef __ARCH_USE_MMU__
	move.l (%sp)+, %a0
#else
	move.l %sp, %a0		/* The argument vector starts just at the
				   current stack top.  */
#endif
...

since I'm not using mmu, it gives me the first line - dereference argv 
and put it in a0 for later.  But my setup has the vector starting at the 
stack top - so I needed to flip the #ifdef, and use the other move.l to 
get argv correctly setup.


and further down :
...
#ifndef __ARCH_USE_MMU__
	clr.l -(%sp)
#else
	pea (%a1)		/* Push address of the shared library
				   termination function.  */
#endif
...

This works correctly on my system, but isn't this a shared/unshared 
issue, not an MMU/noMMU issue?  For m68k, the %a1 may or may not have 
the shared library termination function on it, and this should be 
dependent on whether or not the libs are shared.  Granted, this will 
coincide with !defined(__ARCH_USE_MMU__) quite often - but shouldn't it 
be changed to:

#ifndef __HAVE_SHARED__
	clr.l -(%sp)
#else...
to clear the termination function pointer for static apps?

I have this stuff working on my system right now; I don't have an mmu 
system to test this against, so it might be that my stack is already 
messed up when it gets passed in to _start. (In which case I need to fix 
that, wherever it is.)  In my understanding tho, both these items are 
dependent on whether the libraries are shared, not the mmu/nommu status.

-- 
  - Rick Garcia
  Live Oak Logic



More information about the uClibc mailing list