[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug gas/18427] GNU as slow on hppa architecture
From: |
dave.anglin at bell dot net |
Subject: |
[Bug gas/18427] GNU as slow on hppa architecture |
Date: |
Wed, 03 Jun 2015 19:02:24 +0000 |
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
0000000000000000 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 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS 0000000000000000 00000040
0000000000000000 0000000000000000 AX 0 0 1
[ 2] .data PROGBITS 0000000000000000 00000040
0000000000000000 0000000000000000 WA 0 0 1
[ 3] .bss NOBITS 0000000000000000 00000040
0000000000000000 0000000000000000 WA 0 0 1
[ 4] sec▒▒tion PROGBITS 0000000000000000 00000040
0000000000000009 0000000000000000 0 0 1
[ 5] .shstrtab STRTAB 0000000000000000 000000ea
0000000000000036 0000000000000000 0 0 1
[ 6] .symtab SYMTAB 0000000000000000 00000050
0000000000000090 0000000000000018 7 6 8
[ 7] .strtab STRTAB 0000000000000000 000000e0
000000000000000a 0000000000000000 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 Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 SECTION LOCAL DEFAULT 1
2: 0000000000000000 0 SECTION LOCAL DEFAULT 2
3: 0000000000000000 0 SECTION LOCAL DEFAULT 3
4: 0000000000000000 0 SECTION LOCAL DEFAULT 4
5: 0000000000000000 0 NOTYPE LOCAL DEFAULT 4 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.