--- Additional Comments From nickc at redhat dot com 2008-11-14 09:03
---
Hi Peter,
Thanks for reporting this problem and providing a fix. I have checked your
patch in along with this changelog entry.
Cheers
Nick
gas/ChangeLog
2008-11-14 Peter Jansen <[EMAIL PROTECTED]>
--- Additional Comments From nickc at redhat dot com 2008-11-14 09:18
---
Created an attachment (id=3062)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=3062&action=view)
Guess at how to handle local WPLT30 relocations for 64-bit sparc.
--
http://sourceware.org/bugzilla/show
--- Additional Comments From nickc at redhat dot com 2008-11-14 09:19
---
Hi Rainer,
I am not familiar with the Sparc architecture, but I have uploaded a possible
patch which might fix the problem you discovered. Please could you try it out
and let me know if it really works ?
Cheer
Suppose you have an operating system that supports many different micro
controller boards (RTEMS in our case). Each board needs a linker command file
which supports it. The boards tend to come in various flavors. Some execute
code from flash others copy the code and constant data from a flash in
Hi Mat,
My fix is simply to reserve enough space before calling frag_now_fix
that the frag won't run out of room if frag_more is called later.
Thanks for providing a fix for the problem. I have checked it in along
with this changelog entry.
Cheers
Nick
gas/ChangeLog
2008-11-14 Mat Host
Hi Mat,
emit_expr, used by '.word' and others, grabs dot_value for the current
frag, does some processing, and later calls frag_more. Unfortunately,
the frag_more call can realize the frag is not big enough and switch
to a new frag. That's bad because the dot_value already recorded an
offset i
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-14 14:15 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
> I am not familiar with the Sparc architecture, but I have uploaded a
> possible
--
What|Removed |Added
CC||ian at airs dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=7027
--- You are receiving this mail b
Hi Rainer,
+ if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) ==
R_SPARC_PLT32)
+ || (ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) ==
R_SPARC_PLT64))
The ABI_64_P() part doesn't trigger since ELF32_R_TYPE (rel->r_info) is 18
(i.e. R_SPARC_WPLT30) at this poi
--- Additional Comments From nickc at redhat dot com 2008-11-14 14:51
---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC:
could not read symbols: Bad value
Hi Rainer,
> + if ((! ABI_64_P (abfd) && ELF32_R_TYPE (rel->r_info) ==
> R_SPARC_PLT32)
> +
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-14 15:09 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
> As a matter of interest if you change this to:
>
>if ((! ABI_64_P (abfd) && EL
The weekly snapshot (dated 20081107) of gcc 4.4 fails to compile on a Sun
Solaris machine with the following errors.
/bin/bash ../libtool --tag CXX --tag disable-shared --mode=compile
/home/kkusuman/software/compileHere/gcc-4.4-20081107/./gcc/xgcc -shared-libgcc
-B/home/kkusuman/software/compileHe
12 matches
Mail list logo
