[Bug gas/18427] GNU as slow on hppa architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=18427
--- Comment #6 from dave.anglin at bell dot net ---
Hi Nick,
On 2015-06-01 4:01 AM, nickc at redhat dot com wrote:
https://sourceware.org/bugzilla/show_bug.cgi?id=18427
--- Comment #5 from Nick Clifton nickc at redhat dot com ---
Hi Dave,
Thanks for helping with this change.
I'm not sure about the option. Alpha has somewhat similar code without
an option.
As I understand it, this code is to handle a number of instructions
which require a preceding
label. It usually emitted on the previous line. It seems to me that
changing segments between
the label and its related instruction should be an error. I don't think
this feature is needed
even for the HP-UX SOM target.
I will check whether GCC needs this for SOM.
OK - thanks. If you can confirm that support for this behaviour is no
longer needed then I will be happy to go with the simpler patch. (Or
maybe the simpler one + an error message if the preceding label cannot
be found). I just did not want to break anybody's builds because of a
speed optimization,
Attached is a change to implement the above handling for the last label.
The gas testsuite for the hpux SOM target is clean. There are four
fails with 64-bit
hpux ELF target. None of these appear related to the change. Haven't
tested linux yet.
The 64-bit gas fails are:
FAIL: gas/all/none
FAIL: Multibyte symbol names
FAIL: weak and common directives
FAIL: common and weak directives
The latter two are caused by the behavior of the .comm directive. These
two would pass
with foobar label before the .comm.
We have for gas/all/none:
# ../as-new -o dump.o none.s
# /opt/gnu64/bin/objdump -r -w dump.o
dump.o: file format elf64-hppa
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
R_PARISC_PCREL64 *ABS*
We have for Multibyte symbol names:
# ../as-new -o dump.o syms.s
# /opt/gnu64/bin/readelf -S -s -p .strtab dump.o
There are 8 section headers, starting at offset 0x120:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .text PROGBITS 0040
AX 0 0 1
[ 2] .data PROGBITS 0040
WA 0 0 1
[ 3] .bss NOBITS 0040
WA 0 0 1
[ 4] sec▒▒tion PROGBITS 0040
0009 0 0 1
[ 5] .shstrtab STRTAB 00ea
0036 0 0 1
[ 6] .symtab SYMTAB 0050
0090 0018 7 6 8
[ 7] .strtab STRTAB 00e0
000a 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Symbol table '.symtab' contains 6 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 SECTION LOCAL DEFAULT1
2: 0 SECTION LOCAL DEFAULT2
3: 0 SECTION LOCAL DEFAULT3
4: 0 SECTION LOCAL DEFAULT4
5: 0 NOTYPE LOCAL DEFAULT4 sy▒▒mbol
String dump of section '.strtab':
[tx] sy▒▒mbol
Dave
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/18482] New: inconsistent bfd-plugins directory for cross-compiler tools
https://sourceware.org/bugzilla/show_bug.cgi?id=18482 Bug ID: 18482 Summary: inconsistent bfd-plugins directory for cross-compiler tools Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: ossman at cendio dot se Target Milestone: --- The path to the bfd-plugins directory is computed a bit wonky when you're building binutils for cross-compilation, resulting in it looking in two different locations depending on how you call it. Basically it always looks for it as progdir/../lib/bfd-plugins. The problem is that progdir will be bindir if you call target-nm, but tooldir/bin if you call nm (in the tooldir directory). IOW, e.g. an ARM cross compiler will look in these two places: /usr/bin/../bin/../lib/bfd-plugins /usr/arm-none-linux-gnueabi/bin/../bin/../lib/bfd-plugins Besides the fact that I now have to dump plugins in two places, I'm also concerned that all my different binutils share /usr/lib/bfd-plugins. Does gcc's LTO plugin handle every possible target? Or will I have to put every gcc's plugin in there under different names? And will binutils pick the right one? I'd suggest to use the tooldir directory for cross-compilers in order to avoid confusion. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/15370] linker script does not group sections correctly when building ppc64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=15370 Cary Coutant ccoutant at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Cary Coutant ccoutant at gmail dot com --- Fixed on trunk. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/15370] linker script does not group sections correctly when building ppc64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=15370 --- Comment #2 from cvs-commit at gcc dot gnu.org cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant ccout...@sourceware.org: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=374082dfab280123f5a54a23b1c1b2cb893b4d2b commit 374082dfab280123f5a54a23b1c1b2cb893b4d2b Author: Cary Coutant ccout...@gmail.com Date: Wed Jun 3 19:11:42 2015 -0700 Fix gold to group sections correctly via linker script. In PR 15370, it is noted that gold does not distinguish between *(.foo .bar) and *(.foo) *(.bar) in linker scripts. In both cases, gold groups all .foo sections together, followed by all .bar sections, whereas in the first case, it should collect all .foo and .bar sections in the order seen. If you add sort specs, the Gnu linker has some bizarre corner cases that I do not try to replicate. In particular, *(SORT_BY_NAME(.foo) SORT_BY_NAME(.bar)) does the same thing as *(.foo) *(.bar). But if you apply a sort spec to just one of several patterns, say, *(SORT_BY_NAME(.foo) .bar), the Gnu linker will collect any .bar section it sees before the first .foo, then all .foo sections, then all remaining .bar sections. With this patch, if any of the input patterns have a sort spec, gold will group them all as it did before; e.g., all .foo sections followed by all .bar sections. 2015-06-03 Cary Coutant ccout...@gmail.com gold/ PR gold/15370 * script-sections.cc (Output_section_element_input::set_section_addresses): When there are several patterns with no sort spec, put all sections in the same bin. * testsuite/Makefile.am (script_test_12): New testcase. (script_test_12i): New testcase. * testsuite/Makefile.in: Regenerate. * testsuite/script_test_12.t: New test linker script. * testsuite/script_test_12i.t: New test linker script. * testsuite/script_test_12a.c: New test source file. * testsuite/script_test_12b.c: New test source file. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/15370] linker script does not group sections correctly when building ppc64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=15370 --- Comment #4 from Anton Blanchard anton at samba dot org --- Thanks Cary, with your fix I was able to boot a ppc64el kernel built with gold. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
