[Bug gas/20803] Sparc R_SPARC_32 reloc with miss-align offset.
https://sourceware.org/bugzilla/show_bug.cgi?id=20803 --- Comment #6 from Chris Johns --- (In reply to Chris Johns from comment #5) > I have just tested binutils 2.27 with the patch and 2.28 that contains this > patch and the issue is back. The reloc details from readelf are: This was a bug in the RTEMS ELF loader. I am sorry about the noise. -- 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 gas/20803] Sparc R_SPARC_32 reloc with miss-align offset.
https://sourceware.org/bugzilla/show_bug.cgi?id=20803 --- Comment #5 from Chris Johns --- I have just tested binutils 2.27 with the patch and 2.28 that contains this patch and the issue is back. The reloc details from readelf are: Relocation section '.rela.gcc_except_table.exception_dl' at offset 0x51cc contains 2 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 0040 2a03 R_SPARC_32 _ZTISt9exception + 0 0044 2403 R_SPARC_32 _ZTI16dl_test_throw_me + 0 Relocation section '.rela.rodata._ZTI16dl_test_throw_me' at offset 0x51e4 contains 2 entries: Offset InfoTypeSym. Value Symbol's Name + Addend 2c03 R_SPARC_32 _ZTVN10__cxxabiv117__class_type_infoE + 8 0004 2b03 R_SPARC_32 _ZTS16dl_test_throw_me + 0 The R_SPARC_32 should be R_SPARC_UA32. I do not know how we reopen this bug. -- 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 gas/20803] Sparc R_SPARC_32 reloc with miss-align offset.
https://sourceware.org/bugzilla/show_bug.cgi?id=20803 --- Comment #2 from Chris Johns --- (In reply to Nick Clifton from comment #1) > Created attachment 9623 [details] > Proposed patch Thank you for the quick turn around. > > Please could you try out this patch and let me know if it is enough to > solve the problem. > Yes, this solves the problem we are seeing. > I am not sure if this approach is the correct way to fix the issue, but it > does seem to be the simplest. As far as I can tell, the relocs in the > .eh_frame section can eb unaligned, so using R_SPARC_UA32 seems to be the > correct thing to do. I did look to see if I could enable > sparc_no_align_cons when fixing the output for the .eh_frame section, but I > could not find an easy way to do this. Hence I went for a hack based on the > section name. Not very subtle, but if it works then that is enough for now. I also had a look and felt any change was a potential issue for some other reason I would not be aware of. We will use this patch in RTEMS until the next binutils release. Thank you. -- 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 gas/20803] New: Sparc R_SPARC_32 reloc with miss-align offset.
https://sourceware.org/bugzilla/show_bug.cgi?id=20803 Bug ID: 20803 Summary: Sparc R_SPARC_32 reloc with miss-align offset. Product: binutils Version: 2.27 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: chrisj at rtems dot org Target Milestone: --- Created attachment 9621 --> https://sourceware.org/bugzilla/attachment.cgi?id=9621=edit Sparc ASM showing the miss-aligned R_SPARC_32 reloc offset. I am looking into: https://devel.rtems.org/ticket/2802 where a R_SPARC_32 reloc record with a miss-aligned offset results in a crash. We do not expect a R_SPARC_32 to be miss-aligned. The source is: https://git.rtems.org/rtems/tree/testsuites/libtests/dl05/dl-o5.cpp It seems like emit_expr_fix is being called and it calls TC_CONS_FIX_NEW() without the sparc_no_align_cons being true so R_SPARC_32 reloc type is selected in cons_fix_new_sparc. I do not know if this is an issue in selecting the reloc type, ie sparc_no_align_cons should be true, or the offset should never be miss-aligned. I attach a .s source file that shows the issue. It has been edited removing the .debug output from gcc. -- 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/19222] New: Undefined behavoour in tc-arm.c:encode_arm_immediate with Xcode 7.1
https://sourceware.org/bugzilla/show_bug.cgi?id=19222
Bug ID: 19222
Summary: Undefined behavoour in tc-arm.c:encode_arm_immediate
with Xcode 7.1
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: chrisj at rtems dot org
Target Milestone: ---
The function 'encode_arm_immediate' in tc-arm.c does not compile RTEMS 4.11 ARM
GCC on OS X. The error reported is:
../../../../gcc-4.9.3/libgcc/config/arm/ieee754-df.S: Assembler messages:
../../../../gcc-4.9.3/libgcc/config/arm/ieee754-df.S:567: Error: invalid
constant (ff) after fixup
../../../../gcc-4.9.3/libgcc/config/arm/ieee754-df.S:673: Error: invalid
constant (ff) after fixup
../../../../gcc-4.9.3/libgcc/config/arm/ieee754-df.S:689: Error: invalid
constant (fd) after fixup
../../../../gcc-4.9.3/libgcc/config/arm/ieee754-df.S:875: Error: invalid
constant (ff) after fixup
../../../../gcc-4.9.3/libgcc/config/arm/ieee754-df.S:912: Error: invalid
constant (fd) after fixup
../../../../gcc-4.9.3/libgcc/config/arm/ieee754-df.S:985: Error: invalid
constant (fd) after fixup
The error has been reported to Apple and they have have said the error is due
to undefined behaviour in the function. A possible solution is:
@@ -9,7 +9,7 @@ encode_arm_immediate (unsigned int val)
printf("val = %08x\n", val);
for (i = 0; i < 32; i += 2)
-if ((a = (val << i | val >> (32 - i))) <= 0xff)
+if ((a = (val << i | (i == 0 ? 0:val >> (32 - i <= 0xff)
return a | (i << 7);
return (-1);
--
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/19222] Undefined behavoour in tc-arm.c:encode_arm_immediate with Xcode 7.1
https://sourceware.org/bugzilla/show_bug.cgi?id=19222 Chris Johns changed: What|Removed |Added CC||joel.sherrill at oarcorp dot com Host||OS X -- 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/6483] objdump -g does not understand the debug info
--- Additional Comments From chrisj at rtems dot org 2008-06-26 02:14 --- Hi Nick, Please excuse the delay in getting back to this bug. We looked into this bug more and found the i386 tools worked fine while the m68k do not. Further it seems -g works and -e does not. If I build RTEMS with --target=i386-rtems4.9 using the RTEMS tools obtained by yum on a Fedora Core 8 64bit box, install RTEMS I can extract the debug symbols with : $ i386-rtems4.9-objdump -e librtemsbsp.a In archive librtemsbsp.a: !_TAG_FILE_FORMAT 2 /extended format/ !_TAG_FILE_SORTED 0 /0=unsorted, 1=sorted/ !_TAG_PROGRAM_AUTHORIan Lance Taylor, Salvador E. Tropea and others // !_TAG_PROGRAM_NAME objdump /From GNU binutils/ New compilation unit: /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:int32 char /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:int8 long int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:int32 unsigned int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:uint32 long unsigned int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:uint32 long long int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:int64 long long unsigned int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:uint64 short int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:int16 short unsigned int /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:uint16 signed char /opt/work/sw/rtems/src/head/c/src/lib/libbsp/i386/pc386/../../shared/bootcard.c 0; kind:t type:int8 Same command run with m68k tools on a --target=m68k-rtems4.9 build of RTEMS I get: $ m68k-rtems4.9-objdump -e librtemsbsp.a In archive librtemsbsp.a: m68k-rtems4.9-objdump: bootcard.o: no recognized debugging information m68k-rtems4.9-objdump: bspclean.o: no recognized debugging information m68k-rtems4.9-objdump: bsplibc.o: no recognized debugging information m68k-rtems4.9-objdump: bsppost.o: no recognized debugging information m68k-rtems4.9-objdump: bsppredriverhook.o: no recognized debugging information m68k-rtems4.9-objdump: bspstart.o: no recognized debugging information [snipped] Regards Chris -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sourceware.org/bugzilla/show_bug.cgi?id=6483 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6483] New: objdump -g does not understand the debug info
Using the M68K RTEMS 4.9 tool set from the RTEMS repo installed with yum the following occurs for the m68k target: $ m68k-rtems4.9-gcc -g -c -o hello.o hello.c $ m68k-rtems4.9-objdump -g hello.o hello.o: file format elf32-m68k m68k-rtems4.9-objdump: hello.o: no recognized debugging information The object file can be linked into an RTEMS application that can be debugged with gdb and objdump can disassemble the object with source. The objdump -W displays the DWARF info. The RTEMS tools can be located here: http://www.rtems.org/wiki/index.php/APT/Yum_Repository -- Summary: objdump -g does not understand the debug info Product: binutils Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: chrisj at rtems dot org CC: bug-binutils at gnu dot org GCC build triplet: x86_64-redhat-linux-gnu GCC host triplet: x86_64-redhat-linux-gnu GCC target triplet: m68k-unknown-rtems4.9 http://sourceware.org/bugzilla/show_bug.cgi?id=6483 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
