Stefan Reinauer <[EMAIL PROTECTED]> writes:
> * Jake Page <[EMAIL PROTECTED]> [020724 09:41]:
> >
> > Hey,
> >
> > I'm compiling LinuxBIOS for the Matsonic MS7308E and having a problem with
> > the image generated using gcc 3.1 ( & binutils 2.12.1). Before I try to
> > track this down, is this a known issue? An image built w/ 2.95.3 works
> > fine... (at this point I haven't *completely* narrowed it down to the
> > compiler, but I am using my own compiler toolchain w/ my own build
> > of gcc 2.95.3 & gcc 3.1, etc so there aren't that many other variables...)
> > LinusBIOS CVS version in this test was from ~ June 12, but a newer CVS
> > tree didn't help.
> >
> > The error I am seeing is:
> >
> > LinuxBIOS starting...
> > Ram Initialize?
> > LinuxBIOS booting...
> > Finding PCI configuration type.
> > PCI: Using configuration type 1
> > handle_superio start, s 00080524 nsuperio 0 s->super 00000000
> > handle_superio done
> > Scanning PCI bus...PCI: pci_scan_bus for bus 0
> > Error! malloc: Free_mem_ptr >= free_mem_end_ptr
>
> Same problem as I had. Old binutils helped. The binary has some
> weird offset bugs, so the end of free memory is always assumed to be
> 0
The bug is fairly localizable, I am running a working version of 2.12..
ld --version
GNU ld version 2.12.90.0.9 20020526
Which means the linux specific binutils releases (available at kerenel.org)
work.
For the most part I have avoided the newer compiler releases because they
have a real tendency to generate larger code. Hopefully as the other issues
stabalize out this will be one of the things I can get done.
For those looking at binutils issues, another fun one is that some versions
of as in 2.11 && 2.12 have the bad tendency of adding junk to the end of
the text section. This doesn't require a final link just to assemble some
source code. 2.12.90.0.9 doesn't suffer this defect so I believe it is now
fixed.
Hmm. Actually it looking at the binary I am reproducing it.
I wonder if this code also triggers a compiler bug in older compilers,
which covers up the linker bug. Yuck!
I will look into this a little more tommorrow, but I believe
an easy fix is to move the symbols _heap && _eheap outside of
their respective sections. And to file a bug report against binutils.
Transform (src/arch/i386/config/ldscript.base):
.heap {
_heap = .;
. = HEAP_SIZE;
_eheap = .;
}
to:
_heap = .;
.heap {
. = HEAP_SIZE;
}
_eheap = .;
I looked at this earlier in another context, it appears the linker has
problems assigning addresses in bss like sections it does not allocate.
Now what the compiler bug in older compilers is that covers this up
still a mystery.
Eric
