[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] malloc bug ?

From: Joerg Wunsch
Subject: Re: [avr-libc-dev] malloc bug ?
Date: Mon, 9 Sep 2002 14:03:04 +0200
User-agent: Mutt/1.2.5i

As ken restivo wrote:

> SP doesn't seem to work.  Maybe __SP__ instead?

No such thing like __SP__.  There's __SP_L__ and __SP_H__, but only in
the generated assembler code, that's not usable within C code.

> Just manually changing STACK_POINTER to 0x5d seems to work just
> fine.

Sure, that's in effect what the _SFR_IO16() macro in <avr/sfr_defs.h>
is doing.

I also gave it a try, and my only project using dynamic memory still
works.  (It worked before, probably because subtracting
__malloc_margin's value of 32 from a small positive integer in the
EEPROM data register yielded a negative number, which was then cast to
a large unsigned number so it always assumed enough heap was
available. ;-)

Just for the sake of completeness (and since we've got CVS that can
keep track of these things), i've imported my original version of
malloc.c onto a vendor branch for comparision purposes.  This one was
still using port input operations to obtain the current stack pointer

Since the bug was serious, i just committed a fix for it wrapping
the magic number 0x3D into _SFR_IO16().  We should agree on a better
solution wrt. not hard-coding register numbers in those files though.
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]