[uClibc]Compiling kaffe with uClibc for arm-linux

[Matthew Bloch]

Hello there;

I'm trying to sort out a couple of small compilation problems that have
kept me busy the last couple of hours when compiling kaffe.  It all goes
fine apart from two issues (well, three, but I've not looked at that yet):

1) The ARM build of uClibc doesn't have a wrapper for sbrk or brk -- I'm
not overly familiar with the syscall convention for ARMLinux, so while I
get the other problems sorted out, can anyone advise me as to whether
these additions to the system-dependent part of the library would be
suitable?  I've based them heavily on existing code and guesswork, so
hopefully I've not gone too far wrong:

----------- uClibc/libc/sysdeps/linux/arm/brk.S --------------------
#include <asm/errno.h>
#include <asm/unistd.h>

.global errno;
.global ___brk_addr;

.text
.global brk;
.type brk,#function
.align 4;                                                               \

___brk_addr:

brk:
	stmfd		r13!, {r0}   /* stash value of new  limit... */
	swi		__NR_brk     /* do the call (assume r0 is set right) */
	ldmfd		r13!, {r1}   /* ...unstash it... */
	cmp		r0, #0       /* check for error*/
	ldreq		r3, .L5      /* load (relative?) addr of ___brk_addr */
	streq		r1, [r9, r3] /* ...store new limit in
                                      *  ___brk_addr for sbrk to use
                                      */
	movlt		pc, lr       /* exit without error if r0=0 */
	ldr		r1, =-ENOMEM /* load error code into r1 */
	ldr		r3, .L4      /* load address of errno */
	str		r1, [r9, r3] /* store correct error in errno */
	mvn		r0, #0
	mov		pc, lr       /* return with r0=-1 */

.L4:  .word errno
.L5:  .word ___brk_addr
----------- uClibc/libc/sysdeps/linux/arm/sbrk.c -------------------
#include <unistd.h>
#include <errno.h>

void *___brk_addr = 0;

extern int brk (void *addr);

/* Extend the process's data space by INCREMENT.
   If INCREMENT is negative, shrink data space by - INCREMENT.
   Return start of new space allocated, or -1 for errors.  */
void * sbrk (intptr_t increment)
{
  void *oldbrk;

  if (___brk_addr == NULL)
    if (brk (0) < 0)		/* Initialize the break.  */
      return (void *) -1;

  if (increment == 0)
    return ___brk_addr;

  oldbrk = ___brk_addr;
  if (brk (oldbrk + increment) < 0)
    return (void *) -1;

  return oldbrk;
}
--------------------------------------------------------------------

I'm sure I can work that one out for myself eventually, but if it's
obvious to somebody what should happen in this case, I'd appreciate a
pointer so I could make this into a proper patch.

2) When compiling kaffe's math library (soft.c), there seems to be a
definition problem with the isinf symbol.  I've set the DO_C99_MATH symbol
to 'true' when building the library, but when the program code #includes
math.h (and I've checked it's picking up the right one etc. with gcc -E)
there appears to be two definitions of isinf available: a function
prototype and a macro.  I cannot find the function definition anywhere in
the code, and assume that since this is a header lifted from glibc, it is
dependent on the __USE_ISOC99 macro being set to use the macro instead of
the function prototype.  However no matter how hard I try, I can't get the
uClibc math.h to build to provide the macro rather than the prototype, the
result being a lot of linking errors for the 'isinf' symbol.  If I try to
bodge it and insert a quick '#define __USE_ISOC99 1' at the top of math.h,
I get linking errors for the __isinf symbol, which I presume is necessary
for the macro to work correctly.  I can't find this symbol defined in the
source code either!  Presumably there is some proper setting of this macro
that is the responsibility of gcc, the library build and maybe even kaffe
but I'm not sure where the inconsistency has happened to cause this build
problem.  So is there somebody who knows the ins and outs of how this is
meant to compile who can advise me?

I'll keep hacking at both of these problems tomorrow (bedtime now) but if
someone can give me a helping shove I'll be very grateful.

thanks,

-- 
Matthew       > http://www.soup-kitchen.net/
              > ICQ 19482073