On Jul 8, 2009, at 10:39 PM, Kumar Gala wrote:
On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
If we modify the linker script:
_end2 = .;
_end3 = ALIGN(4096);
_end4 = ALIGN(PAGE_SIZE);
. = ALIGN(PAGE_SIZE);
_end
On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
If we modify the linker script:
_end2 = .;
_end3 = ALIGN(4096);
_end4 = ALIGN(PAGE_SIZE);
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
and the resu
On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
If we modify the linker script:
_end2 = .;
_end3 = ALIGN(4096);
_end4 = ALIGN(PAGE_SIZE);
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
and the resu
Alan,
We are seeing an issue w/ld and kernel linking of 32-bit kernels.
The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not
providing the proper address for _end.
Building stock v2.6.30 w/the mpc85xx_defconfig we get:
1000 A _end
Using 2.18.50.20080215 we get:
c068 A _en
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
> To further verify this if I switch the -me500 to -mspe and build things
> seem to be ok. This further points at some APU section related bug.
Like omitting .PPC.EMB.apuinfo from your kernel link script? See the
ld info doc on orphan
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
> If we modify the linker script:
>
> _end2 = .;
> _end3 = ALIGN(4096);
> _end4 = ALIGN(PAGE_SIZE);
> . = ALIGN(PAGE_SIZE);
> _end = . ;
> PROVIDE32 (end = .);
>
> and the result is:
>
> 1000 A _end
--- Additional Comments From booleandomain at gmail dot com 2009-07-08
20:46 ---
I tried both --with-build-sysroot=/tools and --with-sysroot=/tools
(undocumented?) but I get for example:
$ ldd binutils/ar
linux-vdso.so.1 => (0x7fff2b5ff000)
libz.so.1 => /lib/libz.so.1 (0x7fc61e
--- Additional Comments From hjl dot tools at gmail dot com 2009-07-08
19:46 ---
(In reply to comment #5)
> Yes, but I need that option because I'm building a GNU/Linux toolchain inside
> of
> /tools, and packages have to link to the dynamic linker inside of it.
That is not supported.
--- Additional Comments From booleandomain at gmail dot com 2009-07-08
19:32 ---
Yes, but I need that option because I'm building a GNU/Linux toolchain inside of
/tools, and packages have to link to the dynamic linker inside of it.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10
--- Additional Comments From hjl dot tools at gmail dot com 2009-07-08
17:52 ---
(In reply to comment #2)
> It seems the problem is related to the fact I have in CFLAGS the following
> option: -Wl,--dynamic-linker,/tools/lib64/ld-linux-x86-64.so.2
If you remove it, will build work?
--
--- Additional Comments From booleandomain at gmail dot com 2009-07-08
17:22 ---
I just tried binutils cvs, but the problem persists.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10376
--- You are receiving this mail because: ---
You are on the CC list for the bug, or a
--- Additional Comments From booleandomain at gmail dot com 2009-07-08
15:19 ---
It seems the problem is related to the fact I have in CFLAGS the following
option: -Wl,--dynamic-linker,/tools/lib64/ld-linux-x86-64.so.2
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10376
---
mips-elf-objdump (compiled from binutils 2.19) does not disassemble a sequence
of instructions in section .text if first instruction has a label:
== bug trace
$ cat atest.s
.global write
.text
write: SW $3, Z #
13 matches
Mail list logo
