--- Additional Comments From kamaraju at gmail dot com 2008-11-17 13:34
---
I checked in the /var/tmp folder, but there are no .s files there. They must
have been deleted automatically when the compilation failed. Is there any
alternate way to obtain them?
--
--- Additional Comments From eric dot weddington at atmel dot com
2008-11-17 15:27 ---
Fixed and committed as obvious on HEAD and 2.19 branch.
--
What|Removed |Added
--- Additional Comments From nickc at redhat dot com 2008-11-17 16:34
---
Hi Sebastian,
Why not use a pre-processor instead ? For example your board specific file
could look like this:
MEMORY {
ROM_REGION (RX) : ORIGIN = 0x1000, LENGTH = 256M
RAM_REGION (AIW)
--- Additional Comments From nickc at redhat dot com 2008-11-17 16:46
---
Created an attachment (id=3065)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=3065action=view)
Another patch attempt
--
What|Removed |Added
--- Additional Comments From nickc at redhat dot com 2008-11-17 16:47
---
Hi Rainer,
OK taking Ian's comments into account I have uploaded another attempt at a
patch for this problem. Please could you try it out and let me know if it is
any good ?
Cheers
Nick
--
Hi, Nick,
thanks for your suggestion, I'll try it tomorrow.
from your reply about my using option -X -s, I think it is necessary to
detail the prcess of my operation:
Step first, I use option -r to link all the objs together(without option
-X -s), and it succeed; the output obj file has size
--- Additional Comments From nickc at redhat dot com 2008-11-17 16:52
---
Hi Kamaraju,
I checked in the /var/tmp folder, but there are no .s files there. They must
have been deleted automatically when the compilation failed. Is there any
alternate way to obtain them?
Just add
--- Additional Comments From kamaraju at gmail dot com 2008-11-17 17:03
---
Created an attachment (id=3066)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=3066action=view)
temporary files created during the compilation.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7032
--- Additional Comments From kamaraju at gmail dot com 2008-11-17 17:05
---
Ok. I attached the .s, .ii files from the compilation process.
raju
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7032
--- You are receiving this mail because: ---
You are on the CC list for
Hi shihhuangti,
it is diffcult to me to explain why this happens, for the memory required
by the second step should be smaller the the first step(because the ld can
drop some section within every obj file); and the first functions, why the
second doesn't?
Because when the linker performs a
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-17 17:29 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
OK taking Ian's comments into account I have uploaded another attempt at a
--- Additional Comments From nickc at redhat dot com 2008-11-17 17:32
---
Hi Kamaraju,
What is the command line used to invoke the assembler ? (You can find this by
adding -v to your gcc command line).
Cheers
Nick
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7032
Hi Rainer,
unfortunately, ld SEGVs now here:
#0 0x0008d19c in _bfd_sparc_elf_check_relocs (abfd=0x1dc518, info=0x19d980,
sec=0x1f6a28, relocs=0x1fdc18) at
/vol/gnu/src/binutils/binutils-dist/bfd/elfxx-sparc.c:1348
Doh. Thinko in the patch. Please change:
case R_SPARC_WPLT30:
/*
The relaxing pass fails to properly relax branches. Branch targets that are
reachable during the first relax pass can become unreachable during the second
pass. In the test case the branch target is exactly -0x100 bytes away
after the second round trip of the first pass, but off by 32
--- Additional Comments From nickc at redhat dot com 2008-11-17 17:41
---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC:
could not read symbols: Bad value
Hi Rainer,
unfortunately, ld SEGVs now here:
#0 0x0008d19c in _bfd_sparc_elf_check_relocs
--- Additional Comments From schwab at suse dot de 2008-11-17 17:43 ---
The testcase is available in
http://ftp.suse.com/pub/people/schwab/libjava.tar.bz2.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7036
--- You are receiving this mail because: ---
You are on the CC
--- Additional Comments From kamaraju at gmail dot com 2008-11-17 17:46
---
/home/kkusuman/software/compileHere/gcc-4.4-20081107/./gcc/xgcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../../unZipped/gcc-4.4-20081107/configure
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-17 17:48 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
(Only the last line has changed).
done, but not much better either: at first I
--- Additional Comments From nickc at redhat dot com 2008-11-17 17:51
---
Subject: Re: gcc fails to compile with Internal error,
aborting at dw2gencfi.c line 1267 errror
Hi Kamaraju,
/home/kkusuman/software/compileHere/gcc-4.4-20081107/./gcc/xgcc -
Sorry, I meant please add -v to
--- Additional Comments From nickc at redhat dot com 2008-11-17 17:54
---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC:
could not read symbols: Bad value
Hi Rainer,
done, but not much better either: at first I get a lot of assertion
failures
Ok, this is
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-17 18:02 ---
Created an attachment (id=3068)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=3068action=view)
problematic object file
--
http://sourceware.org/bugzilla/show_bug.cgi?id=7027
---
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-17 18:13 ---
Created an attachment (id=3069)
-- (http://sourceware.org/bugzilla/attachment.cgi?id=3069action=view)
object file that shows both the original and new problems
--
What|Removed
--- Additional Comments From ro at TechFak dot Uni-Bielefeld dot DE
2008-11-17 18:13 ---
Subject: Re: 64-bit libstdc++.so fails to link on Solaris 11/SPARC: could not
read symbols: Bad value
Hi Nick,
Ok, this is going nowhere. Is it possible for you to create a small
testcase
--- Additional Comments From kamaraju at gmail dot com 2008-11-17 18:28
---
I am able to reproduce the internal error by doing
as -Av9 eh_alloc.s
eh_alloc.s: Assembler messages:
eh_alloc.s:9164: Internal error, aborting at dw2gencfi.c line 1267
Please report this bug.
I am using
as
--- Additional Comments From amodra at bigpond dot net dot au 2008-11-18
01:10 ---
It's a doc bug then. You'll see plenty of dynamic relocs against instructions
if you build a non-pic shared library, which is valid on some targets.
--
25 matches
Mail list logo
