https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #13 from Rainer Orth ---
> --- Comment #10 from Indu Bhagat ---
> To be clear, the current SEGV is because we do a sframe_plt = NULL if
> !normal_target in bfd/elfxx-x86.c _bfd_x86_elf_link_setup_gnu_properties. We
> could go ahe
https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #11 from Rainer Orth ---
> --- Comment #10 from Indu Bhagat ---
> (In reply to Rainer Orth from comment #9)
[...]
>> true, but why would this be necessary, especially when gcc is using both
>> gas and gld? This combo should be ab
https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #9 from Rainer Orth ---
> --- Comment #8 from Indu Bhagat ---
> Recently to fix PR ld/33146, commit 939eb467b21de5d18ee703755fb9704a525cfe21
> added some tests to be run with --gsframe. SFrame sections are of type
> SHT_GNU_SFRAM
https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #6 from Rainer Orth ---
> --- Comment #5 from Indu Bhagat ---
> Thanks! Will try this out on cfarm 215 once it back online (it has been down
> the whole day today).
This is weird: the system has been up all day yesterday, and the
https://sourceware.org/bugzilla/show_bug.cgi?id=33199
--- Comment #4 from Rainer Orth ---
> --- Comment #1 from Indu Bhagat ---
> On a cfarm 215, when running the ld testsuite, I see that the lto.exp tests
> are
> not run. Not sure if I need a gcc with lto enabled (will look).
>
> Further man
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #17 from Rainer Orth ---
> --- Comment #16 from Nick Alcock ---
> Hm. This freshly built GNU ld on the compile farm box which I believe is yours
> (cfarm216) seems to be quite unhappy:
>
> nix@s11-sparc:~/binutils-gdb/build/ld$ ./
https://sourceware.org/bugzilla/show_bug.cgi?id=33168
--- Comment #3 from Rainer Orth ---
> --- Comment #2 from Indu Bhagat ---
> AC_USE_SYSTEM_EXTENSIONS is used in other configure.ac in Binutils too. So, I
> am not sure if removing it from libsframe is ideal. I dont have a good grasp
> of th
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #15 from Rainer Orth ---
> --- Comment #14 from Nick Alcock ---
> I think I have something which can literally check to see whether the linker
> is
> dedupping CTF or simply concatenating it :) so even non-GNU linkers should
> j
https://sourceware.org/bugzilla/show_bug.cgi?id=33168
--- Comment #1 from Rainer Orth ---
> * A patch like the following:
>
> diff --git a/libsframe/configure.ac b/libsframe/configure.ac
> --- a/libsframe/configure.ac
> +++ b/libsframe/configure.ac
> @@ -23,6 +23,13 @@ AC_CONFIG_SRCDIR(sframe.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #13 from Rainer Orth ---
> --- Comment #4 from Nick Alcock ---
> We can probably assume that pre-v8plus hardware is long extinct, so this
> horrible hack will probably do. (A shame we can't arrange to assemble "the
> same
> way G
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #12 from Rainer Orth ---
> --- Comment #11 from Nick Alcock ---
> OK, so it's kind of acceptable to have required configurations for a GCC used
> for binutils testing, then. I wasn't sure. Time to build a new GCC locally on
> that
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #10 from Rainer Orth ---
> --- Comment #8 from Nick Alcock ---
> Yes -- but if GCC wasn't built with GNU ld, collect2 appears to run the
> non-GNU
> ld anyway, ignoring(?) -B:
Such a gcc is almost guaranteed to fail when used wi
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #7 from Rainer Orth ---
> --- Comment #6 from Nick Alcock ---
> ... OK, so I need to detect (and probably need to detect for ld tests as well)
> when gcc is built to use a non-GNU ld, and skip all tests that require CTF
> dedup in
https://sourceware.org/bugzilla/show_bug.cgi?id=33162
--- Comment #3 from Rainer Orth ---
> --- Comment #2 from Nick Alcock ---
> There's a big pile of libctf/ failures too, none of which I remember seeing
> before... I'll have a look at those.
The only remaining one I see is on 32-bit Solaris/
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #9 from Rainer Orth ---
> --- Comment #8 from Nick Alcock ---
> That's not the only problem I found on Sol11.4... builds fail entirely when
> Solaris ld is in use because the libctf-nobfd.ver script generation is broken.
> I'll ra
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #7 from Rainer Orth ---
> --- Comment #5 from Nick Alcock ---
> Oh of course, we already have mmap-disabling code in place! More fool me, I
> only wrote it. It will also turn off (entirely working) mmapping of reads, but
> since t
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #4 from Rainer Orth ---
> --- Comment #3 from Nick Alcock ---
Thanks for the update.
> Mixed mmap() and read() from the same fd is absolutely nonportable (or at the
> very least delicate and breaks frequently, as seen here) and w
https://sourceware.org/bugzilla/show_bug.cgi?id=33153
--- Comment #9 from Rainer Orth ---
"ro at CeBiTec dot Uni-Bielefeld.DE"
> --- Comment #8 from Rainer Orth ---
[...]
>>> However, there are quite a number of regressions in the binutils
>>> testsuite:
>>
https://sourceware.org/bugzilla/show_bug.cgi?id=29292
--- Comment #2 from Rainer Orth ---
> --- Comment #1 from Rainer Orth ---
> I'll try to create a minimal testcase (just tmpfile, mmap, fill buffer, msync,
> munmap, fread) to see if the problem reproduces there.
Here's what I've got:
#inclu
https://sourceware.org/bugzilla/show_bug.cgi?id=33153
--- Comment #8 from Rainer Orth ---
> --- Comment #6 from Nick Clifton ---
Hi Nick,
> I have decided to split the patch into two. The changes to the bfd/ files
> fix the actual bug, so they make one patch, and the changes to common.h are
>
https://sourceware.org/bugzilla/show_bug.cgi?id=33153
--- Comment #3 from Rainer Orth ---
> --- Comment #1 from Nick Clifton ---
Hi Nick,
> Please could you try out this patch and let me know if it works ?
>
> It is a bit of a guess on my part, but I think that it has potential.
it didn't
https://sourceware.org/bugzilla/show_bug.cgi?id=32580
--- Comment #19 from Rainer Orth ---
> --- Comment #18 from Stefan Bidigaray ---
> I ran into this issue last month, as well. I was able to track down the
> problem
> to ksh93 itself. A bug report was filed with the maintained version of ksh
https://sourceware.org/bugzilla/show_bug.cgi?id=32580
--- Comment #15 from Rainer Orth ---
> --- Comment #14 from Nick Clifton ---
> Created attachment 15903
> --> https://sourceware.org/bugzilla/attachment.cgi?id=15903&action=edit
> Another proposed patch
Hi Nick,
sorry for the delay: I was
https://sourceware.org/bugzilla/show_bug.cgi?id=32580
--- Comment #1 from Rainer Orth ---
> I'm still trying to figure out what exactly caused this. So far I've found
> that the the problem started with
>
> commit fe217087a4b8aa214a221ca9f033c5fcdbcee90e
> Author: Nick Clifton
> Date: Wed Nov
https://sourceware.org/bugzilla/show_bug.cgi?id=12263
--- Comment #3 from Rainer Orth ---
> --- Comment #2 from Tom Tromey ---
> Is this still a problem?
> I see zlib in the binutils source tree now.
I happen to have a Solaris 8/x86 VM around and gave building binutils
2.41 with gcc 4.7 (the la
https://sourceware.org/bugzilla/show_bug.cgi?id=29512
--- Comment #3 from Rainer Orth ---
> --- Comment #2 from H.J. Lu ---
> Created attachment 14288
> --> https://sourceware.org/bugzilla/attachment.cgi?id=14288&action=edit
> A patch
>
> Try this.
I've just successfully completed a i386-pc-s
https://sourceware.org/bugzilla/show_bug.cgi?id=29424
--- Comment #5 from Rainer Orth ---
> --- Comment #4 from Rainer Orth ---
> I've just spotchecked ld 2.38.90 with that patch included with my
> testcase: the link worked fine (or rather failed as expected due to the
> missing __atomic_* symbo
https://sourceware.org/bugzilla/show_bug.cgi?id=29424
--- Comment #4 from Rainer Orth ---
> --- Comment #2 from Nick Clifton ---
Hi Nick,
> Unfortunately the reproducer fails for me due to lots of missing system
> libraries. Not surprising really given that I was running the test on an
> x86
https://sourceware.org/bugzilla/show_bug.cgi?id=29411
--- Comment #7 from Rainer Orth ---
> --- Comment #6 from Rainer Orth ---
>> --- Comment #5 from Nick Clifton ---
>> (In reply to Rainer Orth from comment #4)
>>
>>> I missed this, although I saw the initial discussion about this warning
>>>
https://sourceware.org/bugzilla/show_bug.cgi?id=29411
--- Comment #6 from Rainer Orth ---
> --- Comment #5 from Nick Clifton ---
> (In reply to Rainer Orth from comment #4)
>
>> I missed this, although I saw the initial discussion about this warning
>> fly by. However, this is not a Solaris/SPA
https://sourceware.org/bugzilla/show_bug.cgi?id=29411
--- Comment #4 from Rainer Orth ---
> --- Comment #2 from Nick Clifton ---
> Hi Rainer,
>
> The warning is intended to alter users to the fact that a segment has been
> created with all three permission flags set - something that is very te
https://sourceware.org/bugzilla/show_bug.cgi?id=27666
--- Comment #7 from Rainer Orth ---
> --- Comment #5 from Joel Brobecker ---
> (Thanks Nick for the patch)
Indeed, thanks a lot.
However, I think we can do better than disabling the ld sparc*tests on
Solaris. Even if we omit support for th
https://sourceware.org/bugzilla/show_bug.cgi?id=27666
--- Comment #6 from Rainer Orth ---
> --- Comment #5 from Joel Brobecker ---
> (Thanks Nick for the patch)
>
> Hi Rainer,
>
> If I read Nick's patch correctly, I think things should be back to normal
> again
> in terms of behavior, thus no l
https://sourceware.org/bugzilla/show_bug.cgi?id=27666
--- Comment #3 from Rainer Orth ---
> --- Comment #2 from Nick Clifton ---
> Created attachment 13455
> --> https://sourceware.org/bugzilla/attachment.cgi?id=13455&action=edit
> Proposed patch
Hi Nick,
sorry for the long delay: I've been
https://sourceware.org/bugzilla/show_bug.cgi?id=27666
--- Comment #1 from Rainer Orth ---
When I tried a sparcv9-sun-solaris2.11 build of gdb master in
preparation for the upcoming GDB 11 release, I found that the impact of
this bug is way greater than just a couple of binutils testsuite
failures
https://sourceware.org/bugzilla/show_bug.cgi?id=25802
--- Comment #3 from Rainer Orth ---
> --- Comment #2 from Nick Clifton ---
> Hi Rainer,
>
>> I wonder how best to handle this: bfd/elfxx-sparc.c
>> (_bfd_sparc_elf_relocate_section) already silently ignores the overflow in a
>> few select c
https://sourceware.org/bugzilla/show_bug.cgi?id=25732
--- Comment #14 from Rainer Orth ---
> --- Comment #13 from H.J. Lu ---
> (In reply to Rainer Orth from comment #11)
>
>> >> That leaves us with the two pr20995-2 ones...
>> >
>> > Does Solaris support GNU_RELRO? If not, I can skip these for
https://sourceware.org/bugzilla/show_bug.cgi?id=25732
--- Comment #11 from Rainer Orth ---
> --- Comment #10 from H.J. Lu ---
>> FAIL: ld-ifunc/ifunc-23a-x86
>> FAIL: ld-ifunc/ifunc-24a-x86
>> FAIL: ld-ifunc/ifunc-25a-x86
>>
>> the last three are highly dubious: Solaris ld.so.1 doesn't support
https://sourceware.org/bugzilla/show_bug.cgi?id=25732
--- Comment #8 from Rainer Orth ---
> --- Comment #6 from H.J. Lu ---
> I stopped checking Solaris cross target since the result isn't clean.
> If Solaris cross target test becomes clean, I will test Solaris cross
I doubt I will be able to
https://sourceware.org/bugzilla/show_bug.cgi?id=25732
--- Comment #5 from Rainer Orth ---
> --- Comment #4 from John Levon ---
> It's only the last 5 for me (running natively, but illumos not Solaris)
That's most likely because gld testing assumes a gcc configured to use
gld without an explicit
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #22 from Rainer Orth ---
> --- Comment #21 from H.J. Lu ---
[...]
> I didn't see R_386_TLS_TPOFF. What happened to
>
> 0030 0b12 R_386_TLS_GD 0004
> __gcov_indirect_call_callee
>
> in input file?
This:
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #20 from Rainer Orth ---
> --- Comment #19 from H.J. Lu ---
[...]
> What doe Solaris ld generate?
Here are the initial sections of with either linker:
* gas-gld:
08048ff0 <__gcov_indirect_call_profiler_v2>:
8048ff0: 55
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #18 from Rainer Orth ---
> --- Comment #17 from H.J. Lu ---
> Please try users/hjl/solaris branch at
>
> https://github.com/hjl-tools/binutils-gdb
Any reason not to keep that branch in the binutils-git repo on
sourceware? That's
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #15 from Rainer Orth ---
> --- Comment #14 from H.J. Lu ---
[...]
> Please provide all linker inputs so that I
> can reproduce i it on Linux.
Now available at
https://www.cebitec.uni-bielefeld.de/~ro/files/pr13671.tar.bz
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #12 from Rainer Orth ---
While it fixes the two failing ld testcases, during a gcc mainline
bootstrap I get man errors:
FAIL: gcc.dg/pr47793.c (test for excess errors)
Excess errors:
/vol/gcc/bin/gld-2.30.51-tls: BFD (GNU Binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #10 from Rainer Orth ---
As a first step, I've enabled ld-i386/tls.exp and ld-x86_64/tls.exp on
Solaris/x86 and ran the respective tests. The x86_64 tests all PASS,
while for i386 I see the known failure case:
FAIL: TLS GD/LD ->
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #7 from Rainer Orth ---
> --- Comment #6 from H.J. Lu ---
[...]
> Please provide one separate testcase in assembly code for each instance
> where ld creates dynamic relocs Solaris ld.so.1 cannot handle.
I'm trying, but I have a h
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #5 from Rainer Orth ---
I don't think it needs to: gcc is careful only to emit those tls relocs
that the whole toolchain (assembler + linker) can handle. See
TARGET_SUN_TLS, HAVE_AS_IX86_TLSLDMPLT, and HAVE_AS_IX86_TLSGDPLT. So
f
https://sourceware.org/bugzilla/show_bug.cgi?id=13671
--- Comment #3 from Rainer Orth ---
> --- Comment #2 from H.J. Lu ---
> These TLS transitions should be disabled for Solaris.
> Does Solaris support Linux TLS relocations without
> TLS transitions?
The full docs on what Solaris does support
https://sourceware.org/bugzilla/show_bug.cgi?id=22727
--- Comment #21 from Rainer Orth ---
> --- Comment #20 from Eric Botcazou ---
> Please give it a try on Solaris.
I just tried gcc mainline with the top of the binutils 2.30 branch on
Solaris 11.4: worked like a charm.
Thanks.
Rainer
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #11 from Rainer Orth ---
> --- Comment #10 from H.J. Lu ---
> Please try:
>
> https://sourceware.org/ml/binutils/2018-01/msg00293.html
As a quick test, I've just rebuilt binutils with that patch and ran the
failing LTO test and t
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #8 from Rainer Orth ---
> --- Comment #7 from H.J. Lu ---
[...]
> What are the commend-line options passed to ld?
ld -plugin ./liblto_plugin.so -plugin-opt=./lto-wrapper \
-plugin-opt=-fresolution=-plugin-save-temps.res \
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #6 from Rainer Orth ---
> --- Comment #3 from H.J. Lu ---
[...]
> Please do
>
> 1. Get users/hjl/lto-mixed/master branch and build/install it.
> 2. Pass -v -save-temps -Wl,-plugin-save-temps to gcc
> This should save all temporary
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #4 from Rainer Orth ---
> --- Comment #3 from H.J. Lu ---
[...]
>> The static tests fail because there are no libc.a and libm.a on Solaris,
>> so full-static linking just isn't possible. Testing static linking when
>> the platfor
https://sourceware.org/bugzilla/show_bug.cgi?id=22727
--- Comment #2 from Rainer Orth ---
> --- Comment #1 from H.J. Lu ---
> Does Linux/Sparc work? Are there any regressions in binutils
I've no idea and no way to test.
> testsuite on Solaris/Sparc?
That will take a bit to determine: I'll ne
https://sourceware.org/bugzilla/show_bug.cgi?id=22721
--- Comment #2 from Rainer Orth ---
> --- Comment #1 from H.J. Lu ---
> A couple questions:
>
> 1. Do all tests under ld/testsuite/ld-i386 pass on Solaris?
No, but that's a preexisting condition:
FAIL: Build libno-plt-1b.so
FAIL: No PLT (dy
https://sourceware.org/bugzilla/show_bug.cgi?id=21251
--- Comment #7 from Rainer Orth ---
> --- Comment #6 from Nick Clifton ---
Hi Nick,
>>> Hmm, I was going to say not a lot, but then I remembered that GCC uses it:
>>>
>>>https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
>>
>> Ma
https://sourceware.org/bugzilla/show_bug.cgi?id=21251
--- Comment #5 from Rainer Orth ---
Hi Nick,
> Great - I have checked the patch in.
excellent, thanks.
>> Btw., do you have any idea how widespread the use of '=' for the sysroot
>> prefix is?
>
> Hmm, I was going to say not a lot, but then
https://sourceware.org/bugzilla/show_bug.cgi?id=21251
--- Comment #2 from Rainer Orth ---
Hi Nick,
sorry for the very long delay in replying ;-(
Yes, works like a charm, thanks.
Btw., do you have any idea how widespread the use of '=' for the sysroot
prefix is? It's kinda hard to search for -
https://sourceware.org/bugzilla/show_bug.cgi?id=20989
--- Comment #2 from Rainer Orth ---
> --- Comment #1 from Alan Modra ---
> How is crt1.o testing that __start_crt_compiler is undefined? I'm talking
> about an "if (foo)" test used in a call to a weak function:
> if (foo)
> foo ();
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=20427
--- Comment #8 from Rainer Orth ---
Two more data points in addition to what Ali has discovered:
* In addition to gas emitting those 64-bit relocs for 32-bit objects, I
tried to build libtest32.so from Stefan's testcase with mainline gcc
https://sourceware.org/bugzilla/show_bug.cgi?id=20118
--- Comment #4 from Rainer Orth ---
> --- Comment #3 from Alan Modra ---
> Fixed.
Great, thanks for the blazingly fast fix.
Rainer
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://sourceware.org/bugzilla/show_bug.cgi?id=19520
--- Comment #12 from Rainer Orth ---
> --- Comment #8 from H.J. Lu ---
> (In reply to Rainer Orth from comment #7)
>> > --- Comment #4 from H.J. Lu ---
>> > Please checkout users/hjl/pr19520/master branch. I added a
>> > configure-time opti
https://sourceware.org/bugzilla/show_bug.cgi?id=19520
--- Comment #7 from Rainer Orth ---
> --- Comment #4 from H.J. Lu ---
> Please checkout users/hjl/pr19520/master branch. I added a
> configure-time option, --enable-new-x86-relocations, and a
> run-time option, -mnew-relocations=.
I've succ
https://sourceware.org/bugzilla/show_bug.cgi?id=19520
--- Comment #2 from Rainer Orth ---
> --- Comment #1 from H.J. Lu ---
> Please open a Solaris linker request to support R_386_GOT32X,
> R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. Then we discuss
> how to address it, depending on the resp
: ld
Assignee: unassigned at sourceware dot org
Reporter: ro at CeBiTec dot Uni-Bielefeld.DE
Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
Build: i386-pc-solaris2.11
While testing a new Solaris/x86 assembler that does support cfi
http://sourceware.org/bugzilla/show_bug.cgi?id=15056
--- Comment #22 from Rainer Orth
2013-02-01 09:31:00 UTC ---
The bootstrap has now concluded without regressions, so all is certainly
fine.
Thanks again.
Rainer
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=ema
http://sourceware.org/bugzilla/show_bug.cgi?id=15056
--- Comment #21 from Rainer Orth
2013-01-31 12:22:42 UTC ---
This fixed the full libstdc++.so testcase. I'm now running a full gcc
mainline bootstrap to check that no other problems turn up.
Many thanks to both of you for the quick resolutio
http://sourceware.org/bugzilla/show_bug.cgi?id=15056
--- Comment #5 from Rainer Orth 2013-01-30
09:31:13 UTC ---
The reghunt identified the following patch as the culprit:
2011-12-07 Alan Modra
PR ld/12772
* elflink.c (elf_gc_sweep_symbol): Discard unmarked symbols
defi
http://sourceware.org/bugzilla/show_bug.cgi?id=15056
--- Comment #4 from Rainer Orth 2013-01-24
13:25:16 UTC ---
> --- Comment #3 from David S. Miller 2013-01-23
> 21:34:17 UTC ---
> Indeed, my change is in the 2.22 release, I just double checked.
Seems like I'll have to run a reghunt to find
http://sourceware.org/bugzilla/show_bug.cgi?id=15057
--- Comment #2 from Rainer Orth 2013-01-24
13:16:08 UTC ---
> --- Comment #1 from Alan Modra 2013-01-24 01:40:40
> UTC ---
> Create a link map for one of these failing tests (-Wl,-Map,). Look
> in to see what sections (or data!) are going
http://sourceware.org/bugzilla/show_bug.cgi?id=13255
--- Comment #3 from Rainer Orth 2011-10-14
11:46:00 UTC ---
> --- Comment #2 from H.J. Lu 2011-10-10 15:55:01
> UTC ---
> Please try the current binutils 2.22 branch.
Sorry for the delay: I've now re-bootstrapped gcc mainline as of
20111007
http://sourceware.org/bugzilla/show_bug.cgi?id=13254
--- Comment #3 from Rainer Orth 2011-10-14
11:41:38 UTC ---
Sorry for the delay: the patch works like a charm.
Thanks.
Rainer
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving thi
http://sourceware.org/bugzilla/show_bug.cgi?id=12987
--- Comment #2 from Rainer Orth 2011-07-12
18:47:23 UTC ---
One issue I forgot: when build a 64-bit gold to perform 64-bit testing
(which otherwise fails in many ways, e.g. due to trying to link
libgold.a), I had to remove the static from the
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #24 from Rainer Orth
2011-03-14 19:40:31 UTC ---
I've had a look at the two remaining errors (apart from not having
static system libs on newer Solaris releases):
gcctestdir/ld: internal error in override_version, at
/vol/gnu/src/
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #23 from Rainer Orth
2011-03-11 15:40:46 UTC ---
> --- Comment #21 from Ian Lance Taylor 2011-03-09
> 01:56:59 UTC ---
[...]
> I committed a patch which should fix the problem of passing too many values to
> readv.
That fixes al
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #22 from Rainer Orth
2011-03-09 09:49:09 UTC ---
> --- Comment #21 from Ian Lance Taylor 2011-03-09
> 01:56:59 UTC ---
> There's not much point to trying to use gold to build gcc until gold passes at
> least most of its tests.
O
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #18 from Rainer Orth
2011-03-08 14:39:08 UTC ---
> --- Comment #17 from Ian Lance Taylor 2011-03-08
> 14:28:19 UTC ---
> Thanks. I would also be interesting in knowing whether gold can pass its
> tests
> with the patch I sent,
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #16 from Rainer Orth
2011-03-08 14:14:01 UTC ---
> --- Comment #15 from Ian Lance Taylor 2011-03-08
> 14:10:34 UTC ---
> What is the value of IOV_MAX on Solaris? The man page implies that it is
> defined in some header file, per
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #14 from Rainer Orth
2011-03-08 10:18:43 UTC ---
"ian at airs dot com" writes:
> --- Comment #13 from Ian Lance Taylor 2011-03-08
> 05:33:07 UTC ---
> Created attachment 5280
> --> http://sourceware.org/bugzilla/attachment.cgi
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #10 from Rainer Orth
2011-03-07 19:10:06 UTC ---
> --- Comment #9 from Ian Lance Taylor 2011-03-04
> 19:08:43 UTC ---
> output.cc does #include . gold is always compiled with
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Those
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #8 from Rainer Orth 2011-03-04
14:48:43 UTC ---
> --- Comment #7 from Ian Lance Taylor 2011-03-03
> 16:39:12 UTC ---
> The intention of the code is that the file is guaranteed to be large enough by
> the call to posix_fallocate i
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #6 from Rainer Orth 2011-03-03
15:19:05 UTC ---
> --- Comment #4 from Ian Lance Taylor 2011-03-02
> 06:03:01 UTC ---
> It is possible that gdb is misleading in saying .
> I
> don't know. The address should be allocated via the
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #5 from Rainer Orth 2011-03-03
14:54:39 UTC ---
> --- Comment #3 from Ian Lance Taylor 2011-03-02
> 05:59:33 UTC ---
> Yes, gold should recognize -dy. That's a bug.
Should I file a separate PR for that?
Rainer
--
Configu
http://sourceware.org/bugzilla/show_bug.cgi?id=12525
--- Comment #2 from Rainer Orth 2011-03-01
14:45:36 UTC ---
> --- Comment #1 from Ian Lance Taylor 2011-03-01
> 14:29:45 UTC ---
> At least part of the problem is that gold does not support the -dy option.
> That is interpreted as the -d op
http://sourceware.org/bugzilla/show_bug.cgi?id=12320
--- Comment #6 from Rainer Orth 2011-02-16
17:51:03 UTC ---
> --- Comment #5 from Alan Modra 2011-02-15 23:54:45
> UTC ---
> So http://sourceware.org/ml/binutils/2010-03/msg00017.html broke --as-needed.
>
> I did ask why you wanted to follow
http://sourceware.org/bugzilla/show_bug.cgi?id=12320
--- Comment #4 from Rainer Orth 2011-02-15
12:44:52 UTC ---
> --- Comment #3 from Alan Modra 2011-02-15 12:01:45
> UTC ---
> In crt1.o
> 15: 0 NOTYPE WEAK DEFAULT UND _DYNAMIC
> In libgcc_s.so
>154: 00018fd0 0 OB
http://sourceware.org/bugzilla/show_bug.cgi?id=12253
--- Comment #6 from Rainer Orth 2010-11-25
16:31:44 UTC ---
> --- Comment #5 from Alan Modra 2010-11-24 05:34:22
> UTC ---
> http://sourceware.org/ml/binutils/2010-11/msg00431.html
> http://sourceware.org/ml/binutils-cvs/2010-11/msg00150.htm
http://sourceware.org/bugzilla/show_bug.cgi?id=12264
--- Comment #2 from Rainer Orth 2010-11-25
16:15:10 UTC ---
Excellent, thanks.
Rainer
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC li
http://sourceware.org/bugzilla/show_bug.cgi?id=12253
--- Comment #3 from Rainer Orth 2010-11-23
16:01:49 UTC ---
> --- Comment #2 from Alan Modra 2010-11-23 13:34:02
> UTC ---
> I took a look at this today. Besides the sorting problem, elf-eh-frame.c gets
> DW_EH_PE_datarel wrong. datarel is
http://sourceware.org/bugzilla/show_bug.cgi?id=12181
--- Comment #1 from Rainer Orth 2010-11-05
17:28:24 UTC ---
Parallel to filing this PR, I've contacted the Solaris linker
maintainers. Here's Ali Bahrami's analysis, cited by permission:
--
91 matches
Mail list logo
