Changes done in binutils revision
Hi, I had done porting using binutils 2.26. Now I want to move to binutils 2.27. Can someone help me, how can I check what all changes are done from 2.26 to 2.27. I do not know how to use git. I want to know what all changes are done for x86-64. Thanks, Parul ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22249] objdump --dwarf-start can be very slow
https://sourceware.org/bugzilla/show_bug.cgi?id=22249 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ae7e78255666733d238e676a0bab14986a1483dd commit ae7e78255666733d238e676a0bab14986a1483dd Author: Nick Clifton Date: Tue Oct 10 13:37:58 2017 +0100 Improve the speed of the --dwarf-start option by skipping processing of any comp unit that ends before the specified start address. PR 22249 * dwarf.c (process_debug_info): Skip any comp unit that ends before dwarf_start_die. -- 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/22249] objdump --dwarf-start can be very slow
https://sourceware.org/bugzilla/show_bug.cgi?id=22249 --- Comment #6 from Nick Clifton --- Hi Tom, OK, well your patch is fine, so I have checked that in. I still think that we need to improve the documentation however. Do you have any suggestions ? Cheers Nick -- 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/22249] objdump --dwarf-start can be very slow
https://sourceware.org/bugzilla/show_bug.cgi?id=22249 --- Comment #7 from Tom Tromey --- (In reply to Nick Clifton from comment #6) > Hi Tom, > > OK, well your patch is fine, so I have checked that in. I still think > that we need to improve the documentation however. Do you have any > suggestions ? I will look, but I'd appreciate it if you could look at the dwarf-mode.el patches that I also posted to the list. Alan had already approved this dwarf.c patch; but I wanted to push them all together, because the whole reason I wrote this change is to work in conjunction with the mode changes so I can actually dig into this problem I'm having... Thanks. -- 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/22249] objdump --dwarf-start can be very slow
https://sourceware.org/bugzilla/show_bug.cgi?id=22249 --- Comment #8 from Nick Clifton --- Hi Tom, > https://sourceware.org/bugzilla/show_bug.cgi?id=22249 > I will look, but I'd appreciate it if you could look at the dwarf-mode.el > patches that I also posted to the list. Alan had already approved > this dwarf.c patch; but I wanted to push them all together, because > the whole reason I wrote this change is to work in conjunction with the > mode changes so I can actually dig into this problem I'm having... Sure - I will take a look, but please could you point me at the email ? Cheers Nick -- 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/22249] objdump --dwarf-start can be very slow
https://sourceware.org/bugzilla/show_bug.cgi?id=22249 --- Comment #9 from Tom Tromey --- Thread starts here: https://sourceware.org/ml/binutils/2017-10/msg00082.html -- 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/22249] objdump --dwarf-start can be very slow
https://sourceware.org/bugzilla/show_bug.cgi?id=22249 --- Comment #10 from Nick Clifton --- Hi Tom, > Thread starts here: > > https://sourceware.org/ml/binutils/2017-10/msg00082.html All the changes look fine to me, apart from one. Patch 2/5 has: +(defvar dwarf-mode-map + (let ((map (make-sparse-keymap))) +(set-keymap-parent special-mode-map) +(define-key map [(control ?m)] #'dwarf-insert-substructure) +map) + "Keymap for dwarf-mode buffers.") But when I tried to byte compile this function (using emacs 25.3.1) there was this warning message: dwarf-mode.el:186:6:Warning: set-keymap-parent called with 1 argument, but requires 2 I am not an emacs expert, but maybe this could be a problem ? Actually - on a related note - would you be interested in becoming the official maintainer for dwarf-mode.el ? Then you could make changes to the file without having to prod slow pokes like me. :-) Cheers Nick -- 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/21402] i386: indirect5 failures
https://sourceware.org/bugzilla/show_bug.cgi?id=21402 --- Comment #11 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Renlin Li : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6c699715f68be7d8c468e965fbefce997f7ed937 commit 6c699715f68be7d8c468e965fbefce997f7ed937 Author: Renlin Li Date: Mon Sep 25 11:41:54 2017 +0100 [ARM] PR ld/21402, only override the symbol dynamic decision on undefined weak symbol. Similar as aarch64 backend, arm backend only overrides the decision on undefined weak symbols. arm backend part already emits necessary relative relocation for this case. bfd/ PR ld/21402 * elf32-arm.c (allocate_dynrelocs_for_symbol): Only make undefined weak symbols into dynamic. ld/ PR ld/21402 * testsuite/ld-arm/tls-app.d: Update address. * testsuite/ld-arm/tls-app.r: Remove relocations. * testsuite/ld-arm/unresolved-1-dyn.d: Update. -- 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/22249] objdump --dwarf-start can be very slow
https://sourceware.org/bugzilla/show_bug.cgi?id=22249 --- Comment #11 from Tom Tromey --- (In reply to Nick Clifton from comment #10) > dwarf-mode.el:186:6:Warning: set-keymap-parent called with 1 argument, but > requires 2 > > I am not an emacs expert, but maybe this could be a problem ? Yeah. I wonder why I didn't see this. I've fixed it. > Actually - on a related note - would you be interested in becoming > the official maintainer for dwarf-mode.el ? That would be great. -- 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/22269] Undefined weak symbols isn't resolved to 0 in static PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=22269 --- Comment #9 from Alan Modra --- > Since call is PC relative, this doesn't branch to address 0. I don't see why this matters. A symbol that resolves to zero without dynamic relocs in a PIE or shared lib results in an address of zero. If that zero is in a PC-relative instruction then you get zero relative to the shared library or PIE base. Typical code for dealing with weakly defined functions like if (foo) foo (); will give you a load of zero (absolute) on the condition, but a relative zero for the call. > This doesn't work with > > -pie --no-dynamic-linker -z dynamic-undefined-weak Define "doesn't work". I would have said that combination of options ought to result in a dynamic reloc for "func" on the original testcase. Which is what powerpc will do. It may not work in the runtime environment for static PIE, but that's a different issue. By passing -z dynamic-undefined-weak you asked for dynamic relocs! -- 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/22269] Undefined weak symbols isn't resolved to 0 in static PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=22269 --- Comment #10 from H.J. Lu --- (In reply to Alan Modra from comment #9) > > Since call is PC relative, this doesn't branch to address 0. > > I don't see why this matters. A symbol that resolves to zero without > dynamic relocs in a PIE or shared lib results in an address of zero. If > that zero is in a PC-relative instruction then you get zero relative to the > shared library or PIE base. Typical code for dealing with weakly defined > functions like > if (foo) > foo (); > will give you a load of zero (absolute) on the condition, but a relative > zero for the call. If there is a program bug: foo (); without if (foo) check, PC relative branch to base may not crash and may lead to undesired behavior. > > This doesn't work with > > > > -pie --no-dynamic-linker -z dynamic-undefined-weak > > Define "doesn't work". I would have said that combination of options ought > to result in a dynamic reloc for "func" on the original testcase. Which is > what powerpc will do. It may not work in the runtime environment for static > PIE, but that's a different issue. By passing -z dynamic-undefined-weak you > asked for dynamic relocs! -z dynamic-undefined-weak applies to there is a DT_NEEDED entry which may provide definition for undefined weak reference at run-time. For static PIE, weak undefined should always be resolved to 0. -- 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/22269] Undefined weak symbols isn't resolved to 0 in static PIE
https://sourceware.org/bugzilla/show_bug.cgi?id=22269 --- Comment #11 from Alan Modra --- > If there is a program bug: > ... > may lead to undesired behavior. Quite so. > -z dynamic-undefined-weak applies if there is a DT_NEEDED entry which > may provide definition for undefined weak reference at run-time. For static > PIE, weak undefined should always be resolved to 0. I agree, which is why I felt it was a good idea to default link_info.dynamic_undefined_weak to 0 when link_info.nointerp. Also, --no-dynamic-linker -z dynamic-undefined-weak probably ought to be an error, or at least warn. However, making that change (or explicitly passing -z nodynamic-undefined-weak) results in x86 tests that fail, due to not generating a plt entry for the undefined weak call. No matter how I look at it, that is a bug in the x86 backend: link_info.dynamic_undefined_weak should not control the generation of a plt entry. (I'm also of the opinion that adding a plt entry for an undefined weak without dynamic relocs is just bloat, but that's a separate issue and one I don't care to argue about.) -- 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
