[Bug gold/13213] New: Gold does not support the BE-8 big-endian variant of the ARM architecture
http://sourceware.org/bugzilla/show_bug.cgi?id=13213 Bug #: 13213 Summary: Gold does not support the BE-8 big-endian variant of the ARM architecture Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: mgret...@sourceware.org Classification: Unclassified Target: arm-none-eabi Gold only supports the BE-32 (word-invariant) big-endian variant of the ARM architecture (supported in v4, v5, and optionally v6). v6 and v7 introduce BE-8 variant (byte invariant). One of the major features of the BE-8 variant is that all instructions are in little-endian format, whereas they are big-endian in BE-32. The ABI (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044d/IHI0044D_aaelf.pdf) section 5.5.1 says that object files are produced in BE-32 format and when the linker produces a BE-8 executable image it byte reverses instructions back to little endian format (word-by-word for ARM, half-word-by-half-word for Thumb). BE-8 executable files have the processor specific flag EF_ARM_BE8 set on the image. The implication of this is that currently Gold cannot produce images that will run correctly in big-endian mode on ARM v7-A CPUs. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13214] New: Gold does emit mapping symbols for stubs
http://sourceware.org/bugzilla/show_bug.cgi?id=13214 Bug #: 13214 Summary: Gold does emit mapping symbols for stubs Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: mgret...@sourceware.org Classification: Unclassified Target: arm-none-eabi Given the following testcase: @tmp.s .syntax unified .thumb .section sect1, "ax" .globl _start _start: bl bar .section sect2, "ax" .globl bar .arm bar: bx lr @end of tmp.s Doing the following: arm-none-eabi-as -march=armv5t tmp.s -o tmp.o arm-none-eabi-ld.gold tmp.o -o tmp --section-start sect2=0x1000 \ --section-start sect1=0x0400 arm-none-eabi-objdump -d tmp Produces the following output: 1000 <_start>: 1000: f000 e800 blx 1004 <_start+0x4> 1004: f004 e51f ; instruction: 0xf004e51f 1008: movsr0, r0 100a: 0400lslsr0, r0, #16 The instruction at 0x1004 is actually an ARM instruction (and so should have a $a mapping symbol). The 'instructions' at 0x1008 and 0x100a are actually a word of data, and so should have a $d mapping symbol. Not emitting these mapping symbols is technically in contravention of the ABI, and makes disassembly harder to read, but in the majority of cases won't impact correct execution of images. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13214] Gold does emit mapping symbols for stubs
http://sourceware.org/bugzilla/show_bug.cgi?id=13214 --- Comment #1 from Matthew Gretton-Dann 2011-09-21 15:05:31 UTC --- Typo in the command lines above: arm-none-eabi-ld.gold tmp.o -o tmp --section-start sect1=0x1000 \ --section-start sect2=0x0400 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 --- Comment #1 from Vincenzo Innocente 2011-09-21 16:50:18 UTC --- any news on a solution of this kind of problem? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 --- Comment #2 from Sriraman Tallam 2011-09-21 16:52:53 UTC --- Sorry, I did not get a chance to look at this yet. I will take a look at it this week. Thanks, -Sri. On Wed, Sep 21, 2011 at 9:50 AM, vincenzo.innocente at cern dot ch wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=12919 > > --- Comment #1 from Vincenzo Innocente > 2011-09-21 16:50:18 UTC --- > any news on a solution of this kind of problem? > > -- > Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. > You are the assignee for the bug. > -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 Sriraman Tallam changed: What|Removed |Added CC||iant at google dot com --- Comment #3 from Sriraman Tallam 2011-09-21 18:57:08 UTC --- It is about pre-emptible symbols and libstdcxx makes namespace std as visiblity default. It is working as intended. Let me explain with an example first. If you have two functions foo and bar, calling zip and zap. If foo and bar are in a shared object and exported in the dynamic symbol table, it is not correct to fold foo and bar even though zip and zap get folded. Simple reason, zip and zap can be pre-empted by another definition in the executable. So, the ICF algorithm would only fold foo and bar if they both called functions with the same name. Here, the 3 introsort_loop functions essentially point to different move_median* functions (the functions differ in their names), for A, B and C. The move_median functions themselves get folded, but since they are exported, icf thinks they can be pre-empted and in theory they can. So, it will not fold the introsort_loop functions. However, if you were to link this into an executable, the introsort_loop functions would be folded. However, pre-emption of these functions maybe never happens in practice. So, I could add a flag to icf that disables preemption and the introsort_loop functions would be folded. I am not sure if this is the right thing to do. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 --- Comment #4 from Sriraman Tallam 2011-09-21 18:58:03 UTC --- It is about pre-emptible symbols and libstdcxx makes namespace std as visiblity default. It is working as intended. Let me explain with an example first. If you have two functions foo and bar, calling zip and zap. If foo and bar are in a shared object and exported in the dynamic symbol table, it is not correct to fold foo and bar even though zip and zap get folded. Simple reason, zip and zap can be pre-empted by another definition in the executable. So, the ICF algorithm would only fold foo and bar if they both called functions with the same name. Here, the 3 introsort_loop functions essentially point to different move_median* functions (the functions differ in their names), for A, B and C. The move_median functions themselves get folded, but since they are exported, icf thinks they can be pre-empted and in theory they can. So, it will not fold the introsort_loop functions. However, if you were to link this into an executable, the introsort_loop functions would be folded. However, pre-emption of these functions maybe never happens in practice. So, I could add a flag to icf that disables preemption and the introsort_loop functions would be folded. I am not sure if this is the right thing to do. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Ian Lance Taylor 2011-09-21 19:55:58 UTC --- I think you actually could combine functions within a .so. Although the symbols are preemptible, if one of them is actually preempted, it will be done by redirecting the PLT entry. So as long as you provide separate PLT entries for each symbol, you could arrange for all the PLT entries to point, by default, to the same code. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 --- Comment #6 from Vincenzo Innocente 2011-09-21 19:58:07 UTC --- Thanks for the detailed analysis that indeed makes sense in the general case. In this specific example introsort_loop is not inlined just for choice of a gcc heuristics. My understanding was that with -fvisibility-inlines-hidden I made the 3 move_median_first and the 3 introsort_loop functions "internals" to the library and therefore neither visible nor preempt-able. maybe they need to be declared "inline" in gcc or even "hidden"? In any case I do not think that they are ment to be preempt-able! -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 --- Comment #7 from Sriraman Tallam 2011-09-21 21:25:45 UTC --- The std namespace is marked explicity with default visibility. So, these symbols are exported no matter what. If you do hide those symbols the folding will work. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12919] icf fails to fold one of the component of std::sort
http://sourceware.org/bugzilla/show_bug.cgi?id=12919 Paolo Carlini changed: What|Removed |Added CC||pcarlini at gmail dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13213] Gold does not support the BE-8 big-endian variant of the ARM architecture
http://sourceware.org/bugzilla/show_bug.cgi?id=13213 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com AssignedTo|ian at airs dot com |dougkwan at google dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13214] Gold does emit mapping symbols for stubs
http://sourceware.org/bugzilla/show_bug.cgi?id=13214 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com AssignedTo|ian at airs dot com |dougkwan at google dot com -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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
