[Bug gprof/23698] Possible access of unintended macro in "gprof/gprof.c" line 455
https://sourceware.org/bugzilla/show_bug.cgi?id=23698 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Petru-Florin, > Shouldn't you use STYLE_EXEC_COUNTS instead of STYLE_ANNOTATED_SOURCE? Yes. :-) Thanks for reporting this. I have checked in the obvious fix for the problem. 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 gprof/23698] Possible access of unintended macro in "gprof/gprof.c" line 455
https://sourceware.org/bugzilla/show_bug.cgi?id=23698 --- Comment #1 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=a0389de085c9caca66ec53bcf7faf830cbf24b89 commit a0389de085c9caca66ec53bcf7faf830cbf24b89 Author: Nick Clifton Date: Mon Oct 1 17:17:54 2018 +0100 Fix typo setting user_specified variable when parsing -Z option. PR 23698 * gprof.c (main): Fix typo setting user_specified variable when parsing -Z option. -- 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/23699] ihex output fails for mipsel-elf-objcopy
https://sourceware.org/bugzilla/show_bug.cgi?id=23699 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi rhn, (In reply to rhn from comment #1) > Created attachment 11269 [details] > Workaround checking for signedness [Sorry I have not had time to look at this, but...] > The bfd_target struct could be extended, to carry some signedness about the > input bfd. If the bfd_target's flavour is bfd_target_elf_flavour then you can cast bfd target's backend field to a struct elf_backend_data pointer (or use the xvec_get_elf_backend_data macro). Then you can access the sign_extend_vma field, which will be set for targets like the MIPS which use signed address ranges. 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 gas/23719] sumo || w3ll squad
https://sourceware.org/bugzilla/show_bug.cgi?id=23719 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |INVALID --- Comment #1 from Nick Clifton --- spam -- 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/23731] New: Building from git issues Ubuntu
https://sourceware.org/bugzilla/show_bug.cgi?id=23731
Bug ID: 23731
Summary: Building from git issues Ubuntu
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jg at jguk dot org
Target Milestone: ---
1)
Is there a way for ./configure to check for "makeinfo" "bison" "flex" commands
first? I just get it bailing out at the end half way through a build. I imagine
everyone else on Ubuntu sees the same as me... Impacts new developers getting
started
gcc -c -I. -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-Wstack-usage=262144 -Werror -I./../zlib -g -O2 -Wno-error ./syslex_wrap.c
./syslex_wrap.c:25:10: fatal error: syslex.c: No such file or directory
#include "syslex.c"
^~
compilation terminated.
As bison, flex, makeinfo commands a really needed, and they mess with the files
generated which must be cleaned... could these be checked up front?
2) After "bison" and "flex" I saw this error:
I got this error:
configure: loading cache ./config.cache
configure: error: `YACC' has changed since the previous run:
configure: former value: `/home/jonny/code/binutils-gdb/missing bison -y'
configure: current value: `bison -y'
configure: error: in `/home/jonny/code/binutils-gdb/binutils':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start
over
Makefile:3527: recipe for target 'configure-binutils' failed
make[1]: *** [configure-binutils] Error 1
make[1]: Leaving directory '/home/jonny/code/binutils-gdb'
Makefile:849: recipe for target 'all' failed
make: *** [all] Error 2
Even the following commands did not clear it:
make distclean
./configure --program-prefix=dev
I'm 20 mins in.. and still no working build.
3)
I saw some warnings wizz past from -Wmaybe-uninitialized
CXXmacrotab.o
In file included from infrun.c:26:0:
inferior.h: In function ‘void handle_vfork_child_exec_or_exit(int)’:
inferior.h:567:26: warning: ‘*((void*)(&
maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
{ set_current_inferior (m_saved_inf); }
~^
infrun.c:931:6: note: ‘*((void*)(&
maybe_restore_inferior)+40).scoped_restore_current_inferior::m_saved_inf’ was
declared here
maybe_restore_inferior;
^~
In file included from inferior.h:49:0,
from infrun.c:26:
progspace.h:285:31: warning: ‘*((void*)(&
maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’
may be used uninitialized in this function [-Wmaybe-uninitialized]
{ set_current_program_space (m_saved_pspace); }
~~^~~~
infrun.c:931:6: note: ‘*((void*)(&
maybe_restore_inferior)+32).scoped_restore_current_program_space::m_saved_pspace’
was declared here
maybe_restore_inferior;
^~
CXXmain.o
Also i noticed the build stopped once after "make -j16", but then "make" on its
own, did a lot more compiling for several minutes... could be a build race
condition.
--
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/23699] ihex output fails for mipsel-elf-objcopy
https://sourceware.org/bugzilla/show_bug.cgi?id=23699 --- Comment #3 from rhn --- Hi Nick, the target bfd is actually bfd_target_ihex_flavor, which is at the core of the issue. One of the solutions I was thinking about was to create an ihex backend with only the signedness information in it. That would still require ihex-specific changes in the copy procedure somewhere though. I couldn't easily identify where those would be needed, but I'm happy to dig deeper if you think it's the way forward. Thanks for taking a look, rhn -- 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/23729] PROVIDE inside --start-group/--end-group overrides defined symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=23729 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #1 from Alan Modra --- I believe the changed behaviour is simply a bug fix. Consider how --start-group libfunc.a main.o -T export.ld --end-group should work. On the first iteration over object files: - libfunc.a is searched for symbols that define currently undefined symbols, none are found so no object files are extracted, - main.o symbols are loaded, giving an undefined "func", - export.ld is processed, which provides "func". Since --start-group/--end-group wrap these three files, the library is searched again for symbols that define currently undefined symbols, but "func" is now defined (by the PROVIDE) so the object is not extracted.. Similar analysis applied to -T export.ld --start-group libfunc.a main.o --end-group or --start-group libfunc.a main.o --end-group -T export.ld says the linker is working properly there too. The older binutils did not process the export.ld "PROVIDE" statement early enough to define "func". You could probably see this difference between binutils-2.26 and current binutils without --start-group/--end-group with main.o -T export.ld libfunc.a Thus a documentation change for --start-group/--end-group is not appropriate. -- 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/23648] Symbols based on MEMORY regions confuse --gc-sections.
https://sourceware.org/bugzilla/show_bug.cgi?id=23648 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.32 -- 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/23727] ld with custom sysroot ignores original rpath
https://sourceware.org/bugzilla/show_bug.cgi?id=23727 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #1 from Alan Modra --- See https://sourceware.org/ml/binutils/2017-03/msg00134.html. You want a different behaviour to the people that posted that patch. I agreed with them then, and still do, that it is incorrect for ld to search outside of a sysroot. -- 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/23727] ld with custom sysroot ignores original rpath
https://sourceware.org/bugzilla/show_bug.cgi?id=23727 --- Comment #2 from Nehal J Wani --- Alan, thanks your for response. If that is the case, then what's the preferred/recommended way of linking target libraries which don't reside in the sysroot using a cross linker? -- 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/23727] ld with custom sysroot ignores original rpath
https://sourceware.org/bugzilla/show_bug.cgi?id=23727 Nehal J Wani changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Nehal J Wani --- I read through the conversation on the mailing list. Further observations: - If I do add -Wl,-rpath-link,$PWD/libs the link succeeds. - If I use the gold linker, the link succeeds. -Wl,-fuse-ld=gold If you think that not searching out of the sysroot at all is the correct behavior, then why is it restricted only to -rpath and not applied to -rpath-link? Why is the behavior of the cross gold linker different? My use case is simple. I want to cross compile let's say libssh2 for a target architecture and I have the libcrypto.so and libz.so dependencies already compiled for the target architecture kept in /path/to/some/prefix/libs. While compiling libssh2, I want to link against those libraries. Why am I expected to keep them in the sysroot always? Does it not defeat the whole purpose of having -rpath in the first place? Does this not seem like a valid use case? -- 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/23704] Too many PT_LOAD segments with -z separate-code
https://sourceware.org/bugzilla/show_bug.cgi?id=23704 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #1 from Alan Modra --- I agree that moving read-only (and relro) sections is a good idea, but it may not work for targets that have limited addressing and use offsets from a register to access .got, .got.plt, .plt and .sdata. Any target that uses the same register to access sections on both sides of DATA_SEGMENT_RELRO_END will likely not be able to tolerate moving read-only sections. -- 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
