[Bug gas/26253] Support SHF_LINK_ORDER with sh_link=0
https://sourceware.org/bugzilla/show_bug.cgi?id=26253 --- Comment #4 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=b71702f1c01052b70b4fd8157982eadc2132fc24 commit b71702f1c01052b70b4fd8157982eadc2132fc24 Author: Nick Clifton Date: Mon Oct 5 10:40:07 2020 +0100 GAS: Update the .section directive so that a numeric section index can be provided when the "o" flag is used. PR 26253 gas * config/obj-elf.c (obj_elf_section): Accept a numeric value for the "o" section flag. Interpret it as a section index. Allow an index of zero. * doc/as.texi: Document the new behaviour. * NEWS: Mention the new feature. Tidy entries. * testsuite/gas/elf/sh-link-zero.s: New test. * testsuite/gas/elf/sh-link-zero.d: New test driver. * testsuite/gas/elf/elf.exp: Run the new test. * testsuite/gas/elf/section21.l: Updated expected assembler output. bfd * elf.c (_bfd_elf_setup_sections): Do not complain about an sh_link value of zero when the SLF_LINK_ORDER flag is set. (assign_section_numbers): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26253] Support SHF_LINK_ORDER with sh_link=0
https://sourceware.org/bugzilla/show_bug.cgi?id=26253 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- (In reply to Fangrui Song from comment #3) > LLVM's integrated assembler hard codes 0 but I think supporting other > numerical indexes is fine. Yeah - I doubt if the new feature will ever be used to set an index other than zero, but I could not think of a good reason to prevent other numbers from being accepted. Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26705] MODRM isn't properly handled
https://sourceware.org/bugzilla/show_bug.cgi?id=26705 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0e9f3bf12616b108682bb6f6e2a5ef04df9586a8 commit 0e9f3bf12616b108682bb6f6e2a5ef04df9586a8 Author: H.J. Lu Date: Mon Oct 5 05:23:29 2020 -0700 x86: Clear modrm if not needed The MODRM byte can be checked to display the instruction name only if the MODRM byte needed. Clear modrm if the MODRM byte isn't needed so that modrm field checks in putop like, modrm.mod == N with N != 0, can be done without checking need_modrm. gas/ PR binutils/26705 * testsuite/gas/i386/x86-64-suffix.s: Add "mov %rsp,%rbp" before sysretq. * testsuite/gas/i386/x86-64-suffix-intel.d: Updated. * testsuite/gas/i386/x86-64-suffix.d: Likewise. opcodes/ PR binutils/26705 * i386-dis.c (print_insn): Clear modrm if not needed. (putop): Check need_modrm for modrm.mod != 3. Don't check need_modrm for modrm.mod == 3. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26704] Missing the 'l' suffix for sysret in 64-bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=26704
--- Comment #1 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by H.J. Lu :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5b316d90e4ec9845a890fd21ad86cf1043fb2ca3
commit 5b316d90e4ec9845a890fd21ad86cf1043fb2ca3
Author: H.J. Lu
Date: Mon Oct 5 05:27:58 2020 -0700
x86-64: Always display suffix for %LQ in 64bit
In 64bit, assembler generates a warning for "sysret":
$ echo sysret | as --64 -o x.o -
{standard input}: Assembler messages:
{standard input}:1: Warning: no instruction mnemonic suffix given and no
register operands; using default for `sysret'
Always display suffix for %LQ in 64bit to display "sysretl".
gas/
PR binutils/26704
* testsuite/gas/i386/noreg64-data16.d: Expect sysretl instead of
sysret.
* testsuite/gas/i386/noreg64.d: Likewise.
* testsuite/gas/i386/x86-64-intel64.d: Likewise.
* testsuite/gas/i386/x86-64-opcode.d: Likewise.
opcodes/
PR binutils/26704
* i386-dis.c (putop): Always display suffix for %LQ in 64bit.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26704] Missing the 'l' suffix for sysret in 64-bit mode
https://sourceware.org/bugzilla/show_bug.cgi?id=26704 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.36 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from H.J. Lu --- Fixed for 2.36. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26705] MODRM isn't properly handled
https://sourceware.org/bugzilla/show_bug.cgi?id=26705 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |2.36 --- Comment #2 from H.J. Lu --- Fixed for 2.36. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26694] gas x86-32: "can't handle non absolute segment in `lcall'" (or `ljmp')
https://sourceware.org/bugzilla/show_bug.cgi?id=26694 --- Comment #11 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6d96a5946d1ec76fea79bc36aa95d7d3dd304200 commit 6d96a5946d1ec76fea79bc36aa95d7d3dd304200 Author: T.K. Chia Date: Mon Oct 5 05:46:23 2020 -0700 i386: Allow non-absolute segment values for lcall/ljmp Allow an unresolved or non-absolute symbol as the segment operand of an immediate far jump (`ljmp SEG, OFF') or far call (`lcall SEG, OFF'). gas/ 2020-10-05 T.K. Chia PR gas/26694 * NEWS: Updated for i386 lcall and ljmp change. * config/tc-i386.c (output_interseg_jump): Allow non-absolute segment operand for immediate lcall and ljmp. * testsuite/gas/i386/jump.d, * testsuite/gas/i386/jump.s, * testsuite/gas/i386/jump16.d, * testsuite/gas/i386/jump16.e, * testsuite/gas/i386/jump16.s: Add tests for non-absolute segment operand for immediate ljmp. ld/ 2020-10-05 T.K. Chia PR gas/26694 * testsuite/ld-i386/ljmp.s, * testsuite/ld-i386/ljmp1.d, * testsuite/ld-i386/ljmp1.s, * testsuite/ld-i386/ljmp2.d, * testsuite/ld-i386/ljmp2.s, * testsuite/ld-x86-64/ljmp1.d, * testsuite/ld-x86-64/ljmp2.d: New testcases. * testsuite/ld-i386/i386.exp, * testsuite/ld-x86-64/x86-64.exp: Run them. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26694] gas x86-32: "can't handle non absolute segment in `lcall'" (or `ljmp')
https://sourceware.org/bugzilla/show_bug.cgi?id=26694 H.J. Lu changed: What|Removed |Added Resolution|--- |NOTABUG Target Milestone|--- |2.36 Status|NEW |RESOLVED --- Comment #12 from H.J. Lu --- Fixed for 2.36. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] Fix typos
Hi Samanta, Thanks very much for telling us about these typos. I have now applied your patch. Cheers Nick
[Bug binutils/26698] out of bounds access in mc_unify_path
https://sourceware.org/bugzilla/show_bug.cgi?id=26698 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Martin, Yep this is a bug. It looks like the coder was trying to check the last character in the string, rather than the first. IE they meant to use end[-1] instead of hsz[-1]. I have therefore checked in a patch to make this change. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26698] out of bounds access in mc_unify_path
https://sourceware.org/bugzilla/show_bug.cgi?id=26698 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Nick Clifton --- Patch applied -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26698] out of bounds access in mc_unify_path
https://sourceware.org/bugzilla/show_bug.cgi?id=26698 --- Comment #2 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=1f1845d435fd0886f5c5561df8922268d2dfaefc commit 1f1845d435fd0886f5c5561df8922268d2dfaefc Author: Nick Clifton Date: Mon Oct 5 16:09:00 2020 +0100 Fix compile time error building windmc, detected by gcc 11. PR 26698 * windmc.c (mc_unify_path): Fix typo checking character at end of pathname. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26701] Ability to suppress warnings due to tags in a library
https://sourceware.org/bugzilla/show_bug.cgi?id=26701 --- Comment #1 from Nick Clifton --- Hi Eyal, Yes, the linker could suppress these warnings. But the important point is that it is not at all clear that the linker should suppress them. The warnings are important, and the real way to get rid of them is to fix the code that is triggering them. Now I appreciate that this is not always possible. But as pointed out in PR 12017 there are several ways to work around the problem without modifying the linker. My stance is: why introduce new code, and potentially new bugs, to the linker when there are other ways of solving the problem. So, if you do want to get a change like this in, I think that you are going to need to drum up some support from the community. If enough people agree with you, then I will make the necessary changes. One important point however is that you ought to make sure that the LLVM community agrees with the idea too, and that they are willing to put it into their linker (LLD). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Bug ld/26701] New: Ability to suppress warnings due to tags in a library
Hi Eyal, Yes, the linker could suppress these warnings. But the important point is that it is not at all clear that the linker should suppress them. The warnings are important, and the real way to get rid of them is to fix the code that is triggering them. Now I appreciate that this is not always possible. But as pointed out in PR 12017 there are several ways to work around the problem without modifying the linker. My stance is: why introduce new code, and potentially new bugs, to the linker when there are other ways of solving the problem. So, if you do want to get a change like this in, I think that you are going to need to drum up some support from the community. If enough people agree with you, then I will make the necessary changes. One important point however is that you ought to make sure that the LLVM community agrees with the idea too, and that they are willing to put it into their linker (LLD). Cheers Nick
[Bug ld/26701] Ability to suppress warnings due to tags in a library
https://sourceware.org/bugzilla/show_bug.cgi?id=26701 --- Comment #2 from Eyal Rozenberg --- (In reply to Nick Clifton from comment #1) > Yes, the linker could suppress these warnings. But the important point > is that it is not at all clear that the linker should suppress them. Oh, but of course the linker shouldn't suppress them _by default_. We're only talking about an optional suppression. > The warnings are important, and the real way to get rid of them is to > fix the code that is triggering them. Warnings may be important. But - sometimes, they are acceptable, otherwise they'd be errors. It's not always the case that "real" way to avoid warnings is to avoid code with warning-trigger. Examples: * You may not have access to the code that's triggering them, which is buried deep in some library (whose functionality you require). * The problematic code may be mandated by certain policy in your organization * The code is only problematic under certain circumstances, but you actually guarantee that they never occur (e.g. in a wrapper function). > Now I appreciate that this is not always possible. It's also sometimes not even useful or desirable. > But as pointed out > in PR 12017 there are several ways to work around the problem without > modifying the linker. My stance is: why introduce new code, and > potentially new bugs, to the linker when there are other ways of solving > the problem. I respectfully disagree, for several reasons, the most important one being: It is a near-universal universal custom to allow silent non-erroneous operation of command-line-focused applications. More specifically - if a compiler lets you suppress warnings - so should the linker. Let me consider your suggested solutions: > *) You could post-process gcc's output and strip out the warning message. This is possible, but in any non-trivial setup - e.g. a build system like CMake or autotools, or a linker launched by another process and not by gcc or by me from the shell - it is somewhat complicated. Also, introduction of a wrapper script will almost certainly be required in many places, so it's actually quite a bit of work, repeatedly. Also - why should gcc or clang users not have to write wrapper scripts to suppress the warnings they get? > *) You could remove the offending section (.gnu.warning) from the C library > (in the tmpman.o archive element) This is actually a pretty bad idea. We don't want to have all sort of modified versions of the C library - nor have build systems start looking for these custom versions. And if we replaced the default one with a modified version - well, actually, no sysadmin in their right mind would let me do that, and if I did, I bet there would be all sorts of subtle breakage in binary packages. > *) You could use a custom linker script that discards the particular > .gnu.warning section. This requires a level of knowledge beyond that of most linker users, who don't even know what linker scripts are. > So, if you do want to get a change like this in, I think that you are > going to need to drum up some support from the community. If enough > people agree with you, then I will make the necessary changes. One > important point however is that you ought to make sure that the LLVM > community agrees with the idea too, and that they are willing to put > it into their linker (LLD). Well, I'm not really in the "build toolchain community", to be honest. But I can certainly file a similar bug against LLD. Remember, though, that this change requires little effort and does not change default behavior. The potential "normative drawback" is that introducing it will make it easier for people to be careless and just ignore all warnings straight away without ever considering them. If that is your main concern, then why not implement just (2.) and (3.), or even just (2.), to make people be specific, and thus make them be conscious of every suppression decision they make? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26706] New: pad strings in .dynstr
https://sourceware.org/bugzilla/show_bug.cgi?id=26706 Bug ID: 26706 Summary: pad strings in .dynstr Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: woodard at redhat dot com Target Milestone: --- There are times where it is necessary to patch ELF files so that they have correct paths to things. Most of the things that they want to be able to update are in the .dynstr section e.g. RPATH and RUNPATH. It would be helpful if the strings in .dynstr were padded with some additional space so that they could be lengthened not just shortened or remain the same length. Evidently Solaris used to do this and it was helpful. Can we either make ld pad these strings when it makes a binary by default or have an option to pad out these strings when linking so that we have some more room in the .dynstr section should we need to update paths. I do not know the best amount of padding. I bet that an extra 256 or 512 bytes per entry would be sufficient for all but the most unusual use cases. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26706] pad strings in .dynstr
https://sourceware.org/bugzilla/show_bug.cgi?id=26706 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26701] Ability to suppress warnings due to tags in a library
https://sourceware.org/bugzilla/show_bug.cgi?id=26701 --- Comment #3 from Kib --- (In reply to Nick Clifton from comment #1) > there are several ways to work around the problem without > modifying the linker. My stance is: why introduce new code, and > potentially new bugs, to the linker when there are other ways of solving > the problem. Because addressing this in the linker requires the solution to be put in one place and makes it easily accessible (via command-line switch) to all who want to use it. Any bugs introduced thus need only be fixed in one place. The workarounds require each user to develop his own custom solution to the same problem, increasing the complexity of development. And every one of these ad hoc solutions would have to be maintained and debugged separately. It's a basic application of the concept of modular design. Localize a recurringly needed solution in one place rather than requiring everyone to invent it independently. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26707] binutils on mingw-w64 for x86_64-elf target because of bison flex?
https://sourceware.org/bugzilla/show_bug.cgi?id=26707 cqwrteur changed: What|Removed |Added Target||x86_64-elf Host||windows. mingw-w64-x86_64 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26707] New: binutils on mingw-w64 for x86_64-elf target because of bison flex?
https://sourceware.org/bugzilla/show_bug.cgi?id=26707 Bug ID: 26707 Summary: binutils on mingw-w64 for x86_64-elf target because of bison flex? Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: euloanty at live dot com Target Milestone: --- In file included from ../../binutils-gdb/intl/plural.y:35: ../../binutils-gdb/intl/plural-exp.h:102:23: error: conflicting types for 'libintl_gettextparse' 102 | # define PLURAL_PARSE libintl_gettextparse | ^~~~ ../../binutils-gdb/intl/plural.y:40:25: note: in expansion of macro 'PLURAL_PARSE' 40 | # define __gettextparse PLURAL_PARSE | ^~~~ plural.c:200:5: note: in expansion of macro '__gettextparse' 200 | int __gettextparse (void); | ^~ ../../binutils-gdb/intl/plural-exp.h:102:23: note: previous declaration of 'libintl_gettextparse' was here 102 | # define PLURAL_PARSE libintl_gettextparse | ^~~~ ../../binutils-gdb/intl/plural-exp.h:114:12: note: in expansion of macro 'PLURAL_PARSE' 114 | extern int PLURAL_PARSE PARAMS ((void *arg)); |^~~~ ../../binutils-gdb/intl/plural-exp.h:102:23: error: conflicting types for 'libintl_gettextparse' 102 | # define PLURAL_PARSE libintl_gettextparse | ^~~~ ../../binutils-gdb/intl/plural.y:40:25: note: in expansion of macro 'PLURAL_PARSE' 40 | # define __gettextparse PLURAL_PARSE | ^~~~ plural.c:68:25: note: in expansion of macro '__gettextparse' 68 | #define yyparse __gettextparse | ^~ plural.c:1038:1: note: in expansion of macro 'yyparse' 1038 | yyparse (void) | ^~~ ../../binutils-gdb/intl/plural-exp.h:102:23: note: previous declaration of 'libintl_gettextparse' was here 102 | # define PLURAL_PARSE libintl_gettextparse | ^~~~ ../../binutils-gdb/intl/plural-exp.h:114:12: note: in expansion of macro 'PLURAL_PARSE' 114 | extern int PLURAL_PARSE PARAMS ((void *arg)); |^~~~ plural.c: In function 'libintl_gettextparse': plural.c:69:25: error: too few arguments to function '__gettextlex' 69 | #define yylex __gettextlex | ^~~~ plural.c:1216:16: note: in expansion of macro 'yylex' 1216 | yychar = yylex (&yylval); |^ plural.c:69:25: note: declared here 69 | #define yylex __gettextlex | ^~~~ ../../binutils-gdb/intl/plural.y:69:12: note: in expansion of macro 'yylex' 69 | static int yylex PARAMS ((YYSTYPE *lval, const char **pexp)); |^ ../../binutils-gdb/intl/plural.y:178:36: error: 'arg' undeclared (first use in this function) 178 | ((struct parse_args *) arg)->res = $1; |^~~ ../../binutils-gdb/intl/plural.y:178:36: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [Makefile:133: plural.o] Error 1 make[1]: *** [Makefile:6655: all-intl] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:866: all] Error 2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26667] Add powerpc64le-*-freebsd* support (elf64-powerpcle-freebsd)
https://sourceware.org/bugzilla/show_bug.cgi?id=26667 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6afcdeb3581e99e2d4ce06d0034c7c47292aeec1 commit 6afcdeb3581e99e2d4ce06d0034c7c47292aeec1 Author: Brandon Bergren Date: Tue Oct 6 09:19:23 2020 +1030 PR26667, Add powerpc64le-*-freebsd* support PR 26667 bfd/ * config.bfd: Add powerpc64le-*-freebsd*. * configure.ac: Add powerpc_elf64_fbsd_le_vec. * elf64-ppc.c (TARGET_LITTLE_SYM, TARGET_LITTLE_NAME): Define for freebsd. * targets.c (powerpc_elf64_fbsd_le_vec): Declare. (_bfd_target_vector): Add it. * configure: Regenerate. ld/ * Makefile.am (ALL_64_EMULATION_SOURCES): Add eelf64lppc_fbsd.c. Include $(DEPDIR)/eelf64lppc_fbsd.Pc. * configure.tgt: Add powerpc64le-*-freebsd*. * emulparams/elf64lppc_fbsd.sh: New file. * Makefile.in: Regenerate. * po/BLD-POTFILES.in: Regenerate. -- You are receiving this mail because: You are on the CC list for the bug.
