[Bug binutils/19310] New: src/binutils/dwarf.c:6459: code relies on undefined behaviour ?
https://sourceware.org/bugzilla/show_bug.cgi?id=19310 Bug ID: 19310 Summary: src/binutils/dwarf.c:6459: code relies on undefined behaviour ? Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dcb314 at hotmail dot com Target Milestone: --- [src/binutils/dwarf.c:6459]: (warning) Invalid test for overflow 'start+ul= block_end || start + ul > block_end || start + ul < start) -- 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/19311] New: arm-linux-as build on Mac OS X with Xcode7 fails to assemble code from FreePascal cross-compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=19311
Bug ID: 19311
Summary: arm-linux-as build on Mac OS X with Xcode7 fails to
assemble code from FreePascal cross-compiler
Product: binutils
Version: 2.25
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: tonne1.schindler at web dot de
Target Milestone: ---
arm-linux-as build on Mac OS X with the command line tools from Xcode 7 fails
to assemble code from FreePascal cross-compiler, whereas everything goes
smooth, if the binutils are built with Xcode 6.
This is the relevant part of the log:
/BlaBla/fpc_fixes_3_0/compiler/ppcrossarm -Ur -Tlinux -Parm -XParm-linux- -Xr
-Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE.
-FU/BlaBla/fpc_fixes_3_0/rtl/units/arm-linux -ap -darm -dRELEASE -Us -Sg
system.pp
system.inc(1824,8) Warning: Implicit string type conversion from
"RawByteString" to "UnicodeString"
{standard input}: Assembler messages:
{standard input}:69: Error: invalid constant (7f) after fixup
and many more so.
simply executing "arm-linux-as string.s" yields the same error or not depending
on the version of xcode.
I checked config.status and config.log in gas and could not find any relevant
difference. The binutils are built with --target=arm-linux and --disable-werror
--disable-nls. I tried some modications of the configure options, but they did
not make any difference.
Karl-Michael Schindler
--
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/19311] arm-linux-as build on Mac OS X with Xcode7 fails to assemble code from FreePascal cross-compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=19311 Kar-Michael Schindler changed: What|Removed |Added Target||arm-linux Host||darwin -- 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/19315] New: addr2line change for C++ symbols breaks behavior for inlined functions
https://sourceware.org/bugzilla/show_bug.cgi?id=19315 Bug ID: 19315 Summary: addr2line change for C++ symbols breaks behavior for inlined functions Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: pcarroll at codesourcery dot com Target Milestone: --- Created attachment 8818 --> https://sourceware.org/bugzilla/attachment.cgi?id=8818&action=edit C++ test case This issue is a side effect of the change for bug #17541 (https://sourceware.org/bugzilla/show_bug.cgi?id=17541). That change was to have addr2line (through the use of BFD dwarf2.c) identify C++ symbols in debug information that could be missing namespace, class, and other information but have no linkage name, and then find a matching symbol in the ELF symbol table. I compiled my enclosed test case with g++ 5.2.0, with the '-g -O2' options, for ARM Linux. I then inspected the DWARF2 information for my resulting executable and found the debug information for my 'main' subprogram. The DWARF2 information then showed 2 following inlined functions. The first inlined function mapped to the 'func1' class member, which had a linkage name of '_Z5func1i'. The second inlined function mapped to the 'myfunc' C function, which has no linkage name. In my example, the low_pc address for 'myfunc' is 0x103cc. (I'm not sure there is a way to figure out the appropriate address without just inspecting an executable. So, of course, I would expect a different address for a test case compiled with a different toolchain.) With that in mind, I run addr2line 2.25.51 on the resulting executable, with the arguments '-f -i -e addr2test2 103ce', so it maps into the innermost function. This produces the following output: main /bug/addr2test2.h:4 _Z5func1i /bug/addr2test2.cpp:23 main /bug/addr2test2.cpp:32 As we can see, this returns the name of the outermost function 'main' rather than the innermost function 'myfunc' for the first function name. When I investigated this issue, I believe it ties into the code at the end of '_bfd_dwarf2_find_nearest_line'. There, the code checks if is_linkage is set for a function. If not (i.e., it is C++ or similar), then a call to '_bfd_elf_find_function' is made. That will find a symbol in the ELF symbol table, which is, of course, the outermost function name. The inlined function names are not found by this means. That is not a problem if the linkage name is present. But that is not always the case, such as for an inlined C function, as occurred here. I believe this can be avoided by modifying '_bfd_elf_find_function' in dwarf2.c, to have it return a pointer to the symbol that is found. Then, after '_bfd_elf_find_function' is called for symbols without a linkage symbol, the value of the ELF symbol is compared against the DWARF's low_pc value. The test I used was: if ((matching_sym->value+section->vma) == function->arange.low) I'm not sure if that is the best way to see if these addresses are the same, but that worked for me. If the addresses are the same, then using the ELF symbol is appropriate. If the addresses are different, though, then the DWARF2 symbol is appropriate. That is true whether the symbol is an embedded C function, such as is my example, or it is a C++ symbol that has no linkage name and is somehow missing namespace, class, or other information. Some information seems better than wrong information. When I ran my modified addr2line function, I got the following output: myfunc /bug/addr2test2.h:4 _Z5func1i /bug/addr2test2.cpp:23 main /bug/addr2test2.cpp:32 That, I think, is the best we can hope for. And that also matches what is seen with addr2line 2.24.51. -- 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/19311] arm-linux-as build on Mac OS X with Xcode7 fails to assemble code from FreePascal cross-compiler
https://sourceware.org/bugzilla/show_bug.cgi?id=19311 --- Comment #1 from Kar-Michael Schindler --- A test with gcc5 produces a working arm-linux-as. Therefore, i suspect whacky code in as, which accidentally works with some compilers and not with others. Some hints point to defines of subarchs or thumb vs arm code or similar, but this is too involved for me to resolve it. Michael. -- 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 ld/19317] New: plugin needed to handle lto object should not be output for plugin generated files when doing incremental link
https://sourceware.org/bugzilla/show_bug.cgi?id=19317 Bug ID: 19317 Summary: plugin needed to handle lto object should not be output for plugin generated files when doing incremental link Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Hi, the implementation of IL linking in GCC is currently blocked by this. When compiling with gcc -r the linker plugin claims the LTO files and uses GCC to merge them into one LTO file which is then streamed. It would be great to fix ld and gold to not complain about this. Honza -- 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/19315] addr2line change for C++ symbols breaks behavior for inlined functions
https://sourceware.org/bugzilla/show_bug.cgi?id=19315 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com -- 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
