* [U-Boot-Users] Bug in malloc()?
@ 2007-10-25 22:35 Timur Tabi
2007-10-26 11:34 ` Jerry Van Baren
0 siblings, 1 reply; 25+ messages in thread
From: Timur Tabi @ 2007-10-25 22:35 UTC (permalink / raw)
To: u-boot
I'm trying to get the very latest U-Boot running on an MPC8323E MDS, and U-Boot
hangs in the code to initialize the environment. Specifically, env_relocate()
calls malloc(), but malloc() never returns.
Before I try to debug the malloc() code, I was hoping someone would have a clue
as to what the problem is.
I put a bunch of printfs() in the malloc() code, as well as a sanity check:
for (victim = last(bin); victim != bin; victim = victim->bk)
{
printf("%s:%u victim=%p\n", __FILE__, __LINE__, victim);
victim_size = chunksize(victim);
printf("%s:%u victim_size=%u nb=%u\n", __FILE__, __LINE__, victim_size, nb);
if (victim_size > max_total_mem) {
printf("%s:%u\n", __FILE__, __LINE__);
return 0;
}
remainder_size = victim_size - nb;
printf("%s:%u remainder_size=%u\n", __FILE__, __LINE__, remainder_size);
if (remainder_size >= (long)MINSIZE) /* too big */
{
printf("%s:%u\n", __FILE__, __LINE__);
--idx; /* adjust to rescan below after checking last remainder */
break;
}
else if (remainder_size >= 0) /* exact fit */
{
printf("%s:%u\n", __FILE__, __LINE__);
unlink(victim, bck, fwd);
set_inuse_bit_at_offset(victim, victim_size);
check_malloced_chunk(victim, nb);
printf("%s:%u\n", __FILE__, __LINE__);
return chunk2mem(victim);
}
printf("%s:%u\n", __FILE__, __LINE__);
}
and I get this:
dlmalloc.c:2153
dlmalloc.c:2158
dlmalloc.c:2192
dlmalloc.c:2198 victim=fe02d138
dlmalloc.c:2200 victim_size=4261597488 nb=8200
dlmalloc.c:2202
env_relocate[217] malloced ENV at 00000000
Look at the value of victim_size. This can't be right.
Without the "if (victim_size > max_total_mem)" sanity check, this code loops
indefinitely.
Can anyone tell me what's going on? I don't think there's a bug in malloc() per
se, but something has corrupted the heap. What could do that?
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-25 22:35 [U-Boot-Users] Bug in malloc()? Timur Tabi
@ 2007-10-26 11:34 ` Jerry Van Baren
2007-10-26 14:20 ` Rune Torgersen
0 siblings, 1 reply; 25+ messages in thread
From: Jerry Van Baren @ 2007-10-26 11:34 UTC (permalink / raw)
To: u-boot
Timur Tabi wrote:
> I'm trying to get the very latest U-Boot running on an MPC8323E MDS, and U-Boot
> hangs in the code to initialize the environment. Specifically, env_relocate()
> calls malloc(), but malloc() never returns.
>
> Before I try to debug the malloc() code, I was hoping someone would have a clue
> as to what the problem is.
Sounds a lot like what Rune Torgersen was finding with the mpc8260 family.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32645/focus=32645
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32740
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/32752/focus=32752
gvb
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 11:34 ` Jerry Van Baren
@ 2007-10-26 14:20 ` Rune Torgersen
2007-10-26 14:27 ` Timur Tabi
0 siblings, 1 reply; 25+ messages in thread
From: Rune Torgersen @ 2007-10-26 14:20 UTC (permalink / raw)
To: u-boot
> From: Jerry Van Baren
>
> Timur Tabi wrote:
> > I'm trying to get the very latest U-Boot running on an MPC8323E MDS,
and U-Boot
> > hangs in the code to initialize the environment. Specifically,
env_relocate()
> > calls malloc(), but malloc() never returns.
>
> Sounds a lot like what Rune Torgersen was finding with the
> mpc8260 family.
>
It is excactly what I ran into also.
Im my case it turns out that the new relocation code fixups does not
work.
I could get malloc to work , but then afterwards, none of the command
line commands would work as they were not properly relocated either.
I had to disable CONFIG_RELOC_FIXUP_WORKS in include/common.h for my CPU
to get it to work.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 14:20 ` Rune Torgersen
@ 2007-10-26 14:27 ` Timur Tabi
2007-10-26 14:41 ` Rune Torgersen
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Timur Tabi @ 2007-10-26 14:27 UTC (permalink / raw)
To: u-boot
Rune Torgersen wrote:
> It is excactly what I ran into also.
Something tells me that a lot of 83xx and 82xx platforms are broken.
> Im my case it turns out that the new relocation code fixups does not
> work.
> I could get malloc to work , but then afterwards, none of the command
> line commands would work as they were not properly relocated either.
Just to be clear, backing out f82b3b6304b620ef7e28bfaa1ea887a2ad2fa325
and e9514751cfa5cce61ea699fa0d3eb37898a5eeb5 makes malloc work, but breaks the
command line?
> I had to disable CONFIG_RELOC_FIXUP_WORKS in include/common.h for my CPU
> to get it to work.
Does disabling that make everything work?
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 14:27 ` Timur Tabi
@ 2007-10-26 14:41 ` Rune Torgersen
2007-10-26 14:45 ` Rune Torgersen
2007-10-26 15:04 ` Rune Torgersen
2 siblings, 0 replies; 25+ messages in thread
From: Rune Torgersen @ 2007-10-26 14:41 UTC (permalink / raw)
To: u-boot
> From: Timur Tabi [mailto:timur at freescale.com]
> Just to be clear, backing out f82b3b6304b620ef7e28bfaa1ea887a2ad2fa325
> and e9514751cfa5cce61ea699fa0d3eb37898a5eeb5 makes malloc
> work, but breaks the
> command line?
I think both will work, because one of those commits sets gd->reloc_off
to 0 and that is what breaks everything.
I need try ry it again to make sure.
>
>> I had to disable CONFIG_RELOC_FIXUP_WORKS in
>> include/common.h for my CPU
>> to get it to work.
>
> Does disabling that make everything work?
Yes, as far as I can tell. I could successfully download and run a
kernel uImage.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 14:27 ` Timur Tabi
2007-10-26 14:41 ` Rune Torgersen
@ 2007-10-26 14:45 ` Rune Torgersen
2007-10-26 15:01 ` Timur Tabi
2007-10-26 22:18 ` Timur Tabi
2007-10-26 15:04 ` Rune Torgersen
2 siblings, 2 replies; 25+ messages in thread
From: Rune Torgersen @ 2007-10-26 14:45 UTC (permalink / raw)
To: u-boot
> From: Timur Tabi [mailto:timur at freescale.com]
> Something tells me that a lot of 83xx and 82xx platforms are broken.
I would think ALL of them are broken. Probably also some of the other
PPC platforms.
Some must be working, (probably 85xx and 440, based in some of the
commit messages)
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 14:45 ` Rune Torgersen
@ 2007-10-26 15:01 ` Timur Tabi
[not found] ` <DCEAAC0833DD314AB0B58112AD99B93B038A2914@ismail.innsys.innovsys.com>
2007-10-26 22:18 ` Timur Tabi
1 sibling, 1 reply; 25+ messages in thread
From: Timur Tabi @ 2007-10-26 15:01 UTC (permalink / raw)
To: u-boot
Rune Torgersen wrote:
>> From: Timur Tabi [mailto:timur at freescale.com]
>> Something tells me that a lot of 83xx and 82xx platforms are broken.
>
> I would think ALL of them are broken. Probably also some of the other
> PPC platforms.
> Some must be working, (probably 85xx and 440, based in some of the
> commit messages)
I just got a report that 8568 works.
I think the problem may come from mem_malloc_init(). I'm debugging that right
now. It's possible that the heap data structures are being located (partially)
in flash, and that's causing them to have invalid values.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 14:27 ` Timur Tabi
2007-10-26 14:41 ` Rune Torgersen
2007-10-26 14:45 ` Rune Torgersen
@ 2007-10-26 15:04 ` Rune Torgersen
2 siblings, 0 replies; 25+ messages in thread
From: Rune Torgersen @ 2007-10-26 15:04 UTC (permalink / raw)
To: u-boot
> From: Timur Tabi [mailto:timur at freescale.com]
> Just to be clear, backing out f82b3b6304b620ef7e28bfaa1ea887a2ad2fa325
> and e9514751cfa5cce61ea699fa0d3eb37898a5eeb5 makes malloc
> work, but breaks the
> command line?
Backing out those two commits makes everything work (including command
line)
(tested with 1.3.0-rc3-g849ab532-dirty)
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
[not found] ` <47220576.2080700@freescale.com>
@ 2007-10-26 15:23 ` Rune Torgersen
0 siblings, 0 replies; 25+ messages in thread
From: Rune Torgersen @ 2007-10-26 15:23 UTC (permalink / raw)
To: u-boot
> From: Timur Tabi [mailto:timur at freescale.com]
> > BTW: I looked at the differences in 8568's u-boot.lds and
> 8260 uboot.lds
> > There is a missing (*.fixup) in the .text segment.
>
> Is it missing from the 8568 lds or the 8260 lds?
8260 lds.
There are a lot of differences:
8568mds lds file, .text segment
.text :
{
cpu/mpc85xx/start.o (.text)
board/mpc8568mds/init.o (.text)
cpu/mpc85xx/traps.o (.text)
cpu/mpc85xx/interrupts.o (.text)
cpu/mpc85xx/cpu_init.o (.text)
cpu/mpc85xx/cpu.o (.text)
cpu/mpc85xx/speed.o (.text)
cpu/mpc85xx/pci.o (.text)
common/dlmalloc.o (.text)
lib_generic/crc32.o (.text)
lib_ppc/extable.o (.text)
lib_generic/zlib.o (.text)
*(.text)
*(.fixup)
*(.got1)
}
_etext = .;
PROVIDE (etext = .);
.rodata :
{
*(.rodata)
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
}
8260 lds file .text segment
.text :
{
cpu/mpc8260/start.o (.text)
*(.text)
*(.got1)
. = ALIGN(16);
*(.rodata)
*(.rodata1)
*(.rodata.str1.4)
*(.eh_frame)
}
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
[not found] ` <DCEAAC0833DD314AB0B58112AD99B93B038A2914@ismail.innsys.innovsys.com>
[not found] ` <472203F8.3030800@freescale.com>
@ 2007-10-26 16:56 ` Timur Tabi
1 sibling, 0 replies; 25+ messages in thread
From: Timur Tabi @ 2007-10-26 16:56 UTC (permalink / raw)
To: u-boot
Rune Torgersen wrote:
> The heap data structure gets filled in by the compiler on compile time,
> and it puts its next/prev pointers to point to flash.
> malloc_bin_reloc() normally takes care of this, but since gd->reloc_off
> is 0, they stay in flash.
Ah, I get it now.
I've been talking to Grant on IRC. I have some things I can try to narrow down
the problem.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 14:45 ` Rune Torgersen
2007-10-26 15:01 ` Timur Tabi
@ 2007-10-26 22:18 ` Timur Tabi
2007-10-26 22:27 ` Grant Likely
1 sibling, 1 reply; 25+ messages in thread
From: Timur Tabi @ 2007-10-26 22:18 UTC (permalink / raw)
To: u-boot
Rune Torgersen wrote:
>> From: Timur Tabi [mailto:timur at freescale.com]
>> Something tells me that a lot of 83xx and 82xx platforms are broken.
>
> I would think ALL of them are broken. Probably also some of the other
> PPC platforms.
I think all of 83xx is broken. In fact, according to git-bisect, this commit is
the cause:
057004f4a4863554d56cc56268bfa7c7d9738e27 ("Correct fixup relocation for mpc83xx")
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=057004f4a4863554d56cc56268bfa7c7d9738e27
I tested 8323 and 8360, and neither boot with this commit applied.
Grant, can you try booting a U-Boot with this commit as the top?
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 22:18 ` Timur Tabi
@ 2007-10-26 22:27 ` Grant Likely
2007-10-26 22:33 ` Timur Tabi
0 siblings, 1 reply; 25+ messages in thread
From: Grant Likely @ 2007-10-26 22:27 UTC (permalink / raw)
To: u-boot
On 10/26/07, Timur Tabi <timur@freescale.com> wrote:
> Rune Torgersen wrote:
> >> From: Timur Tabi [mailto:timur at freescale.com]
> >> Something tells me that a lot of 83xx and 82xx platforms are broken.
> >
> > I would think ALL of them are broken. Probably also some of the other
> > PPC platforms.
>
> I think all of 83xx is broken. In fact, according to git-bisect, this commit is
> the cause:
>
> 057004f4a4863554d56cc56268bfa7c7d9738e27 ("Correct fixup relocation for mpc83xx")
>
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=057004f4a4863554d56cc56268bfa7c7d9738e27
>
> I tested 8323 and 8360, and neither boot with this commit applied.
>
> Grant, can you try booting a U-Boot with this commit as the top?
mpc8349-mitx-gp is working fine for me, so it's not all of 83xx
It might be related to compiler version. I'm using ELDK 4.1:
grant at trillian:~/hacking/u-boot$ ppc6xx ppc_6xx-gcc --version
ppc_6xx-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0)
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 22:27 ` Grant Likely
@ 2007-10-26 22:33 ` Timur Tabi
2007-10-26 22:36 ` Rune Torgersen
0 siblings, 1 reply; 25+ messages in thread
From: Timur Tabi @ 2007-10-26 22:33 UTC (permalink / raw)
To: u-boot
Grant Likely wrote:
> mpc8349-mitx-gp is working fine for me, so it's not all of 83xx
>
> It might be related to compiler version. I'm using ELDK 4.1:
It is. I was using 4.1.78. When I switched to 4.0.2, it worked.
So now what?
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 22:33 ` Timur Tabi
@ 2007-10-26 22:36 ` Rune Torgersen
2007-10-26 22:39 ` Timur Tabi
0 siblings, 1 reply; 25+ messages in thread
From: Rune Torgersen @ 2007-10-26 22:36 UTC (permalink / raw)
To: u-boot
> From: Timur Tabi Boot-Users] Bug in malloc()?
>
> Grant Likely wrote:
>
> > mpc8349-mitx-gp is working fine for me, so it's not all of 83xx
> >
> > It might be related to compiler version. I'm using ELDK 4.1:
>
> It is. I was using 4.1.78. When I switched to 4.0.2, it worked.
I tried 8280 with gcc 4.1.2, and it gets an machine check exception at
the point where it does the environment malloc.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 22:36 ` Rune Torgersen
@ 2007-10-26 22:39 ` Timur Tabi
2007-10-29 20:45 ` michael.firth at bt.com
0 siblings, 1 reply; 25+ messages in thread
From: Timur Tabi @ 2007-10-26 22:39 UTC (permalink / raw)
To: u-boot
Rune Torgersen wrote:
> I tried 8280 with gcc 4.1.2, and it gets an machine check exception at
> the point where it does the environment malloc.
Yes, I saw that too with sometimes with the 83xx tree. Sometimes it machine
checks, sometimes it goes in an infinite loop.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-26 22:39 ` Timur Tabi
@ 2007-10-29 20:45 ` michael.firth at bt.com
2007-10-29 20:53 ` Grant Likely
0 siblings, 1 reply; 25+ messages in thread
From: michael.firth at bt.com @ 2007-10-29 20:45 UTC (permalink / raw)
To: u-boot
>
> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Timur
Tabi
> Sent: 26 October 2007 23:40
> To: Rune Torgersen
> Cc: Grant Likely; u-boot-users at lists.sourceforge.net; Jerry Van Baren
> Subject: Re: [U-Boot-Users] Bug in malloc()?
>
> Rune Torgersen wrote:
>
> > I tried 8280 with gcc 4.1.2, and it gets an machine check exception
at
> > the point where it does the environment malloc.
>
> Yes, I saw that too with sometimes with the 83xx tree. Sometimes it
machine checks, sometimes it goes in an infinite loop.
This looks like the same issue I'm seeing trying to update my MPC834x
based system to u-boot-1.3.0-rcx. Under a BDI2000 it seems that several
of the malloc related pointers have addresses in flash, while in my
older u-boot version they are correctly pointing to addresses in RAM.
From this thread, it seems that three fixes have been recommended:
1) Disable "CONFIG_RELOC_FIXUP_WORKS" in the CPU header files
2) Backout some changes which affect the fixup operations (?)
3) Migrate to a newer compiler version
Which of these three options is the best to take, or has this thread not
yet reached that conclusion?
Thanks
Michael
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 20:45 ` michael.firth at bt.com
@ 2007-10-29 20:53 ` Grant Likely
2007-10-29 20:55 ` Timur Tabi
0 siblings, 1 reply; 25+ messages in thread
From: Grant Likely @ 2007-10-29 20:53 UTC (permalink / raw)
To: u-boot
On 10/29/07, michael.firth at bt.com <michael.firth@bt.com> wrote:
> >
> > Yes, I saw that too with sometimes with the 83xx tree. Sometimes it
> machine checks, sometimes it goes in an infinite loop.
>
> This looks like the same issue I'm seeing trying to update my MPC834x
> based system to u-boot-1.3.0-rcx. Under a BDI2000 it seems that several
> of the malloc related pointers have addresses in flash, while in my
> older u-boot version they are correctly pointing to addresses in RAM.
>
> From this thread, it seems that three fixes have been recommended:
>
> 1) Disable "CONFIG_RELOC_FIXUP_WORKS" in the CPU header files
> 2) Backout some changes which affect the fixup operations (?)
> 3) Migrate to a newer compiler version
Actually, #3 is migrate to an *older* compiler version. :-(
Unfortunately EABI relocation seems to be a rather undocumented thing.
If you can use an older compiler, #3 is the easiest workaround. I use
ELDK 4.1 personally which include GCC 4.0.0. You can backout the
enabling of CONFIG_RELOC_FIXUP_WORKS for 82xx, but I don't want to
apply that change to mainline if at all possible. I'd rather get
relocation working properly for all compilers once and for all.
>
> Which of these three options is the best to take, or has this thread not
> yet reached that conclusion?
>
> Thanks
>
> Michael
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 20:53 ` Grant Likely
@ 2007-10-29 20:55 ` Timur Tabi
2007-10-29 20:59 ` Rune Torgersen
0 siblings, 1 reply; 25+ messages in thread
From: Timur Tabi @ 2007-10-29 20:55 UTC (permalink / raw)
To: u-boot
Grant Likely wrote:
> Actually, #3 is migrate to an *older* compiler version. :-(
> Unfortunately EABI relocation seems to be a rather undocumented thing.
So *all* versions of gcc 4.1 are broken, or just newer ones? Do we know exactly
which versions are broken?
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 20:55 ` Timur Tabi
@ 2007-10-29 20:59 ` Rune Torgersen
2007-10-29 21:19 ` michael.firth at bt.com
2007-10-29 21:41 ` Grant Likely
0 siblings, 2 replies; 25+ messages in thread
From: Rune Torgersen @ 2007-10-29 20:59 UTC (permalink / raw)
To: u-boot
> From: Timur Tabi [mailto:timur at freescale.com]
> Sent: Monday, October 29, 2007 3:55 PM
>
> So *all* versions of gcc 4.1 are broken, or just newer ones?
> Do we know exactly
> which versions are broken?
Lerts start a list....
Broken:
gcc 3.4.3, glibc 2.3.4, binutils 2.15.94
gcc 4.1.2, glibc 2.5, binutils 2.17
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 20:59 ` Rune Torgersen
@ 2007-10-29 21:19 ` michael.firth at bt.com
2007-10-29 21:35 ` Rune Torgersen
2007-10-29 21:41 ` Grant Likely
1 sibling, 1 reply; 25+ messages in thread
From: michael.firth at bt.com @ 2007-10-29 21:19 UTC (permalink / raw)
To: u-boot
> -----Original Message-----
> From: Rune Torgersen [mailto:runet at innovsys.com]
>
> > From: Timur Tabi [mailto:timur at freescale.com]
> > Sent: Monday, October 29, 2007 3:55 PM
> >
> > So *all* versions of gcc 4.1 are broken, or just newer ones?
> > Do we know exactly
> > which versions are broken?
>
> Lerts start a list....
> Broken:
> gcc 3.4.3, glibc 2.3.4, binutils 2.15.94
> gcc 4.1.2, glibc 2.5, binutils 2.17
>
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On
> Behalf Of Grant Likely
>
> Actually, #3 is migrate to an *older* compiler version. :-(
Unfortunately EABI relocation seems to be a rather undocumented thing.
>
So, from Rune's list, it seems you actually need a 'middling' compiler
version, too old won't work, and too new won't work!
Sadly, I'm currently using gcc-3.4.3 for my U-Boot builds, so I'll
probably try one of the other two fixes, at least as an interim measure,
to prove that otherwise my u-boot-1.3.0 build is working.
Michael
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 21:19 ` michael.firth at bt.com
@ 2007-10-29 21:35 ` Rune Torgersen
2007-10-29 21:39 ` michael.firth at bt.com
0 siblings, 1 reply; 25+ messages in thread
From: Rune Torgersen @ 2007-10-29 21:35 UTC (permalink / raw)
To: u-boot
> From: michael.firth at bt.com
> > -----Original Message-----
> > From: Rune Torgersen [mailto:runet at innovsys.com]
> >
> > > From: Timur Tabi [mailto:timur at freescale.com]
> > > Sent: Monday, October 29, 2007 3:55 PM
> > >
> > > So *all* versions of gcc 4.1 are broken, or just newer ones?
> > > Do we know exactly
> > > which versions are broken?
> >
> > Lerts start a list....
> > Broken:
> > gcc 3.4.3, glibc 2.3.4, binutils 2.15.94
> > gcc 4.1.2, glibc 2.5, binutils 2.17
> >
> > From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On
> > Behalf Of Grant Likely
> >
> > Actually, #3 is migrate to an *older* compiler version. :-(
> Unfortunately EABI relocation seems to be a rather undocumented thing.
>
> So, from Rune's list, it seems you actually need a 'middling' compiler
> version, too old won't work, and too new won't work!
>
> Sadly, I'm currently using gcc-3.4.3 for my U-Boot builds, so I'll
> probably try one of the other two fixes, at least as an
> interim measure,
> to prove that otherwise my u-boot-1.3.0 build is working.
Then use solution #1. (works on both 3.4.3 amd 4.1.2 for me)
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 21:35 ` Rune Torgersen
@ 2007-10-29 21:39 ` michael.firth at bt.com
2007-10-29 21:42 ` Grant Likely
0 siblings, 1 reply; 25+ messages in thread
From: michael.firth at bt.com @ 2007-10-29 21:39 UTC (permalink / raw)
To: u-boot
> -----Original Message-----
> From: Rune Torgersen [mailto:runet at innovsys.com]
> Sent: 29 October 2007 21:35
> To: Firth,MJC,Michael,DMM R; timur at freescale.com;
> grant.likely at secretlab.ca
> Cc: u-boot-users at lists.sourceforge.net; gerald.vanbaren at ge.com
> Subject: RE: [U-Boot-Users] Bug in malloc()?
>
> > From: michael.firth at bt.com
> > > -----Original Message-----
> > > From: Rune Torgersen [mailto:runet at innovsys.com]
> > >
> > > > From: Timur Tabi [mailto:timur at freescale.com]
> > > > Sent: Monday, October 29, 2007 3:55 PM
> > > >
> > > > So *all* versions of gcc 4.1 are broken, or just newer ones?
> > > > Do we know exactly
> > > > which versions are broken?
> > >
> > > Lerts start a list....
> > > Broken:
> > > gcc 3.4.3, glibc 2.3.4, binutils 2.15.94 gcc 4.1.2, glibc 2.5,
> > > binutils 2.17
> > >
> > > From: glikely at secretlab.ca [mailto:glikely at secretlab.ca]
> On Behalf
> > > Of Grant Likely
> > >
> > > Actually, #3 is migrate to an *older* compiler version. :-(
> > Unfortunately EABI relocation seems to be a rather
> undocumented thing.
> >
> > So, from Rune's list, it seems you actually need a
> 'middling' compiler
> > version, too old won't work, and too new won't work!
> >
> > Sadly, I'm currently using gcc-3.4.3 for my U-Boot builds, so I'll
> > probably try one of the other two fixes, at least as an interim
> > measure, to prove that otherwise my u-boot-1.3.0 build is working.
>
> Then use solution #1. (works on both 3.4.3 amd 4.1.2 for me)
>
Will try that, it also has the advantage of being the easiest of the 3
options to try. Are there any bad side effects of disabling that define,
given that Grant's not keen to back it out more generally?
Michael
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 20:59 ` Rune Torgersen
2007-10-29 21:19 ` michael.firth at bt.com
@ 2007-10-29 21:41 ` Grant Likely
2007-10-29 21:55 ` Rune Torgersen
1 sibling, 1 reply; 25+ messages in thread
From: Grant Likely @ 2007-10-29 21:41 UTC (permalink / raw)
To: u-boot
On 10/29/07, Rune Torgersen <runet@innovsys.com> wrote:
> > From: Timur Tabi [mailto:timur at freescale.com]
> > Sent: Monday, October 29, 2007 3:55 PM
> >
> > So *all* versions of gcc 4.1 are broken, or just newer ones?
> > Do we know exactly
> > which versions are broken?
>
> Lerts start a list....
> Broken:
> gcc 3.4.3, glibc 2.3.4, binutils 2.15.94
> gcc 4.1.2, glibc 2.5, binutils 2.17
For all those who are experiencing breakage; can you please also post
the .reloc section from your u-boot.map file?
Here's mine from a working u-boot image:
.reloc 0xfe02e000 0x1fd0
*(.got)
0xfe02e000 _GOT2_TABLE_ = .
*(.got2)
.got2 0xfe02e000 0x24 cpu/mpc83xx/start.o
.got2 0xfe02e024 0x4c cpu/mpc83xx/libmpc83xx.a(traps.o)
.got2 0xfe02e070 0x1c cpu/mpc83xx/libmpc83xx.a(cpu_init.o)
.got2 0xfe02e08c 0x3c cpu/mpc83xx/libmpc83xx.a(speed.o)
.got2 0xfe02e0c8 0x70 lib_ppc/libppc.a(board.o)
.got2 0xfe02e138 0x8 lib_ppc/libppc.a(extable.o)
.got2 0xfe02e140 0x8 lib_ppc/libppc.a(interrupts.o)
.got2 0xfe02e148 0x12c net/libnet.a(net.o)
.got2 0xfe02e274 0xd0 net/libnet.a(tftp.o)
.got2 0xfe02e344 0x74 net/libnet.a(bootp.o)
.got2 0xfe02e3b8 0x30 net/libnet.a(rarp.o)
.got2 0xfe02e3e8 0x48 net/libnet.a(eth.o)
.got2 0xfe02e430 0xc8 net/libnet.a(nfs.o)
.got2 0xfe02e4f8 0x90 drivers/libdrivers.a(cfi_flash.o)
.got2 0xfe02e588 0x8 drivers/libdrivers.a(fsl_i2c.o)
.got2 0xfe02e590 0x20 drivers/libdrivers.a(pci.o)
.got2 0xfe02e5b0 0x4 drivers/libdrivers.a(serial.o)
.got2 0xfe02e5b4 0x90 drivers/libdrivers.a(tsec.o)
.got2 0xfe02e644 0x58 common/libcommon.a(main.o)
.got2 0xfe02e69c 0x20 common/libcommon.a(cmd_autoscript.o)
.got2 0xfe02e6bc 0x40 common/libcommon.a(cmd_bdinfo.o)
.got2 0xfe02e6fc 0xc common/libcommon.a(cmd_boot.o)
.got2 0xfe02e708 0x1bc common/libcommon.a(cmd_bootm.o)
.got2 0xfe02e8c4 0x1c common/libcommon.a(cmd_cache.o)
.got2 0xfe02e8e0 0x18 common/libcommon.a(cmd_console.o)
.got2 0xfe02e8f8 0x1c common/libcommon.a(cmd_date.o)
.got2 0xfe02e914 0xb0 common/libcommon.a(cmd_fdt.o)
.got2 0xfe02e9c4 0x64 common/libcommon.a(cmd_flash.o)
.got2 0xfe02ea28 0x260 common/libcommon.a(cmd_i2c.o)
.got2 0xfe02ec88 0x1c common/libcommon.a(cmd_itest.o)
.got2 0xfe02eca4 0xac common/libcommon.a(cmd_load.o)
.got2 0xfe02ed50 0x78 common/libcommon.a(cmd_mem.o)
.got2 0xfe02edc8 0x4 common/libcommon.a(cmd_misc.o)
.got2 0xfe02edcc 0x68 common/libcommon.a(cmd_net.o)
.got2 0xfe02ee34 0x68 common/libcommon.a(cmd_nvedit.o)
.got2 0xfe02ee9c 0x17c common/libcommon.a(cmd_pci.o)
.got2 0xfe02f018 0x54 common/libcommon.a(command.o)
.got2 0xfe02f06c 0x34 common/libcommon.a(console.o)
.got2 0xfe02f0a0 0x20 common/libcommon.a(devices.o)
.got2 0xfe02f0c0 0x2c common/libcommon.a(dlmalloc.o)
.got2 0xfe02f0ec 0x14 common/libcommon.a(env_common.o)
.got2 0xfe02f100 0x18 common/libcommon.a(env_flash.o)
.got2 0xfe02f118 0x3c common/libcommon.a(exports.o)
.got2 0xfe02f154 0x38 common/libcommon.a(fdt_support.o)
.got2 0xfe02f18c 0x2c common/libcommon.a(flash.o)
.got2 0xfe02f1b8 0xac common/libcommon.a(hush.o)
.got2 0xfe02f264 0x40 common/libcommon.a(miiphyutil.o)
.got2 0xfe02f2a4 0x4 common/libcommon.a(s_record.o)
.got2 0xfe02f2a8 0x48 common/libcommon.a(xyzModem.o)
.got2 0xfe02f2f0 0x4 common/libcommon.a(crc16.o)
.got2 0xfe02f2f4 0x18 libfdt/libfdt.a(fdt_ro.o)
.got2 0xfe02f30c 0x10 libfdt/libfdt.a(fdt_strerror.o)
.got2 0xfe02f31c 0x4 libfdt/libfdt.a(fdt_wip.o)
.got2 0xfe02f320 0x4 lib_generic/libgeneric.a(crc32.o)
.got2 0xfe02f324 0x2c
lib_generic/libgeneric.a(display_options.o)
.got2 0xfe02f350 0x4 lib_generic/libgeneric.a(string.o)
.got2 0xfe02f354 0x10 lib_generic/libgeneric.a(vsprintf.o)
.got2 0xfe02f364 0x8c lib_generic/libgeneric.a(zlib.o)
.got2 0xfe02f3f0 0x28
board/freescale/mpc8349itx/libmpc8349itx.a(mpc8349itx.o)
.got2 0xfe02f418 0x14
board/freescale/mpc8349itx/libmpc8349itx.a(pci.o)
.got2 0xfe02f42c 0x88 cpu/mpc83xx/libmpc83xx.a(cpu.o)
.got2 0xfe02f4b4 0x34 cpu/mpc83xx/libmpc83xx.a(spd_sdram.o)
.got2 0xfe02f4e8 0x8 rtc/librtc.a(date.o)
.got2 0xfe02f4f0 0x4 rtc/librtc.a(ds1337.o)
.got2 0xfe02f4f4 0x18 drivers/libdrivers.a(pci_indirect.o)
0xfe02f50c _FIXUP_TABLE_ = .
*(.fixup)
.fixup 0xfe02f50c 0x20 cpu/mpc83xx/libmpc83xx.a(cpu_init.o)
.fixup 0xfe02f52c 0x10 cpu/mpc83xx/libmpc83xx.a(speed.o)
.fixup 0xfe02f53c 0x38 lib_ppc/libppc.a(board.o)
.fixup 0xfe02f574 0x19c drivers/libdrivers.a(tsec.o)
.fixup 0xfe02f710 0x10 common/libcommon.a(cmd_autoscript.o)
.fixup 0xfe02f720 0xc common/libcommon.a(cmd_bdinfo.o)
.fixup 0xfe02f72c 0x1c common/libcommon.a(cmd_boot.o)
.fixup 0xfe02f748 0x48 common/libcommon.a(cmd_bootm.o)
.fixup 0xfe02f790 0x20 common/libcommon.a(cmd_cache.o)
.fixup 0xfe02f7b0 0x10 common/libcommon.a(cmd_console.o)
.fixup 0xfe02f7c0 0x2c common/libcommon.a(cmd_date.o)
.fixup 0xfe02f7ec 0x10 common/libcommon.a(cmd_fdt.o)
.fixup 0xfe02f7fc 0x30 common/libcommon.a(cmd_flash.o)
.fixup 0xfe02f82c 0x90 common/libcommon.a(cmd_i2c.o)
.fixup 0xfe02f8bc 0x44 common/libcommon.a(cmd_itest.o)
.fixup 0xfe02f900 0x30 common/libcommon.a(cmd_load.o)
.fixup 0xfe02f930 0xa0 common/libcommon.a(cmd_mem.o)
.fixup 0xfe02f9d0 0x1c common/libcommon.a(cmd_misc.o)
.fixup 0xfe02f9ec 0x50 common/libcommon.a(cmd_net.o)
.fixup 0xfe02fa3c 0x3c common/libcommon.a(cmd_nvedit.o)
.fixup 0xfe02fa78 0x10 common/libcommon.a(cmd_pci.o)
.fixup 0xfe02fa88 0x58 common/libcommon.a(command.o)
.fixup 0xfe02fae0 0xc common/libcommon.a(devices.o)
.fixup 0xfe02faec 0x400 common/libcommon.a(dlmalloc.o)
.fixup 0xfe02feec 0x4 common/libcommon.a(env_common.o)
.fixup 0xfe02fef0 0x4 common/libcommon.a(env_flash.o)
.fixup 0xfe02fef4 0x2c common/libcommon.a(hush.o)
0x00000543 __got2_entries =
((_FIXUP_TABLE_ - _GOT2_TABLE_) >> 0x2)
0x000002b1 __fixup_entries = ((. -
_FIXUP_TABLE_) >> 0x2)
.data 0xfe02ffd0 0xb40
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 21:39 ` michael.firth at bt.com
@ 2007-10-29 21:42 ` Grant Likely
0 siblings, 0 replies; 25+ messages in thread
From: Grant Likely @ 2007-10-29 21:42 UTC (permalink / raw)
To: u-boot
On 10/29/07, michael.firth at bt.com <michael.firth@bt.com> wrote:
> > -----Original Message-----
> > From: Rune Torgersen [mailto:runet at innovsys.com]
> > Sent: 29 October 2007 21:35
> > To: Firth,MJC,Michael,DMM R; timur at freescale.com;
> > grant.likely at secretlab.ca
> > Cc: u-boot-users at lists.sourceforge.net; gerald.vanbaren at ge.com
> > Subject: RE: [U-Boot-Users] Bug in malloc()?
> >
> > > From: michael.firth at bt.com
> > > > -----Original Message-----
> > > > From: Rune Torgersen [mailto:runet at innovsys.com]
> > > >
> > > > > From: Timur Tabi [mailto:timur at freescale.com]
> > > > > Sent: Monday, October 29, 2007 3:55 PM
> > > > >
> > > > > So *all* versions of gcc 4.1 are broken, or just newer ones?
> > > > > Do we know exactly
> > > > > which versions are broken?
> > > >
> > > > Lerts start a list....
> > > > Broken:
> > > > gcc 3.4.3, glibc 2.3.4, binutils 2.15.94 gcc 4.1.2, glibc 2.5,
> > > > binutils 2.17
> > > >
> > > > From: glikely at secretlab.ca [mailto:glikely at secretlab.ca]
> > On Behalf
> > > > Of Grant Likely
> > > >
> > > > Actually, #3 is migrate to an *older* compiler version. :-(
> > > Unfortunately EABI relocation seems to be a rather
> > undocumented thing.
> > >
> > > So, from Rune's list, it seems you actually need a
> > 'middling' compiler
> > > version, too old won't work, and too new won't work!
> > >
> > > Sadly, I'm currently using gcc-3.4.3 for my U-Boot builds, so I'll
> > > probably try one of the other two fixes, at least as an interim
> > > measure, to prove that otherwise my u-boot-1.3.0 build is working.
> >
> > Then use solution #1. (works on both 3.4.3 amd 4.1.2 for me)
> >
> Will try that, it also has the advantage of being the easiest of the 3
> options to try. Are there any bad side effects of disabling that define,
> given that Grant's not keen to back it out more generally?
The badness is that it's just avoiding the problem. The *real*
problem is that our C environment is insane and pointers to static
data need to be manually adjusted at runtime.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195
^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot-Users] Bug in malloc()?
2007-10-29 21:41 ` Grant Likely
@ 2007-10-29 21:55 ` Rune Torgersen
0 siblings, 0 replies; 25+ messages in thread
From: Rune Torgersen @ 2007-10-29 21:55 UTC (permalink / raw)
To: u-boot
> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On
> Sent: Monday, October 29, 2007 4:41 PM
> For all those who are experiencing breakage; can you please also post
> the .reloc section from your u-boot.map file?
gcc 3.4.3 at bottom
gcc 4.1.2:
.reloc 0xfff2e000 0x2208
*(.got)
0xfff2e000 _GOT2_TABLE_ = .
*(.got2)
.got2 0xfff2e000 0x24 cpu/mpc8260/start.o
.got2 0xfff2e024 0xd4
board/innovsys_ap2/libinnovsys_ap2.a(cmd_ap2.o)
.got2 0xfff2e0f8 0x90
board/innovsys_ap2/libinnovsys_ap2.a(sysinfo_proc.o)
.got2 0xfff2e188 0x150
board/innovsys_ap2/libinnovsys_ap2.a(ethsw_util.o)
.got2 0xfff2e2d8 0x14
board/innovsys_ap2/libinnovsys_ap2.a(altera.o)
.got2 0xfff2e2ec 0x54 cpu/mpc8260/libmpc8260.a(traps.o)
.got2 0xfff2e340 0x20
cpu/mpc8260/libmpc8260.a(cpu_init.o)
.got2 0xfff2e360 0x28
cpu/mpc8260/libmpc8260.a(interrupts.o)
.got2 0xfff2e388 0x4
cpu/mpc8260/libmpc8260.a(commproc.o)
.got2 0xfff2e38c 0x78 lib_ppc/libppc.a(board.o)
.got2 0xfff2e404 0x8 lib_ppc/libppc.a(extable.o)
.got2 0xfff2e40c 0x0 lib_ppc/libppc.a(time.o)
.got2 0xfff2e40c 0x8 lib_ppc/libppc.a(interrupts.o)
.got2 0xfff2e414 0x128 net/libnet.a(net.o)
.got2 0xfff2e53c 0xcc net/libnet.a(tftp.o)
.got2 0xfff2e608 0x70 net/libnet.a(bootp.o)
.got2 0xfff2e678 0x2c net/libnet.a(rarp.o)
.got2 0xfff2e6a4 0x44 net/libnet.a(eth.o)
.got2 0xfff2e6e8 0x24 drivers/libdrivers.a(pci.o)
.got2 0xfff2e70c 0x0 drivers/libdrivers.a(pci_auto.o)
.got2 0xfff2e70c 0x8 drivers/libdrivers.a(status_led.o)
.got2 0xfff2e714 0x44 common/libcommon.a(main.o)
.got2 0xfff2e758 0x20
common/libcommon.a(cmd_autoscript.o)
.got2 0xfff2e778 0x58 common/libcommon.a(cmd_bdinfo.o)
.got2 0xfff2e7d0 0xc common/libcommon.a(cmd_boot.o)
.got2 0xfff2e7dc 0x180 common/libcommon.a(cmd_bootm.o)
.got2 0xfff2e95c 0x1c common/libcommon.a(cmd_cache.o)
.got2 0xfff2e978 0x14 common/libcommon.a(cmd_eeprom.o)
.got2 0xfff2e98c 0x64 common/libcommon.a(cmd_flash.o)
.got2 0xfff2e9f0 0x218 common/libcommon.a(cmd_i2c.o)
.got2 0xfff2ec08 0x13c common/libcommon.a(cmd_immap.o)
.got2 0xfff2ed44 0x1c common/libcommon.a(cmd_itest.o)
.got2 0xfff2ed60 0x78 common/libcommon.a(cmd_mem.o)
.got2 0xfff2edd8 0x94 common/libcommon.a(cmd_mii.o)
.got2 0xfff2ee6c 0x4 common/libcommon.a(cmd_misc.o)
.got2 0xfff2ee70 0x68 common/libcommon.a(cmd_net.o)
.got2 0xfff2eed8 0x70 common/libcommon.a(cmd_nvedit.o)
.got2 0xfff2ef48 0x17c common/libcommon.a(cmd_pci.o)
.got2 0xfff2f0c4 0x18 common/libcommon.a(cmd_portio.o)
.got2 0xfff2f0dc 0x54 common/libcommon.a(command.o)
.got2 0xfff2f130 0x34 common/libcommon.a(console.o)
.got2 0xfff2f164 0x20 common/libcommon.a(devices.o)
.got2 0xfff2f184 0x28 common/libcommon.a(dlmalloc.o)
.got2 0xfff2f1ac 0x14 common/libcommon.a(env_common.o)
.got2 0xfff2f1c0 0x14 common/libcommon.a(env_flash.o)
.got2 0xfff2f1d4 0x3c common/libcommon.a(exports.o)
.got2 0xfff2f210 0x2c common/libcommon.a(flash.o)
.got2 0xfff2f23c 0xa0 common/libcommon.a(hush.o)
.got2 0xfff2f2dc 0x0 common/libcommon.a(lists.o)
.got2 0xfff2f2dc 0x0 common/libcommon.a(miiphybb.o)
.got2 0xfff2f2dc 0x40 common/libcommon.a(miiphyutil.o)
.got2 0xfff2f31c 0x0 common/libcommon.a(soft_i2c.o)
.got2 0xfff2f31c 0x4 lib_generic/libgeneric.a(crc32.o)
.got2 0xfff2f320 0x0 lib_generic/libgeneric.a(ctype.o)
.got2 0xfff2f320 0x2c
lib_generic/libgeneric.a(display_options.o)
.got2 0xfff2f34c 0x4 lib_generic/libgeneric.a(string.o)
.got2 0xfff2f350 0x10
lib_generic/libgeneric.a(vsprintf.o)
.got2 0xfff2f360 0x8c lib_generic/libgeneric.a(zlib.o)
.got2 0xfff2f3ec 0xf8
board/innovsys_ap2/libinnovsys_ap2.a(innovsys_ap2.o)
.got2 0xfff2f4e4 0x9c
board/innovsys_ap2/libinnovsys_ap2.a(flash.o)
.got2 0xfff2f580 0x0
cpu/mpc8260/libmpc8260.a(serial_smc.o)
.got2 0xfff2f580 0x50 cpu/mpc8260/libmpc8260.a(cpu.o)
.got2 0xfff2f5d0 0x34 cpu/mpc8260/libmpc8260.a(speed.o)
.got2 0xfff2f604 0x44
cpu/mpc8260/libmpc8260.a(ether_fcc.o)
.got2 0xfff2f648 0x4 cpu/mpc8260/libmpc8260.a(pci.o)
.got2 0xfff2f64c 0x0 lib_ppc/libppc.a(cache.o)
.got2 0xfff2f64c 0x18
drivers/libdrivers.a(pci_indirect.o)
0xfff2f664 _FIXUP_TABLE_ = .
*(.fixup)
.fixup 0xfff2f664 0x90
board/innovsys_ap2/libinnovsys_ap2.a(cmd_ap2.o)
.fixup 0xfff2f6f4 0x18
cpu/mpc8260/libmpc8260.a(cpu_init.o)
.fixup 0xfff2f70c 0x50 lib_ppc/libppc.a(board.o)
.fixup 0xfff2f75c 0x10
common/libcommon.a(cmd_autoscript.o)
.fixup 0xfff2f76c 0xc common/libcommon.a(cmd_bdinfo.o)
.fixup 0xfff2f778 0x1c common/libcommon.a(cmd_boot.o)
.fixup 0xfff2f794 0x30 common/libcommon.a(cmd_bootm.o)
.fixup 0xfff2f7c4 0x20 common/libcommon.a(cmd_cache.o)
.fixup 0xfff2f7e4 0x10 common/libcommon.a(cmd_eeprom.o)
.fixup 0xfff2f7f4 0x30 common/libcommon.a(cmd_flash.o)
.fixup 0xfff2f824 0x80 common/libcommon.a(cmd_i2c.o)
.fixup 0xfff2f8a4 0xd0 common/libcommon.a(cmd_immap.o)
.fixup 0xfff2f974 0x44 common/libcommon.a(cmd_itest.o)
.fixup 0xfff2f9b8 0xa0 common/libcommon.a(cmd_mem.o)
.fixup 0xfff2fa58 0x118 common/libcommon.a(cmd_mii.o)
.fixup 0xfff2fb70 0x1c common/libcommon.a(cmd_misc.o)
.fixup 0xfff2fb8c 0x40 common/libcommon.a(cmd_net.o)
.fixup 0xfff2fbcc 0x4c common/libcommon.a(cmd_nvedit.o)
.fixup 0xfff2fc18 0x10 common/libcommon.a(cmd_pci.o)
.fixup 0xfff2fc28 0x20 common/libcommon.a(cmd_portio.o)
.fixup 0xfff2fc48 0x58 common/libcommon.a(command.o)
.fixup 0xfff2fca0 0xc common/libcommon.a(devices.o)
.fixup 0xfff2fcac 0x400 common/libcommon.a(dlmalloc.o)
.fixup 0xfff300ac 0x4 common/libcommon.a(env_common.o)
.fixup 0xfff300b0 0x4 common/libcommon.a(env_flash.o)
.fixup 0xfff300b4 0x2c common/libcommon.a(hush.o)
.fixup 0xfff300e0 0x24 lib_generic/libgeneric.a(zlib.o)
.fixup 0xfff30104 0x4
board/innovsys_ap2/libinnovsys_ap2.a(innovsys_ap2.o)
.fixup 0xfff30108 0x100 cpu/mpc8260/libmpc8260.a(speed.o)
0x00000599 __got2_entries =
((_FIXUP_TABLE_ - _GOT2_TABLE_) >> 0x2)
0x000002e9 __fixup_entries = ((. -
_FIXUP_TABLE_) >> 0x2)
.data 0xfff30208 0xd48
++++++++++++++++++
gcc 3.4.3:
.reloc 0xfff2e000 0x1664
*(.got)
0xfff2e000 _GOT2_TABLE_ = .
*(.got2)
.got2 0xfff2e000 0x24 cpu/mpc8260/start.o
.got2 0xfff2e024 0xd4
board/innovsys_ap2/libinnovsys_ap2.a(cmd_ap2.o)
.got2 0xfff2e0f8 0x8c
board/innovsys_ap2/libinnovsys_ap2.a(sysinfo_proc.o)
.got2 0xfff2e184 0x150
board/innovsys_ap2/libinnovsys_ap2.a(ethsw_util.o)
.got2 0xfff2e2d4 0x14
board/innovsys_ap2/libinnovsys_ap2.a(altera.o)
.got2 0xfff2e2e8 0x54 cpu/mpc8260/libmpc8260.a(traps.o)
.got2 0xfff2e33c 0x20
cpu/mpc8260/libmpc8260.a(cpu_init.o)
.got2 0xfff2e35c 0x28
cpu/mpc8260/libmpc8260.a(interrupts.o)
.got2 0xfff2e384 0x4
cpu/mpc8260/libmpc8260.a(commproc.o)
.got2 0xfff2e388 0x78 lib_ppc/libppc.a(board.o)
.got2 0xfff2e400 0x8 lib_ppc/libppc.a(extable.o)
.got2 0xfff2e408 0x8 lib_ppc/libppc.a(interrupts.o)
.got2 0xfff2e410 0x128 net/libnet.a(net.o)
.got2 0xfff2e538 0xd0 net/libnet.a(tftp.o)
.got2 0xfff2e608 0x70 net/libnet.a(bootp.o)
.got2 0xfff2e678 0x2c net/libnet.a(rarp.o)
.got2 0xfff2e6a4 0x44 net/libnet.a(eth.o)
.got2 0xfff2e6e8 0x24 drivers/libdrivers.a(pci.o)
.got2 0xfff2e70c 0x8 drivers/libdrivers.a(status_led.o)
.got2 0xfff2e714 0x48 common/libcommon.a(main.o)
.got2 0xfff2e75c 0x20
common/libcommon.a(cmd_autoscript.o)
.got2 0xfff2e77c 0x58 common/libcommon.a(cmd_bdinfo.o)
.got2 0xfff2e7d4 0xc common/libcommon.a(cmd_boot.o)
.got2 0xfff2e7e0 0x17c common/libcommon.a(cmd_bootm.o)
.got2 0xfff2e95c 0x1c common/libcommon.a(cmd_cache.o)
.got2 0xfff2e978 0x14 common/libcommon.a(cmd_eeprom.o)
.got2 0xfff2e98c 0x64 common/libcommon.a(cmd_flash.o)
.got2 0xfff2e9f0 0x218 common/libcommon.a(cmd_i2c.o)
.got2 0xfff2ec08 0x138 common/libcommon.a(cmd_immap.o)
.got2 0xfff2ed40 0x18 common/libcommon.a(cmd_itest.o)
.got2 0xfff2ed58 0x78 common/libcommon.a(cmd_mem.o)
.got2 0xfff2edd0 0x94 common/libcommon.a(cmd_mii.o)
.got2 0xfff2ee64 0x4 common/libcommon.a(cmd_misc.o)
.got2 0xfff2ee68 0x68 common/libcommon.a(cmd_net.o)
.got2 0xfff2eed0 0x70 common/libcommon.a(cmd_nvedit.o)
.got2 0xfff2ef40 0x178 common/libcommon.a(cmd_pci.o)
.got2 0xfff2f0b8 0x18 common/libcommon.a(cmd_portio.o)
.got2 0xfff2f0d0 0x54 common/libcommon.a(command.o)
.got2 0xfff2f124 0x34 common/libcommon.a(console.o)
.got2 0xfff2f158 0x20 common/libcommon.a(devices.o)
.got2 0xfff2f178 0x2c common/libcommon.a(dlmalloc.o)
.got2 0xfff2f1a4 0x14 common/libcommon.a(env_common.o)
.got2 0xfff2f1b8 0x18 common/libcommon.a(env_flash.o)
.got2 0xfff2f1d0 0x3c common/libcommon.a(exports.o)
.got2 0xfff2f20c 0x2c common/libcommon.a(flash.o)
.got2 0xfff2f238 0xa4 common/libcommon.a(hush.o)
.got2 0xfff2f2dc 0x40 common/libcommon.a(miiphyutil.o)
.got2 0xfff2f31c 0x4 lib_generic/libgeneric.a(crc32.o)
.got2 0xfff2f320 0x2c
lib_generic/libgeneric.a(display_options.o)
.got2 0xfff2f34c 0x4 lib_generic/libgeneric.a(string.o)
.got2 0xfff2f350 0x10
lib_generic/libgeneric.a(vsprintf.o)
.got2 0xfff2f360 0x8c lib_generic/libgeneric.a(zlib.o)
.got2 0xfff2f3ec 0xf8
board/innovsys_ap2/libinnovsys_ap2.a(innovsys_ap2.o)
.got2 0xfff2f4e4 0x98
board/innovsys_ap2/libinnovsys_ap2.a(flash.o)
.got2 0xfff2f57c 0x4
cpu/mpc8260/libmpc8260.a(serial_smc.o)
.got2 0xfff2f580 0x50 cpu/mpc8260/libmpc8260.a(cpu.o)
.got2 0xfff2f5d0 0x34 cpu/mpc8260/libmpc8260.a(speed.o)
.got2 0xfff2f604 0x44
cpu/mpc8260/libmpc8260.a(ether_fcc.o)
.got2 0xfff2f648 0x4 cpu/mpc8260/libmpc8260.a(pci.o)
.got2 0xfff2f64c 0x18
drivers/libdrivers.a(pci_indirect.o)
0xfff2f664 _FIXUP_TABLE_ = .
*(.fixup)
0x00000599 __got2_entries =
((_FIXUP_TABLE_ - _GOT2_TABLE_) >> 0x2)
0x00000000 __fixup_entries = ((. -
_FIXUP_TABLE_) >> 0x2)
.data 0xfff2f664 0xe94
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2007-10-29 21:55 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-25 22:35 [U-Boot-Users] Bug in malloc()? Timur Tabi
2007-10-26 11:34 ` Jerry Van Baren
2007-10-26 14:20 ` Rune Torgersen
2007-10-26 14:27 ` Timur Tabi
2007-10-26 14:41 ` Rune Torgersen
2007-10-26 14:45 ` Rune Torgersen
2007-10-26 15:01 ` Timur Tabi
[not found] ` <DCEAAC0833DD314AB0B58112AD99B93B038A2914@ismail.innsys.innovsys.com>
[not found] ` <472203F8.3030800@freescale.com>
[not found] ` <DCEAAC0833DD314AB0B58112AD99B93B038A292D@ismail.innsys.innovsys.com>
[not found] ` <47220576.2080700@freescale.com>
2007-10-26 15:23 ` Rune Torgersen
2007-10-26 16:56 ` Timur Tabi
2007-10-26 22:18 ` Timur Tabi
2007-10-26 22:27 ` Grant Likely
2007-10-26 22:33 ` Timur Tabi
2007-10-26 22:36 ` Rune Torgersen
2007-10-26 22:39 ` Timur Tabi
2007-10-29 20:45 ` michael.firth at bt.com
2007-10-29 20:53 ` Grant Likely
2007-10-29 20:55 ` Timur Tabi
2007-10-29 20:59 ` Rune Torgersen
2007-10-29 21:19 ` michael.firth at bt.com
2007-10-29 21:35 ` Rune Torgersen
2007-10-29 21:39 ` michael.firth at bt.com
2007-10-29 21:42 ` Grant Likely
2007-10-29 21:41 ` Grant Likely
2007-10-29 21:55 ` Rune Torgersen
2007-10-26 15:04 ` Rune Torgersen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox