Summary: | APP/NO_APP with linefile | ||
---|---|---|---|
Product: | binutils | Reporter: | Mikael Pettersson <mikpelinux> |
Component: | gas | Assignee: | Alan Modra <amodra> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bergner |
Priority: | P2 | ||
Version: | 2.39 | ||
Target Milestone: | 2.39 | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2022-08-10 00:00:00 | |
Attachments: | _divmoddi4.s for vax-linux from gcc-12.1 |
Simpler test: #NO_APP #APP # 1153 "libgcc2.c" 1 # 0 "" 2 #NO_APP Replacing the lineinfo comments # with .linefile results in expansion of the text. We don't have enough room in the output buffer, and the remaining input just gets dropped. The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4d74aab7aa562fe79d4669cdad0c32610531cbc0 commit 4d74aab7aa562fe79d4669cdad0c32610531cbc0 Author: Alan Modra <amodra@gmail.com> Date: Thu Aug 11 09:51:03 2022 +0930 PR29466, APP/NO_APP with .linefile Commit 53f2b36a54b9 exposed a bug in sb_scrub_and_add_sb that could result in losing input. If scrubbing results in expansion past the holding capacity of do_scrub_chars output buffer, then do_scrub_chars stashes the extra input for the next call. That call never came because sb_scrub_and_add_sb wrongly decided it was done. Fix that by allowing sb_scrub_and_add_sb to see whether there is pending input. Also allow a little extra space so that in most cases we won't need to resize the output buffer. sb_scrub_and_add_sb also limited output to the size of the input, rather than the actual output buffer size. Fixing that resulted in a fail of gas/testsuite/macros/dot with an extra warning: "end of file not at end of a line; newline inserted". OK, so the macro in dot.s really does finish without end-of-line. Apparently the macro expansion code relied on do_scrub_chars returning early. So fix that too by adding a newline if needed in macro_expand_body. PR 29466 * app.c (do_scrub_pending): New function. * as.h: Declare it. * input-scrub.c (input_scrub_include_sb): Add extra space for two .linefile directives. * sb.c (sb_scrub_and_add_sb): Take into account pending input. Allow output to max. * macro.c (macro_expand_body): Add terminating newline. * testsuite/config/default.exp (SIZE, SIZEFLAGS): Define. * testsuite/gas/macros/app5.d, * testsuite/gas/macros/app5.s: New test. * testsuite/gas/macros/macros.exp: Run it. The binutils-2_39-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9e855cffa1fda44629e7f9b76dfa3e5a51a440e9 commit 9e855cffa1fda44629e7f9b76dfa3e5a51a440e9 Author: Alan Modra <amodra@gmail.com> Date: Thu Aug 11 09:51:03 2022 +0930 PR29466, APP/NO_APP with .linefile Commit 53f2b36a54b9 exposed a bug in sb_scrub_and_add_sb that could result in losing input. If scrubbing results in expansion past the holding capacity of do_scrub_chars output buffer, then do_scrub_chars stashes the extra input for the next call. That call never came because sb_scrub_and_add_sb wrongly decided it was done. Fix that by allowing sb_scrub_and_add_sb to see whether there is pending input. Also allow a little extra space so that in most cases we won't need to resize the output buffer. sb_scrub_and_add_sb also limited output to the size of the input, rather than the actual output buffer size. Fixing that resulted in a fail of gas/testsuite/macros/dot with an extra warning: "end of file not at end of a line; newline inserted". OK, so the macro in dot.s really does finish without end-of-line. Apparently the macro expansion code relied on do_scrub_chars returning early. So fix that too by adding a newline if needed in macro_expand_body. PR 29466 * app.c (do_scrub_pending): New function. * as.h: Declare it. * input-scrub.c (input_scrub_include_sb): Add extra space for two .linefile directives. * sb.c (sb_scrub_and_add_sb): Take into account pending input. Allow output to max. * macro.c (macro_expand_body): Add terminating newline. * testsuite/config/default.exp (SIZE, SIZEFLAGS): Define. * testsuite/gas/macros/app5.d, * testsuite/gas/macros/app5.s: New test. * testsuite/gas/macros/macros.exp: Run it. (cherry picked from commit 4d74aab7aa562fe79d4669cdad0c32610531cbc0) Fixed. 2.39 branch too. I can confirm that repeating my build of a vax-linux cross compiler using the current HEAD of binutils-2_39-branch succeeds. Thanks. Hi Alan, I just built a current as of today powerpc64le-linux build (our rain6p1 system - RHEL8.5) and did a "make maybe-check-gas" and I see this FAIL with the following output: ../as-new -o tmpdir/app5.o /home/bergner/binutils/binutils-gdb/gas/testsuite/gas/macros/app5.s Executing on host: sh -c {../as-new -o tmpdir/app5.o /home/bergner/binutils/binutils-gdb/gas/testsuite/gas/macros/app5.s 2>&1} /dev/null dump.tmp (timeout = 300) spawn [open ...]^M size -G tmpdir/app5.o > tmpdir/dump.out Executing on host: sh -c {size -G tmpdir/app5.o > tmpdir/dump.out 2>dump.tmp} /dev/null (timeout = 300) spawn [open ...]^M exited abnormally with 1, output:size: invalid option -- 'G' Usage: size [option(s)] [file(s)] Displays the sizes of sections inside binary files If no input file(s) are specified, a.out is assumed The options are: -A|-B --format={sysv|berkeley} Select output style (default is berkeley) -o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex -t --totals Display the total sizes (Berkeley only) --common Display total size for *COM* syms --target=<bfdname> Set the binary file format @<file> Read options from <file> -h --help Display this information -v --version Display the program's version size: supported targets: elf64-powerpcle elf64-powerpc elf32-powerpcle elf32-powerpc aixcoff-rs6000 aixcoff64-rs6000 aix5coff64-rs6000 elf64-little elf64-big elf32-little elf32-big pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 elf64-l1om elf64-k1om pe-i386 pei-i386 elf32-i386 elf32-iamcu plugin srec symbolsrec verilog tekhex binary ihex FAIL: APP with linefile The binutils-2_39-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4233be14a34d754a70b8b6f6fa42d21f35c6e030 commit 4233be14a34d754a70b8b6f6fa42d21f35c6e030 Author: Alan Modra <amodra@gmail.com> Date: Sat Sep 10 07:30:57 2022 +0930 Re: PR29466, APP/NO_APP with linefile It looks like I copied the SIZE init across from binutils/testsuite/config/default.exp without some necessary editing. PR 29466 * testsuite/config/default.exp (SIZE): Adjust relative path. (cherry picked from commit 1180f540d5f2f7751b5309bdd6c38d69fcf699e7) |
Created attachment 14270 [details] _divmoddi4.s for vax-linux from gcc-12.1 Attempting to assemble the attached _divmoddi4.s with gas built for vax-linux fails with: /tmp/_divmoddi4.s: Assembler messages: /tmp/_divmoddi4.s:372: Error: junk at end of line, first unrecognized character is `0' /mnt/scratch/cross/sources/gcc-12.1.0/libgcc/libgcc2.c:1181: Fatal error: Ignoring statement due to "Not enough operands" This was first seen while updating a gcc-12.1 cross-compiler to vax-linux from binutils-2.38 to binutils-2.39, which caused the build of libgcc2's _divmoddi4 to fail with the above message. A git bisect between 2.38 and 2.39 identified: # first bad commit: [53f2b36a54b9597f734891176fe6ba0866b819a8] gas read_a_source_file #APP processing Target: vax-unknown-linux Host: x86_64-pc-linux-gnu (Fedora 36) Vanilla upstream sources