[Bug gas/11517] Fatal error assembling ldgp for Alpha ECOFF
https://sourceware.org/bugzilla/show_bug.cgi?id=11517 Alan Modra changed: What|Removed |Added Resolution|--- |OBSOLETE Status|WAITING |RESOLVED --- Comment #3 from Rainer Orth --- Subject: Re: Fatal error assembling ldgp for Alpha ECOFF Hi Nick, > The uploaded patch fixes this problem for me, but since I no expert on this > particular architecture I am not sure if it is the right solution. What do > you > think ? the object files produced by gas and as differ for my testcase: $ objdump -dr ldgp.o [...] Disassembly of section .text: <.text>: 0: 00 00 bb 27 ldahgp,0(t12) 0: GPDISP *ABS*+0x4 4: 04 00 bd 23 lda gp,4(gp) 4: IGNORE *ABS*+0x8000 8: 1f 04 ff 47 nop c: 00 00 fe 2f unop $ objdump -dr ldgp.as.o [...] Disassembly of section .text: <.text>: 0: 01 00 bb 27 ldahgp,1(t12) 0: GPDISP *ABS*+0x4 4: 10 80 bd 23 lda gp,-32752(gp) 8: 00 00 fe 2f unop c: 1f 04 ff 47 nop I'd probably have to either study the architecture manual, or (far simpler since it doesn't require my time) try a gcc bootstrap once gas is again able to assemble gcc output. This is generally an excellent test. Rainer --- Comment #4 from Alan Modra --- Target is obsolete -- 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 Resolution|--- |OBSOLETE Status|NEW |RESOLVED --- Comment #5 from Alan Modra --- Reality is that the target is obsolete. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/11518] Support explicit relocations for Alpha ECOFF
https://sourceware.org/bugzilla/show_bug.cgi?id=11518 Alan Modra changed: What|Removed |Added Resolution|--- |OBSOLETE Status|NEW |RESOLVED --- Comment #1 from Alan Modra --- Target is obsolete. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30421] Symbols in import lib are influenced by .def file
https://sourceware.org/bugzilla/show_bug.cgi?id=30421 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=80d4e113d7b9af8a5a36e5ea4399bca86050784f commit 80d4e113d7b9af8a5a36e5ea4399bca86050784f Author: Luca Bacci Date: Wed May 17 13:38:14 2023 +0100 Decorated symbols in import libs (BUG 30421) PR 30421 * cofflink.c (_decoration_hash_newfunc): New function. (_bfd_coff_link_hash_table_init): Call it. * libcoff-in.h (struct coff_link_hash_table): Add decoration_hash field. (struct decoration_hash_entry): Declare. (_decoration_hash_newfunc): Prototype. * libcoff.h: Regenerate. * emultempl/pe.em (set_decoration): New function. (pe_fixup_stdcalls): Call the new function. * emultempl/pep.em (set_decoration): New function. (pep_fixup_stdcalls): Call the new function. * pe-dll.c (make_one): Check for decoated symbols. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30390] Allow to specify custom stub for PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30390 --- Comment #3 from Nick Clifton --- Hi Pali, I must admit that I am reluctant to pursue this feature. This stub is only used when running an executable in a DOS environment yes ? So its utility in modern Windows based systems seems to be quite small, and implementing it is likely to introduce new bugs into the linker. For the record the function where the hard-coded message is held is bfd/peicode.h:pe_mkobject(). The message is stored in a 64 byte array in the pe_data_type structure. Adding an option to store a custom sequence of 64 bytes into this structure would not be too hard, but I imagine that what you really want is to be able to store a stub of an arbitrary length. This would mean putting in a lot more changes, and would be much more likely to break things. This is why I am reluctant to have a go at this. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #5 from Nick Clifton --- (In reply to Pali Rohár from comment #4) > So it looks like that IMAGE_SCN_MEM_READ characteristic is always added, > IMAGE_SCN_MEM_WRITE characteristic is added only when readonly flag is not > specified. And other flags add following characteristics: > > alloc --> IMAGE_SCN_CNT_UNINITIALIZED_DATA > noload --> IMAGE_SCN_MEM_DISCARDABLE > debug --> IMAGE_SCN_CNT_INITIALIZED_DATA + IMAGE_SCN_MEM_DISCARDABLE > code --> IMAGE_SCN_CNT_CODE + IMAGE_SCN_MEM_EXECUTE > data --> IMAGE_SCN_CNT_INITIALIZED_DATA > exclude --> IMAGE_SCN_MEM_DISCARDABLE > share --> IMAGE_SCN_MEM_SHARED OK, so obviously it would be good to extend the list of supported flags to include the PE names. I will have a look at doing this. > What is difference between noload and exclude? Seems that both flags do same > thing. Well for ELF based targets the exclude flag marks a section which should be discarded unless a partial link is being performed. That is they are kept around if linking with the -r or --relocateable options, but otherwise they are discarded. The noload flag marks a section which is not normally discarded, but which also is not loaded into memory when the application runs. In theory the exclude flag should probably map to the IMAGE_SCN_LNK_REMOVE flag, but this does not appear to happen in practice. At least not at the moment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30145] No way to specify PE IMAGE_SCN_* characteristics
https://sourceware.org/bugzilla/show_bug.cgi?id=30145 --- Comment #6 from Pali Rohár --- IMAGE_SCN_LNK_REMOVE is valid only for object files, not for executables. But yes, from above description exclude flag should be mapped to IMAGE_SCN_LNK_REMOVE characteristics. Also it would be great to synchronize support for these flags with flags supported by assembler: https://sourceware.org/binutils/docs/as/Section.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30390] Allow to specify custom stub for PE binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=30390 --- Comment #4 from Pali Rohár --- Ok, I understand reasons. And I think that replacing 64-byte array by another with same size by some special linker flag has likely very small value, because this simple replacement can be done by e.g. dd tool. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/11601] Solaris assembler compatibility doesn't work
https://sourceware.org/bugzilla/show_bug.cgi?id=11601 --- Comment #4 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=4cb88cfae84363cef6ed59d9d458a20ff2e1e893 commit 4cb88cfae84363cef6ed59d9d458a20ff2e1e893 Author: Alan Modra Date: Thu May 18 09:26:18 2023 +0930 PR11601, Solaris assembler compatibility doesn't work Well, it doesn't work on x86 or ppc, which both have # starting comments anywhere on a line. I think it is therefore only useful on sparc. PR 11601 * config/obj-elf.c (obj_elf_section_word): Only compile for sparc. (obj_elf_section): Only support solaris .section directive on sparc. * doc/as.texi (Section): Mention that solaris .section directive is only supported for sparc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/11601] Solaris assembler compatibility doesn't work
https://sourceware.org/bugzilla/show_bug.cgi?id=11601 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at sources dot redhat.c |amodra at gmail dot com |om | --- Comment #5 from Alan Modra --- Fixed, after only 13 years -- You are receiving this mail because: You are on the CC list for the bug.
