[Bug binutils/30870] binutils/bfd/vms-alpha.c:1628:16: error：expected statement before ‘)’ token
https://sourceware.org/bugzilla/show_bug.cgi?id=30870 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #2 from Alan Modra --- Fixed, thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30870] binutils/bfd/vms-alpha.c:1628:16: error：expected statement before ‘)’ token
https://sourceware.org/bugzilla/show_bug.cgi?id=30870 --- 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=fbf4b3c9bb0347950ee8792093e44c9d0cac60c5 commit fbf4b3c9bb0347950ee8792093e44c9d0cac60c5 Author: Song Mengzhi Date: Tue Sep 19 07:13:46 2023 + PR30870, VMS_DEBUG compilation error Introduced by 8169954446. PR 30870 * vms-alpha.c (image_write): Remove extraneous parenthesis. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30860] Possible usage of NULL in GAS
https://sourceware.org/bugzilla/show_bug.cgi?id=30860 --- Comment #3 from jacob at jacob dot remcomp.fr --- > > Actually this is wrong. The point of compiling with NDEBUG active > is that sanity checks like the one above are removed making the code > (theoretically) faster. Anyone using programs compiled with NDEBUG > must take on the risk that the program will fail in an unhelpful way > if the input is not as expected. > > So replacing know() with gas_assert() will remove the benefit of > compiling with NDEBUG. Of course this leads to the question - why > have a gas_assert() function at all, why not just use know() all > the time ? The answer is partially programmer preference and > partially assumption of risk. If the programmer is sure that a > failing a particular test can only happen if something else is wrong > elsewhere in the code, eg a rs_org fragment not being followed by > another fragment, then using know() makes sense. If the test fails > then there is a bug elsewhere and this code is not at fault. So it > should be safe to remove the test when compiling with NDEBUG - using > NDEBUG implies that the user is happy with the code's behaviour and > does not want extra tests. > > If on the other hand, the programmer knows that an issue can arise > because of input over which the code has no control - eg the assembler > source input file - and there is no easy way to report this error back > to the user, then using gas_assert() makes sense. The code cannot > continue and cannot go back, so halting with an error message is the > only option. > > Having said all of that, there probably are places in the current code > where it would be better to use gas_assert() instead of know() and > places where it would be better to report an error back to the function > caller rather than halting. It is just that, in my opinion, write.c:3014 > is not one of them. > Hi Nick Look, I do not share your views but I understand them. It is such a matter of programming philosophy that I agree that you can leave that as it is now. It is not a serious problem. Thanks for your work in binutils gas. Jacob -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30867] merge.cc:668:27: error: ‘char16_t’ was not declared in this scope
https://sourceware.org/bugzilla/show_bug.cgi?id=30867 --- Comment #2 from Szabolcs Nagy --- on a second thought gold likely requires AX_CXX_COMPILE_STDCXX(11, , mandatory) in its configure.ac -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/30867] merge.cc:668:27: error: ‘char16_t’ was not declared in this scope
https://sourceware.org/bugzilla/show_bug.cgi?id=30867 Szabolcs Nagy changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #1 from Szabolcs Nagy --- sounds like your compiler does not support c++11. gcc-4.8.5 used to default to gnu++98 standard so i guess you need to use CXX='g++ -std=gnu++11' when configuring gold. i guess the config script could detect this error, but otherwise this is a user issue: gold requires a c++11 compiler. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30875] Output section type does not been applied to section forced output by `. = .` assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=30875 Hsinyuan Xavier changed: What|Removed |Added CC||TheLastLin at hotmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30875] New: Output section type does not been applied to section forced output by `. = .` assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=30875
Bug ID: 30875
Summary: Output section type does not been applied to section
forced output by `. = .` assignment
Product: binutils
Version: 2.38
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: TheLastLin at hotmail dot com
Target Milestone: ---
Created attachment 15118
--> https://sourceware.org/bugzilla/attachment.cgi?id=15118&action=edit
Workaround patch, set flags by sectype at exp_init_os and
map_input_to_output_sections:case lang_assignment_statement_enum
Sometimes we may want to keep some empty section from discarding with ` . = .
`. But it seems that such empty section don't apply specific output section
type.
Example linker script:
SECTIONS
{
foo (READONLY) :
{
*(bar)
. = . ;
}
}
Expected(when bar doesn't exist in input):
section foo with no SHF_WRITE flags.
Actually(when bar doesn't exist in input):
section foo with SHF_WRITE flag.
A workaround is also
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30874] New: ld internal error, aborting at ../../bfd/merge.c:935 in _bfd_merged_section_offset
https://sourceware.org/bugzilla/show_bug.cgi?id=30874 Bug ID: 30874 Summary: ld internal error, aborting at ../../bfd/merge.c:935 in _bfd_merged_section_offset Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: llvm at rifkin dot dev Target Milestone: --- When compiling llvm I ran into an ld crash: [3135/3427] Linking CXX executable bin/llvm-cat FAILED: bin/llvm-cat : && /usr/bin/c++ -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -Wl,-rpath-link,/homes/rifkin/scratch/llvm/build/./lib tools/llvm-cat/CMakeFiles/llvm-cat.dir/llvm-cat.cpp.o -o bin/llvm-cat -Wl,-rpath,"\$ORIGIN/../lib:" lib/libLLVMIRReader.a lib/libLLVMBitReader.a lib/libLLVMBitWriter.a lib/libLLVMCore.a lib/libLLVMSupport.a lib/libLLVMAnalysis.a lib/libLLVMProfileData.a lib/libLLVMSymbolize.a lib/libLLVMDebugInfoPDB.a lib/libLLVMDebugInfoMSF.a lib/libLLVMDebugInfoDWARF.a lib/libLLVMObject.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMRemarks.a lib/libLLVMBitstreamReader.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMTextAPI.a lib/libLLVMBinaryFormat.a lib/libLLVMTargetParser.a lib/libLLVMSupport.a -lrt -ldl -lm /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libtinfo.so lib/libLLVMDemangle.a && : /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.38 internal error, aborting at ../../bfd/merge.c:935 in _bfd_merged_section_offset /usr/bin/ld: Please report this bug. Steps to reproduce: mkdir llvm && cd llvm git init git remote add origin https://github.com/llvm/llvm-project.git git fetch --depth 1 origin 7cbf1a2591520c2491aa35339f227775f4d3adf6 git checkout FETCH_HEAD mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Debug -GNinja -DLLVM_PARALLEL_LINK_JOBS=8 ../llvm ninja -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30873] New: [RISC-V] On the failure of ".option arch, +/-" caused by implicit derivation of Zc extension
https://sourceware.org/bugzilla/show_bug.cgi?id=30873 Bug ID: 30873 Summary: [RISC-V] On the failure of ".option arch, +/-" caused by implicit derivation of Zc extension Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: mumuxi_ll at outlook dot com Target Milestone: --- Hi, Since Zca is implicited by Zcb/Zcf/Zcd, when I want to restrict part of my assembly code from compiling without the Zc extension(eg:march=rv32ima_zca_zcb_zcf_zcd), I must use the ".option arch, -" like below: .option push .option arch, -zcb .option arch, -zcf .option arch, -zcd .option arch, -zca add x3, x3, x27 ... .option pop If I write like: .option push .option arch, -zca .option arch, -zcb .option arch, -zcf .option arch, -zcd add x3, x3, x27 ... .option pop then the ".option arch, -zca" will not work. So I want to know if this implicit derivation relationship of Zc is necessary, or if there is a better way to solve the ".option arch, -" of Zc. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29259] ld -r may create reloc sections with unordered relocs again
https://sourceware.org/bugzilla/show_bug.cgi?id=29259 Ajay Kaher changed: What|Removed |Added CC||akaher at vmware dot com --- Comment #3 from Ajay Kaher --- Thanks for this fix. Initially we observed ~10% degradation to compiling Linux Kernel with gcc-12.x as compare to gcc-10.x. During investigation we found ~5% is because of binutils and with git bisect end up with following commit: https://github.com/bminor/binutils-gdb/commit/fba1ac87dcb76e61f270d236f1e7c8aaec80f9c4 Could this problem be fixed (in some other way) without any degradation? -Ajay -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30870] New: binutils/bfd/vms-alpha.c:1628:16: error：expected statement before ‘)’ token
https://sourceware.org/bugzilla/show_bug.cgi?id=30870 Bug ID: 30870 Summary: binutils/bfd/vms-alpha.c:1628:16: error：expected statement before ‘)’ token Product: binutils Version: 2.39 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: song.mengzhi at zte dot com.cn Target Milestone: --- When I enable the VMS_DEBUG macro in bfd/vms.h, I encounter compilation errors.The reason is that there is an extra ")" before the ";" on line 1628 in binutils/bfd/vms-alpha.c. This error is introduced by this patch:https:github.com/bminor/binutils-gdb/commit/816995444667f936c918bc76f3945105c4e1ec1b. Here is the modification method: @@ -1625,7 +1625,7 @@ image_write (bfd *abfd, unsigned char *p #if VMS_DEBUG _bfd_vms_debug (8, "image_write from (%p, %d) to (%ld)\n", ptr, size, - (long) off)); + (long) off); #endif if (PRIV (image_section)->contents != NULL) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 --- Comment #6 from Fangrui Song --- (In reply to Alan Modra from comment #5) > (In reply to Fangrui Song from comment #0) > > For GNU ld's AArch64/PPC64/x86-64 ports, the --emit-relocs code retains the > > original relocation type even if a linker optimization is applied. > > No, ppc64 adjusts relocations to match the emitted code. See for example > R_PPC64_GOT16_LO_DS handling in ppc64_elf_relocate_section, adjusted to > R_PPC64_TOC16_LO when a got indirect code sequence can be edited to got > pointer relative. > > > This is partly to communicate more information to the analysis tool > > This is exactly why relocations for ppc64 (and ppc32) were edited. IBM's > FDPR post-link optimisation tool used them. ppc64 even emits relocs for > linker generated stub code. > > The fact that other targets emit the original relocations is not a good > argument for saying that riscv should do so. Most maintainers of other > targets simply didn't see a need to correct the relocs when editing code. Thanks for the reply! I did not know. I have now made some notes on https://maskray.me/blog/2023-02-26-linker-notes-on-power-isa#emit-relocs For example, a TOC-indirect to TOC-relative optimization uses a pair of relocations `R_PPC64_TOC16_HA(.toc)+R_PPC64_TOC16_LO_DS(.toc)`. After optimization, they will become `R_PPC64_TOC16_HA(sym)+R_PPC64_TOC16_LO(sym)`. The `R_PPC64_TOC16_HA` relocation is present even if the first instruction is converted to a NOP. A general-dynamic TLS model code sequence may use relocations `R_PPC64_GOT_TLSGD16_HA+R_PPC64_GOT_TLSGD16_LO+R_PPC64_TLSGD+R_PPC64_REL24`. After optimization, they will become: * `R_PPC64_NONE+R_PPC64_TPREL16_HA+R_PPC64_TPREL16_LO+R_PPC64_NONE` after general-dynamic to local-exec TLS optimization. * `R_PPC64_GOT_TPREL16_HA+R_PPC64_GOT_TPREL16_LO_DS+R_PPC64_NONE+R_PPC64_NONE` after general-dynamic to initial-exec TLS optimization. So it seems that ppc performed conversion can all be described by existing relocation types, which is nice. However, I do not know whether the property will hold for all current and future RISC-V relaxation schemes. When investigating relocation overflow pressure for x86-64 small code model, I have found that preserving the original relocation type gives me more information: I can tell how many R_X86_64_PC32/R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX are problematic. If they are converted to R_X86_64_PC32/R_X86_64_32, I'd lose some information. Perhaps whether the --emit-relocs uses the original relocation type or the transformed relocation type , does not matter for the majority of use cases. E.g. Linux kernel's objtool, seems to perform a sanity check on relocations. It just needs to know the categories of relocations, e.g. absolute/PC-relative, not the exact type. -- You are receiving this mail because: You are on the CC list for the bug.
