--- Additional Comments From sebastian dot huber at embedded-brains dot de
2008-11-18 09:15 ---
Hi Nick,
we could of course use the C pre-processor or a billion other tools to generate
a linker command file, but the linker should do its job without the need of
external tools. The
Test case: test.c
==
extern one();
main () {
one();
}
===
Compilation command: cr16-elf-gcc test.c -g -O2
===
ld:Dwarf Error: Offset (78) greater than or equal to (null) size (135095464).
/tmp/cceIbvAM.o: In function `':
r/align/1.c:5: undefined reference to `_one'
collect2: ld returned 1 exit
--- Additional Comments From swami at india dot nsc dot com 2008-11-18
10:11 ---
Created an attachment (id=3071)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=3071action=view)
Assembly file of test.c
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7037
--- You are
--- Additional Comments From nickc at redhat dot com 2008-11-18 11:42
---
Created an attachment (id=3072)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=3072action=view)
third try
--
What|Removed |Added
--- Additional Comments From nickc at redhat dot com 2008-11-18 11:45
---
Hi Rainer,
OK, I have uploaded a third patch for you to try. This one works(1) for me
although to be honest I do not really see how it is different from the second
patch. Anyway give it a whirl and see how
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-18 13:05 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
OK, I have uploaded a third patch for you to try. This one works(1) for me
--- Additional Comments From nickc at redhat dot com 2008-11-18 13:56
---
Created an attachment (id=3073)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=3073action=view)
Fix reloc desriptions
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7037
--- You are receiving
--- Additional Comments From nickc at redhat dot com 2008-11-18 14:02
---
Hi Swami,
Well this was a fun one to track down. The problem turned out to be the
descriptions of the CR16 relocs in elf32-cr16.c. In particular they were using
the src_mask field of reloc_howto_struct which
Hi Rainer,
Unfortunately, regtesting the resulting GCC build is
currently hampered by the following warning:
/vol/gcc/obj/binutils-2.19.50-g/ld/ld-new: warning: section `.bss' type changed
to PROGBITS
This is harmless during the build, but many testcases (not only c++ and
libstdc++-v3) fail
--- Additional Comments From nickc at redhat dot com 2008-11-18 14:07
---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC:
could not read symbols: Bad value
Hi Rainer,
Unfortunately, regtesting the resulting GCC build is
currently hampered by the following
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-18 14:10 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
I think that this is a separate problem, rather than fallout from the
certainly.
Hi Rainer,
I'll try. First of all, I need to understand what the warning is all
about.
Oh, well the progbits attribute indicates that the section contains
data values, but the .bss section should in theory be completely empty
and just initialized with zero bytes when the program is loaded
--- Additional Comments From nickc at redhat dot com 2008-11-18 14:21
---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC:
could not read symbols: Bad value
Hi Rainer,
I'll try. First of all, I need to understand what the warning is all
about.
Oh, well
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-18 14:41 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
Oh, well the progbits attribute indicates that the section contains
data values,
Hi Rainer,
Every single one of the libstdc++ object files is affected. E.g.
% readelf -S --wide .libs/wstring-inst.o |grep -A1 '\.bss'
[191] .bss._ZZL18__gthread_active_pvE21__gthread_active_once PROGBITS
0205a8 20 00 WA 0 0 8
If I assemble the same
--- Additional Comments From nickc at redhat dot com 2008-11-18 15:11
---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC:
could not read symbols: Bad value
Hi Rainer,
Every single one of the libstdc++ object files is affected. E.g.
% readelf -S --wide
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-18 18:23 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
So, are you saying that assembling with gas v2.19 fixes the problem ?
indeed:
I reported this on gnu.utils.bug a while back, but never got any bites
(http://groups.google.com/group/gnu.utils.bug/browse_thread/thread/6c67f496bcea3cde/fa5b859ca7bf663c?hl=enlnk=gstq=ld#fa5b859ca7bf663c).
Here's the description:
I suspect it's always worked this way, but seems like a bug to
--- Additional Comments From swami at sourceware dot org 2008-11-19 04:21
---
Hi Nick,
Thank you very much for anlysis and patch.
Thanks
Swami
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7037
--- You are receiving this mail because: ---
You are on the CC list for
I am currently trying to embed an ELF into a larger ELF that will manage this
ELF (boostrap it and execute it).
Extra information is inserted when trying to embed an ELF into a larger ELF.
This extra info makes the start and end labels useless if code in the
larger ELF would like to jump to the
20 matches
Mail list logo
