[Bug gas/31323] New: [x86] GAS does not error out instruction that exceed 16 bytes
https://sourceware.org/bugzilla/show_bug.cgi?id=31323 Bug ID: 31323 Summary: [x86] GAS does not error out instruction that exceed 16 bytes Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: wwwhhhyyy333 at gmail dot com Target Milestone: --- With APX NDD add, the instruction length would exceed 16byte when segment prefix was used, e.g. addq $0xe0, %fs:0, %rdx Assembler only throws warning for such instruction unless manually turned on --fatal-warnings. For general use it is better to error out such illegal instruction by default, otherwise we only know it until runtime. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/31320] binutils-2.42 build failure on macos - error: 'uchar.h' file not found
https://sourceware.org/bugzilla/show_bug.cgi?id=31320 --- Comment #3 from Chris Packham --- Looks like it could be imported from gnulib https://www.gnu.org/software/gnulib/manual/html_node/uchar_002eh.html for systems that don't have it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/31320] binutils-2.42 build failure on macos - error: 'uchar.h' file not found
https://sourceware.org/bugzilla/show_bug.cgi?id=31320 --- Comment #2 from Chris Packham --- It looks like is a C11 thing so maybe instead of __APPLE__ some check around that would be better. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/31320] binutils-2.42 build failure on macos - error: 'uchar.h' file not found
https://sourceware.org/bugzilla/show_bug.cgi?id=31320 Bryan Hundven changed: What|Removed |Added CC||bryanhundven at gmail dot com --- Comment #1 from Bryan Hundven --- Looks like from the standard, char16_t and char32_t are uint_least16_t and uint_least32_t (from stdint.h), respectively. Could do something like: ``` #ifdef __APPLE__ #include typedef uint_least16_t char16_t; typedef uint_least32_t char32_t; #else #include #endif ``` ...in both output.cc and stringpoo.cc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/31109] gprofng not built and installed in a combined binutils+gcc build
https://sourceware.org/bugzilla/show_bug.cgi?id=31109 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #12 from Vladimir Mezentsev --- On 1/31/24 00:56, Richard Biener wrote: > On Wed, Jan 31, 2024 at 4:46 AM Vladimir Mezentsev > wrote: >> may I close 31109 ? > > So yes, I'd say that's an INVALID bug since it doesn't use master > branches on both sides. > > Richard. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP
https://sourceware.org/bugzilla/show_bug.cgi?id=31124 Georg-Johann Lay changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31321 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31321] AVR: Remove PROVIDE from definition of symbol __flmap_init_label
https://sourceware.org/bugzilla/show_bug.cgi?id=31321 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |2.43 Status|NEW |RESOLVED Target||avr Priority|P2 |P3 See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31124 Resolution|--- |FIXED --- Comment #1 from Georg-Johann Lay --- Resolved in v2.43: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=24f5deb64d9b0c33280108f185d03ff7dfef30ce Resolved in v2.42.1: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2fad36c3f553d103fcd0b75abd7a17da89b99864 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31321] New: AVR: Remove PROVIDE from definition of symbol __flmap_init_label
https://sourceware.org/bugzilla/show_bug.cgi?id=31321 Bug ID: 31321 Summary: AVR: Remove PROVIDE from definition of symbol __flmap_init_label Product: binutils Version: 2.42 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: gjl at gcc dot gnu.org Target Milestone: --- PR31124 introduced symbol __flmap_init_label as: PROVIDE (__flmap_init_label = DEFINED(__flmap_init_start) ? __flmap_init_start : 0) ; for emulations avrxmega2_flmap and avrxmega4_flmap. The symbol is supposed to be used by the startup-code crt*.o from AVR-LibC: The symbol resolves to: * __flmap_init_start when NVMCTRL_CTRLB.FLMAP should be initialized according to __flmap_value_with_lock, which is the case for emulations avrxmega2/4_flmap. * __flmap_noinit_start when the startup code should bypass the initialization of NVMCTRL_CTRLB.FLMAP, which is the case for emulations avrxmega2/4. All this works as expected, except in the case when such a crt*.o is used with a version of Binutils that does not implement PR31124. This can happen when crt*.o is deployed as part of a device pack that's build with PR31124 but used with a toolchain that does not have PR31124. In such a case, linking will throw an undefined reference to __flmap_init_label. The obvious fix would be to provide a default for that symbol in gcrt1.S like: .weak __flmap_init_label .set __flmap_init_label, __flmap_noinit_start which solves the undefined reference, however __flmap_init_label ceases to work when PR31124 *IS* supported, because the PROVIDE (__flmap_init_label = __flmap_init_start) won't touch the already defined __flmap_init_label, hence init of NVMCTRL_CTRLB.FLMAP would be bypassed when it must not be bypassed. Hence, remove PROVIDE from __flmap_init_label. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP
https://sourceware.org/bugzilla/show_bug.cgi?id=31124 --- Comment #5 from Sourceware Commits --- The binutils-2_42-branch branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2fad36c3f553d103fcd0b75abd7a17da89b99864 commit 2fad36c3f553d103fcd0b75abd7a17da89b99864 Author: Georg-Johann Lay Date: Wed Jan 31 11:24:22 2024 + PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap. Supply these symbols as computed by the linker scripts, even when there are weak definitions. PR 31124 * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP
https://sourceware.org/bugzilla/show_bug.cgi?id=31124 --- Comment #4 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=24f5deb64d9b0c33280108f185d03ff7dfef30ce commit 24f5deb64d9b0c33280108f185d03ff7dfef30ce Author: Georg-Johann Lay Date: Wed Jan 31 11:23:20 2024 + PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap. Supply these symbols as computed by the linker scripts, even when there are weak definitions. PR 31124 * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31319] [2.42 regression]: `.arch i386` is rejected by `x86_64` target: 4bit mode not supported on `i386'.
https://sourceware.org/bugzilla/show_bug.cgi?id=31319 Sergei Trofimovich changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |NOTABUG --- Comment #5 from Sergei Trofimovich --- Thank you! Proposed kexec-tools fix as http://lists.infradead.org/pipermail/kexec/2024-January/029349.html Let's close as NOTABUG. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31319] [2.42 regression]: `.arch i386` is rejected by `x86_64` target: 4bit mode not supported on `i386'.
https://sourceware.org/bugzilla/show_bug.cgi?id=31319 --- Comment #4 from Jan Beulich --- (In reply to Sergei Trofimovich from comment #3) > Aha, adapting kexec-tools sounds fine as well. > > Does the `.code16` use look fine in the rest of the file? They're all okay, as there's no other .arch directive. Ordering there would be a problem only if you had e.g. ".arch i286" ahead of ".code16". > SO far I made it build as: >[...] > Does it look about right? Yes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31319] [2.42 regression]: `.arch i386` is rejected by `x86_64` target: 4bit mode not supported on `i386'.
https://sourceware.org/bugzilla/show_bug.cgi?id=31319 --- Comment #3 from Sergei Trofimovich --- Aha, adapting kexec-tools sounds fine as well. Does the `.code16` use look fine in the rest of the file? SO far I made it build as: --- a/entry32-16-debug.s +++ b/entry32-16-debug.s @@ -18,10 +18,10 @@ .globl entry16_debug_pre32 .globl entry16_debug_first32 .globl entry16_debug_old_first32 + .code32 .arch i386 .balign 16 entry16_debug: - .code32 call 1f 1: popl %ebx Does it look about right? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31319] [2.42 regression]: `.arch i386` is rejected by `x86_64` target: 4bit mode not supported on `i386'.
https://sourceware.org/bugzilla/show_bug.cgi?id=31319 Jan Beulich changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-31 Status|UNCONFIRMED |WAITING --- Comment #2 from Jan Beulich --- So this is precisely the case that the new behavior is intended to catch: It is meaningless to restrict ISA to i386 when trying to build 64-bit code. In the kexec example, the .code32 comes too late anyway (would have wanted to be at least before the label already before); wants moving ahead of the .arch. IOW for now I view this as neither a bug nor a regression; earlier gas simply was to lax. I'm open to be convinced otherwise ... -- You are receiving this mail because: You are on the CC list for the bug.
