[Bug gprofng/29521] [docs] man pages are not in the release tarball
https://sourceware.org/bugzilla/show_bug.cgi?id=29521 --- Comment #2 from Sam James --- Could this be addressed in time for .40 if possible please? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29991] gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-01-13 Ever confirmed|0 |1 --- Comment #5 from Alan Modra --- Created attachment 14589 --> https://sourceware.org/bugzilla/attachment.cgi?id=14589=edit Simpler patch Please verify that the attached patch works for you. It should be OK to run file_mips_check_options and mips_mark_labels without your define_label logic. I moved the mips_mark_labels call after .align expression parsing as is done with other directives. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29994] ld fails to generate NOTE segment (with Build ID) on aarch64 if -z execstack or -z noexecstack
https://sourceware.org/bugzilla/show_bug.cgi?id=29994 Nick Desaulniers changed: What|Removed |Added CC||ndesaulniers at google dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 --- Comment #2 from William Cohen --- I believe the large number of notes is because of the use of static libraries in the packages. Took a look at how the some of the shared libraries were generated in the mesa package which has a similar but not so extreme percentage of time taken by the gnu_merge_build_notes function (20% rather than 70% of the rpmbuild install). For example the libdpau_gallium.so.1.0.0 was linked with the following: [2390/2405] g++ -o src/gallium/targets/vdpau/libvdpau_gallium.so.1.0.0 src/gallium/targets/vdpau/libvdpau_gallium.so.1.0.0.p/target.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libvdpau_gallium.so.1.0.0 -Wl,--whole-archive src/gallium/frontends/vdpau/libvdpau_st.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/wcohen/rpmbuild/BUILD/mesa-22.1.7/.package_note-mesa-22.1.7-1.fc36.x86_64.ld -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection src/gallium/auxiliary/libgalliumvlwinsys.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/gallium/auxiliary/libgalliumvl.a src/gallium/auxiliary/libgallium.a src/compiler/nir/libnir.a src/compiler/libcompiler.a src/gallium/auxiliary/pipe-loader/libpipe_loader_static.a src/loader/libloader.a src/util/libxmlconfig.a src/gallium/winsys/sw/null/libws_null.a src/gallium/winsys/sw/wrapper/libwsw.a src/gallium/winsys/sw/dri/libswdri.a src/gallium/winsys/sw/kms-dri/libswkmsdri.a src/gallium/drivers/r300/libr300.a src/gallium/winsys/radeon/drm/libradeonwinsys.a src/gallium/drivers/r600/libr600.a src/mesa/libmesa.a src/compiler/glsl/libglsl.a src/compiler/glsl/glcpp/libglcpp.a src/mesa/libmesa_sse41.a src/gallium/drivers/radeonsi/libradeonsi_gfx6.a src/gallium/drivers/radeonsi/libradeonsi_gfx7.a src/gallium/drivers/radeonsi/libradeonsi_gfx8.a src/gallium/drivers/radeonsi/libradeonsi_gfx9.a src/gallium/drivers/radeonsi/libradeonsi_gfx10.a src/gallium/drivers/radeonsi/libradeonsi_gfx103.a src/gallium/drivers/radeonsi/libradeonsi.a src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a src/amd/addrlib/libaddrlib.a src/amd/common/libamd_common.a src/amd/llvm/libamd_common_llvm.a src/gallium/winsys/nouveau/drm/libnouveauwinsys.a src/gallium/drivers/nouveau/libnouveau.a -Wl,--version-script /home/wcohen/rpmbuild/BUILD/mesa-22.1.7/src/gallium/targets/vdpau/vdpau.sym -Wl,--dynamic-list /home/wcohen/rpmbuild/BUILD/mesa-22.1.7/src/gallium/targets/vdpau/../dri-vdpau.dyn -Wl,--gc-sections /usr/lib64/libz.so -pthread -lm /usr/lib64/libdrm.so /usr/lib64/libxcb-sync.so /usr/lib64/libxcb-present.so /usr/lib64/libxshmfence.so /usr/lib64/libxcb-xfixes.so /usr/lib64/libxcb-dri3.so /usr/lib64/libzstd.so /usr/lib64/libunwind.so -lLLVM-14 -lsensors /usr/lib64/libexpat.so /usr/lib64/libdrm_radeon.so -lLLVM-14 /usr/lib64/libelf.so -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 -lLLVM-14 /usr/lib64/libdrm_amdgpu.so -lLLVM-14 /usr/lib64/libdrm_nouveau.so /usr/lib64/libxcb.so /usr/lib64/libX11-xcb.so /usr/lib64/libX11.so /usr/lib64/libxcb-dri2.so -Wl,--end-group Individual static library in there hvae thousands of lines of notes: $ readelf --notes --wide src/gallium/frontends/vdpau/libvdpau_st.a |wc 3192 29512 253834 $ readelf --notes --wide src/gallium/drivers/nouveau/libnouveau.a |wc 65270 604954 5272013 To see how much a difference there is between static and shared libraries notes I compared the static and shared libraries from libpfm-4.11.0-10.fc37.src.rpm. The static library has a couple orders of magnitude more notes than the shared library: [wcohen@haro SPECS]$ readelf --notes --wide /usr/lib64/libpfm.a |wc 9209 84135 705543 [wcohen@haro SPECS]$ readelf --notes --wide /usr/lib64/libpfm.so.4.10.1 |wc 32 2492467 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29994] New: ld fails to generate NOTE segment (with Build ID) on aarch64 if -z execstack or -z noexecstack
https://sourceware.org/bugzilla/show_bug.cgi?id=29994
Bug ID: 29994
Summary: ld fails to generate NOTE segment (with Build ID) on
aarch64 if -z execstack or -z noexecstack
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: tom.saeger at oracle dot com
Target Milestone: ---
This issue was discovered while building linux-stable 5.15.y on aarch64.
Introduced into 5.15.y by
4c7ee827da2c ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
which is a backport of
0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
Discussions for context:
- https://lore.kernel.org/all/cover.1670358255.git.tom.sae...@oracle.com/#r
-
https://lore.kernel.org/all/3df32572ec7016e783d37e185f88495831671f5d.1671143628.git.tom.sae...@oracle.com/
The tool-flow within 5.15.y linux kernels, when configured with
CONFIG_MODVERSIONS is roughly:
1. gcc head.S -> head.o
2. ld -z noexecstack head.o -> .tmp_head.o
3. mv -f .tmp_head.o head.o
4. ld -o vmlinux --whole-archive arch/arm64/kernel/head.o ...
After 4c7ee827da2c, on aarch64 the resulting vmlinux does not have a NOTE
segment which contains the Build ID.
This seems unique to aarch64 and ld.
x86_64 works.
aarch64 llvm works.
If step 2 above uses -z execstack - it still fails.
However, removing -z noexecstack from step 2. in my testing works-around this
issue.
Reproduction steps (on aarch64 system):
git clone -b v5.15.61 --depth=1
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
make ARCH=arm64 defconfig
scripts/config -e MODVERSIONS
make ARCH=arm64 olddefconfig
make ARCH=arm64 V=1 -j16 vmlinux
readelf -n vmlinux
ld versions 2.36, 2.37, 2.38, and 2.39 all exhibited this same behavior.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 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 binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993 William Cohen changed: What|Removed |Added CC||wcohen at redhat dot com --- Comment #1 from William Cohen --- Looked at the number of notes in the libxul.so found that there were about 4 million lines of output with the following: fche, hmm. there looks to be a huge amount of notes in libxul.so. $ cd ~/rpmbuild/BUILD/firefox-108.0.1; readelf --notes --wide ./objdir/dist/firefox/libxul.so | wc readelf: ./objdir/dist/firefox/libxul.so: Warning: Gap in build notes detected from 0xb9f69a to 0x661ae9f 4378890 42206207 436839245 over 4 million lines of notes output for libxul.so. that might explain why so much time spent in objcopy. Used "perf report" to see where the samles were in merge_gnu_build_notes. The behavior is caused by the large number of notes and "Rule 2" linearly searching through the list of previous notes. Even if "identically attributed notes" are grouped together there can still be a lot to go through. There appears to be a lot merged out as the installed firefox libxul.so is much more compact: $ readelf --notes --wide /usr/lib64/firefox/libxul.so |wc readelf: /usr/lib64/firefox/libxul.so: Warning: Gap in build notes detected from 0xcb7d6f to 0x661aebf 86 8367897 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29993] New: objcopy --merge-notes slow for large .so with many annobin notes
https://sourceware.org/bugzilla/show_bug.cgi?id=29993
Bug ID: 29993
Summary: objcopy --merge-notes slow for large .so with many
annobin notes
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: fche at redhat dot com
Target Milestone: ---
A modern firefox build includes construction of a 3.9GB libxul.so (including
debuginfo) on x86-64. On a f37 toolchain, readelf -S reports
[30] .gnu.build.a[...] NOTE 093022c8 088cef2c
076734c8 0 0 4
i.e., 118MB of .gnu.build.attributes, of some 4 million entries.
The fedora rpm build process includes an
% objcopy --merge-notes libxul.so
stage to gather those together. On a 5GHz machine with ample RAM, this process
takes around ten minutes of 100% cpu time. That's about 1/3rd of the total
build time for the package.
objcopy.c's merge copy seems to be responsible. There is a
doubly nested loop over the notes, resulting in O(n**2) complexity.
2406 for (pnote = pnotes; pnote < pnotes_end; pnote ++)
2407 {
[...]
2426 /* Rule 2: Check to see if there is an identical previous note.
*/
2427 for (iter = 0, back = pnote - 1; back >= pnotes; back --)
2428 {
2429 if (is_deleted_note (back))
2430 continue;
Please consider improving the algorithm's performance on this sort of large
dataset.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 --- Comment #28 from H.J. Lu --- (In reply to Rainer Orth from comment #27) > Created attachment 14577 [details] > Augmented patch, incorporating review comments expected_tls_le should be unsigned int. The check will be if (r_type_tls == expected_tls_le) > Like so? I wonder if it would be possible to move the declaration of > expected_tls_le to its use. Given that binutils now requires C99, that would > certainly be clearer, but differ in style from the rest of the file. > > Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu as well as a full > all-languages > gcc bootstrap. > > As an additional experiment, I've enabled ld-i386/tls.exp on Solaris/x86. > Before > this patch, only two tests FAIL: > > FAIL: TLS GD/LD -> IE transition without PLT > FAIL: TLS GD/LD -> IE transition without PLT (-z now) > > The error is the expected > > Running: tmpdir/tls-1d > tmpdir/tls-1d.out > ld.so.1: tls-1d: fatal: relocation error: R_386_UNKNOWN37: file > tmpdir/tls-1d: symbol gd: offset size (0 bytes) is not supported > > With the patch, those two tests continue to FAIL. However, the error is > different: > > /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect- > ld: warning: /usr/lib/crtn.o: missing .note.GNU-stack section implies > executable stack > /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect- > ld: NOTE: This behaviour is deprecated and will be removed in a future > version of the linker > /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect- > ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail > /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 > /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect- > ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail > /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 > /var/gcc/binutils/i386/obj/binutils-2.40-branch-local/ld/tmpdir/ld/collect- > ld: BFD (GNU Binutils) 2.39.90.20230111 assertion fail > /vol/src/gnu/binutils/hg/binutils-2.40-branch/local/bfd/elf32-i386.c:3377 > collect2: error: ld returned 1 exit status > > On top of that, there are four new failures > > +FAIL: TLS GD/LD -> LE transition without PLT (dynamic) > +FAIL: TLS GD/LD -> LE transition without PLT (dynamic, -z now) > +FAIL: TLS GD/LD -> LE transition without PLT (PIE) > +FAIL: TLS GD/LD -> LE transition without PLT (PIE, -z now) > > which show the same error. So TLS doesn't work for Solaris. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29983] 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite
https://sourceware.org/bugzilla/show_bug.cgi?id=29983 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The binutils-2_40-branch branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=999e7ed7a2bfd3a65468b383222d441a8071d8e4 commit 999e7ed7a2bfd3a65468b383222d441a8071d8e4 Author: Nick Alcock Date: Mon Jan 9 13:43:09 2023 + libctf: ctf-link outdated input check faulty This check has a pair of faults which, combined, can lead to memory corruption. Firstly, it assumes that the values of the ctf_link_inputs hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much shorter structure. So the flags check which is the core of this is faulty (but happens, by chance, to give the right output on most architectures, since usually we happen to get a 0 here, so the test that checks this usually passes). Worse, the warning that is emitted when the test fails is added to the wrong dict -- it's added to the input dict, whose warning list is never consumed, rendering the whole check useless. But the dict it adds to is still the wrong type, so we end up overwriting something deep in memory (or, much more likely, dereferencing a garbage pointer and crashing). Fixing both reveals another problem: the link input is an *archive* consisting of multiple members, so we have to consider whether to check all of them for the outdated-func-info thing we are checking here. However, no compiler exists that emits a mixture of members with this flag on and members with it off, and the linker always reserializes (and upgrades) such things when it sees them: so all members in a given archive must have the same value of the flag, so we only need to check one member per input archive. libctf/ PR libctf/29983 * ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of members of ctf_link_inputs right, fixing a possible spurious tesst failure / wild pointer deref / overwrite. Emit the warning message into the right dict. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29983] 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite
https://sourceware.org/bugzilla/show_bug.cgi?id=29983 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c777aa9765b6892c1ef7d7584385b9377071248e commit c777aa9765b6892c1ef7d7584385b9377071248e Author: Nick Alcock Date: Mon Jan 9 13:43:09 2023 + libctf: ctf-link outdated input check faulty This check has a pair of faults which, combined, can lead to memory corruption. Firstly, it assumes that the values of the ctf_link_inputs hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much shorter structure. So the flags check which is the core of this is faulty (but happens, by chance, to give the right output on most architectures, since usually we happen to get a 0 here, so the test that checks this usually passes). Worse, the warning that is emitted when the test fails is added to the wrong dict -- it's added to the input dict, whose warning list is never consumed, rendering the whole check useless. But the dict it adds to is still the wrong type, so we end up overwriting something deep in memory (or, much more likely, dereferencing a garbage pointer and crashing). Fixing both reveals another problem: the link input is an *archive* consisting of multiple members, so we have to consider whether to check all of them for the outdated-func-info thing we are checking here. However, no compiler exists that emits a mixture of members with this flag on and members with it off, and the linker always reserializes (and upgrades) such things when it sees them: so all members in a given archive must have the same value of the flag, so we only need to check one member per input archive. libctf/ PR libctf/29983 * ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of members of ctf_link_inputs right, fixing a possible spurious tesst failure / wild pointer deref / overwrite. Emit the warning message into the right dict. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 Alan Modra changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #8 from Alan Modra --- . *** This bug has been marked as a duplicate of bug 29991 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29991] gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 --- Comment #4 from Alan Modra --- *** Bug 29990 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/11516] Fatal error assembling jsr for Alpha ECOFF
https://sourceware.org/bugzilla/show_bug.cgi?id=11516 Alan Modra changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Rainer Orth --- Subject: Re: Fatal error assembling jsr for Alpha ECOFF Hi Nick, > I am not an expert in this particular architecture. The uploaded patch neither am I: I just happen to maintain the GCC port to Tru64 UNIX :-) > prevents the seg-fault, but the assembler now responds with: > > Error: invalid relocation for field > > Is this what you would expect ? Actually no: the native assembler assembles this just fine: $ as -o jsr.o jsr.s $ objdump -d jsr.o jsr.o: file format ecoff-littlealpha Disassembly of section .text: <.text>: 0: 10 80 7d a7 ldq t12,-32752(gp) 4: 00 40 5b 6b jsr ra,(t12),0x8 8: 1f 04 ff 47 nop c: 00 00 fe 2f unop It may be related to the fact that Alpha ELF gas uses explicit relocs and anything else suffers from bitrot. I'd tried to enable them for the target, but failed, cf. PR gas/11518. Thanks. Rainer --- Comment #4 from Alan Modra --- Hmm, the top-level configure disables gas and ld for alpha-dec-osf since 1999. alpha-linuxecoff prior to commit df26367c793c (ie. prior to 2.24) actually generated ELF. Poking at this bug a little makes me think alpha-linuxecoff ought to be marked obsolete. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29991] gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 --- Comment #1 from 刘鑫 --- Created attachment 14585 --> https://sourceware.org/bugzilla/attachment.cgi?id=14585=edit test code:align-after-label.s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29991] New: gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 Bug ID: 29991 Summary: gas: MicroMIPS flag mistakenly erased after align directives Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: xin.liu at oss dot cipunited.com Target Milestone: --- Created attachment 14584 --> https://sourceware.org/bugzilla/attachment.cgi?id=14584=edit this is the patch file. To reproduce this behaviour, I have used the following assembly code with `-EL -mmicromips -mips32r5` ``` .set micromips seg1: .align 2 addiu $0, $0, 1 ``` The correct objdump of this would have its all sections marked with micromips, but when the align directive on line 3 is added, the code after "seg1" label won't have the micromips flag, the resulting objdump shown as following. The incorrect behaviour would be: ``` : 0: 0c004c02jal 13008 4: nop ... ``` While the correct one should be： ``` : 0: 4c02addiu zero,zero,1 2: 0c00nop ... ``` The patch attached would fix this problem by defining a new flag which would be setted when the micromips flag is set and the assembler reads label definitions, then the flag is read every time the parser reads the '.align' directive so it could correct the behaviour by set the micromips to true, the flag is cleared after the correction. There are 2 more tests added for the patch, the files are attached with the patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29991] gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 刘鑫 changed: What|Removed |Added CC||xin.liu at oss dot cipunited.com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29991] gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 --- Comment #2 from 刘鑫 --- Created attachment 14586 --> https://sourceware.org/bugzilla/attachment.cgi?id=14586=edit testcase1:mips-align-after-label.d -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29991] gas: MicroMIPS flag mistakenly erased after align directives
https://sourceware.org/bugzilla/show_bug.cgi?id=29991 --- Comment #3 from 刘鑫 --- Created attachment 14587 --> https://sourceware.org/bugzilla/attachment.cgi?id=14587=edit testcase2:micromips-align-after-label.d -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 --- Comment #5 from 刘鑫 --- Created attachment 14581 --> https://sourceware.org/bugzilla/attachment.cgi?id=14581=edit tescase2:micromips-align-after-label.d -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 --- Comment #6 from 刘鑫 --- Created attachment 14582 --> https://sourceware.org/bugzilla/attachment.cgi?id=14582=edit this is the patch file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 --- Comment #3 from 刘鑫 --- Created attachment 14579 --> https://sourceware.org/bugzilla/attachment.cgi?id=14579=edit test code:align-after-label.s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 --- Comment #7 from 刘鑫 --- Created attachment 14583 --> https://sourceware.org/bugzilla/attachment.cgi?id=14583=edit this is the patch file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 刘鑫 changed: What|Removed |Added Summary|gas: mistakenly mark|gas: micromips flag |micromips if .align after |mistakenly erased after |label |align directive CC||xin.liu at oss dot cipunited.com Version|unspecified |2.40 --- Comment #1 from 刘鑫 --- To reproduce this behaviour, I used the following assembly code with -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 --- Comment #4 from 刘鑫 --- Created attachment 14580 --> https://sourceware.org/bugzilla/attachment.cgi?id=14580=edit tescase1:mips-align-after-label.d -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] gas: micromips flag mistakenly erased after align directive
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 --- Comment #2 from 刘鑫 --- Created attachment 14578 --> https://sourceware.org/bugzilla/attachment.cgi?id=14578=edit this is the patch file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29990] New: gas: mistakenly mark micromips if .align after label
https://sourceware.org/bugzilla/show_bug.cgi?id=29990 Bug ID: 29990 Summary: gas: mistakenly mark micromips if .align after label Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: xin.liu at oss dot cipunited.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the bug.
