[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 --- Comment #19 from Jan Beulich --- (In reply to Michael Matz from comment #14) > The scrubber removes whitespace between tokens of different classes, but > retains > whitespace between token of same class, which sometimes makes it so that > whitespace in macro invocation does or does not separate arguments, the > difference visible in e.g.: > > invoke 1 2 > invoke 1 + 2 3 But that's the whole issue: This isn't how the scrubber works. It's not uniformly "different classes" (there's not really a proper concept of tokens either). Boundaries between what may be numbers or identifiers are different from boundaries between operators and alike. The original report that I started this effort from was (iirc) something like invoke (1) (2) where the (pretty obviously) two arguments become just one. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Questions Regarding Initial Input Seeds Used for Fuzzing Binutils via OSS-Fuzz
Hi Philippe and Nick, Thank you both for the helpful information. Best regards, Federico On Mon, Aug 12, 2024 at 5:46 PM Nick Clifton wrote: > Hi Federico, > > > I have been exploring the Binutils library and its integration with > OSS-Fuzz for fuzzing purposes. > > To be clear: The OSS-Fuzz project is completely separate from > the GNU Binutils project. We are happy that they want to use > our code as part of their project, but we are not connected in > any way. > > > I have questions regarding the initial input seeds used to fuzz the > library and would greatly appreciate your assistance. > > You will have to ask the OSS-Fuzz project these questions directly. > Unfortunately we do not have the answers here. > > Cheers >Nick > >
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 --- Comment #20 from Michael Matz --- (In reply to Jan Beulich from comment #19) > (In reply to Michael Matz from comment #14) > > The scrubber removes whitespace between tokens of different classes, but > > retains > > whitespace between token of same class, which sometimes makes it so that > > whitespace in macro invocation does or does not separate arguments, the > > difference visible in e.g.: > > > > invoke 1 2 > > invoke 1 + 2 3 > > But that's the whole issue: This isn't how the scrubber works. I was talking "in principle" and hence imprecisely. > It's not uniformly "different classes" (there's not really a proper concept > of tokens either). Tokens _are_ classes of character-sequences. 'identifier', 'number', 'punctuator', and so on. (Sometimes the class has just one member: e.g. ')'). But you're right that it's not the difference of classes between RHS and LHS that enables white-space removal, but rather if pasting the two strings results in one new token or not. > Boundaries between what may be numbers or identifiers are > different from boundaries between operators and alike. The original > report that I started this effort from was (iirc) something like > > invoke (1) (2) > > where the (pretty obviously) two arguments become just one. Yes, when the removed whitespace doesn't change the parse (i.e. the character sequences now side-by-side don't form a new token), then it can be removed. Except of course, it cannot, because whitespace has semantic meaning as separator later on :-/ I don't have a good solution, I see only hacks (e.g. above: fix _this_ very instance of '(1) (2)' being pasted, to not be anymore, or alternatively to continue pasting them, but handle outermost ')' as additional macro argument separator). :-( Or: accept the fact that '(1) (2)' is a single macro argument, even if surprising. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32072] ./dlltool.c:870:27: error: initializer-string for array of 'char' is too long
https://sourceware.org/bugzilla/show_bug.cgi?id=32072 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #2 from Alan Modra --- . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 --- Comment #21 from H.J. Lu --- (In reply to Michael Matz from comment #20) > Or: accept the fact that '(1) (2)' is a single macro argument, even if > surprising. I submitted a test for it: https://sourceware.org/pipermail/binutils/2024-August/136307.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 Maciej W. Rozycki changed: What|Removed |Added CC||macro at orcam dot me.uk -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 --- Comment #22 from Maciej W. Rozycki --- (In reply to Michael Matz from comment #20) > I don't have a good solution, I see only hacks (e.g. above: fix _this_ very > instance of '(1) (2)' being pasted, to not be anymore, or alternatively to > continue pasting them, but handle outermost ')' as additional macro argument > separator). :-( > > Or: accept the fact that '(1) (2)' is a single macro argument, even if > surprising. Fair enough. Would it help and work if we at least only permitted one kind of separator per invocation, i.e. if there's an unquoted comma in the argument string then it becomes the separator and whitespace is not? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #23 from Fangrui Song --- (In reply to H.J. Lu from comment #0) > [...] > failed to build Linux kernel 6.10.4: > [...] > make[5]: *** [scripts/Makefile.build:362: arch/x86/crypto/sha256-avx2-asm.o] > Error 1 I have created a Linux kernel patch to fix arch/x86/crypto/sha256-avx2-asm.S https://lore.kernel.org/all/20240814044802.1743286-1-mask...@google.com/T/#u M a + b => M (a + b) Further investigation reveals that arch/arm64/kvm/hyp/nvhe/../hyp-entry has the following `(1 << 15) | 1` pattern, which was broken by the scrubber changes. (make -skj"$(nproc)" O=/tmp/linux/arm64 ARCH=arm64 LLVM=1 defconfig all) altinstruction_entry 661f, kvm_patch_vector_branch, (1 << 15) | 1, 662f-661f, 0 I have checked how the LLVM integrated assembler (which doesn't have a whitespace scrubber) handles x86 `a + b` and arm64 `(1 << 15) | 1`. After parsing `a`, it checks whether the next token is an operator, and if yes, parse the next token and merge them into `a`. https://github.com/llvm/llvm-project/commit/055006475e22014b28a070db1bff41ca15f322f0#diff-e6bafec46d3db78a4169cfe729e3852b72cf7eebe7d5cbab12b1d7e3cb00b6e8R1578 (In reply to Jan Beulich from comment #5) > (In reply to Andreas Schwab from comment #4) > > $ cat svml_d_acos2_core-sse2.S > > #define JUMPTARGET(name) *name##@GOTPCREL(%rip) > > > > .macro WRAPPER_IMPL_SSE2 callee > > call JUMPTARGET(\callee) > > .endm > > .text > > WRAPPER_IMPL_SSE2 acos > > Which cpp expands to > > .macro WRAPPER_IMPL_SSE2 callee > call *\ callee@GOTPCREL(%rip) > .endm > .text > WRAPPER_IMPL_SSE2 acos > > Wow. Where's the blank coming from? I didn't know the pre-processor may > insert random whitespace. And the pre-processed result is identical to that > of the (imo) bogus > > call JUMPTARGET(\ callee) > > How's the consumer supposed to be telling apart which one it was originally? > > Yet then documentation is unclear on whether there may be whitespace between > the \ and the parameter name. We could of course make macro expansion skip > whitespace when a valid parameter name follows. Yet I fear there could be > other anomalies as a result. In the clang -E expansion, there is no such space... .macro WRAPPER_IMPL_SSE2 callee call *\callee@GOTPCREL(%rip) .endm .text WRAPPER_IMPL_SSE2 acos But I am amused by this behavior (\ callee). .macro foo a // clang reports an error while gas currently accepts this call \ a .endm foo ab (In reply to Maciej W. Rozycki from comment #22) > (In reply to Michael Matz from comment #20) > > I don't have a good solution, I see only hacks (e.g. above: fix _this_ very > > instance of '(1) (2)' being pasted, to not be anymore, or alternatively to > > continue pasting them, but handle outermost ')' as additional macro argument > > separator). :-( > > > > Or: accept the fact that '(1) (2)' is a single macro argument, even if > > surprising. > Fair enough. Would it help and work if we at least only permitted one > kind of separator per invocation, i.e. if there's an unquoted comma in > the argument string then it becomes the separator and whitespace is not? I think this will be useful. We could explore additional opportunities to restrict space separators to as few scenarios as possible (as long as not used in the wild)... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32073] [2.44 Regression] gas failed to build x86-64 Linux kernel
https://sourceware.org/bugzilla/show_bug.cgi?id=32073 --- Comment #24 from Fangrui Song --- (In reply to H.J. Lu from comment #6) > It also breaks GCC builds for ARM, AVR, PRU and others. Do you have links to the potentially brittle assembly? In the gcc repo, I checked a few `rg '\.macro' -g '*.s' -g '*.S'` occurrences, but I did not find anything. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32082] New: gas arm aarch64: missing mapping symbols $d in the absence of alignment directives
https://sourceware.org/bugzilla/show_bug.cgi?id=32082
Bug ID: 32082
Summary: gas arm aarch64: missing mapping symbols $d in the
absence of alignment directives
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Data sections without alignment directives (excluding
BSS) might lack '$d' symbols, and mixing data and text sections can
introduce state transition problems.
The relevant code was modified by
https://sourceware.org/pipermail/binutils/2015-March/088214.html
% cat x.c
char var = 1;
char arr[2] = {1};
% arm-linux-gnueabi-gcc -c -fdata-sections x.c && objdump -t x.o #
aarch64-linux-gnu-gcc is similar
x.o: file format elf32-little
SYMBOL TABLE:
ldf *ABS* x.c
ld .text .text
ld .data .data
ld .bss .bss
ld .data.var .data.var
ld .data.arr .data.arr
l .data.arr $d
...
LLVM integrated assembler's AArch32 port doesn't insert '$d' unless
code is present, which could lead to similar issues.
(https://reviews.llvm.org/D30724)
% clang -c --target=armv7-linux-gnueabi -fdata-sections x.c && objdump -t x.o
x.o: file format elf32-little
SYMBOL TABLE:
ldf *ABS* x.c
g O .data.var 0001 var
g O .data.arr 0002 arr
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/32082] gas arm aarch64: missing mapping symbols $d in the absence of alignment directives
https://sourceware.org/bugzilla/show_bug.cgi?id=32082 Fangrui Song changed: What|Removed |Added Target||arm*-*-* aarch64-*-* -- You are receiving this mail because: You are on the CC list for the bug.
