[Bug binutils/17065] New: Building z80-none-elf fails: gas/output-file.c:37:43: error: ‘TARGET_FORMAT’ undeclared (first use in this function)
https://sourceware.org/bugzilla/show_bug.cgi?id=17065 Bug ID: 17065 Summary: Building z80-none-elf fails: gas/output-file.c:37:43: error: ‘TARGET_FORMAT’ undeclared (firs t use in this function) Product: binutils Version: 2.24 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Trying to build binutils for z80-none-elf fails with the error: gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.24/gas -I. -I../../binutils-2.24/gas -I../bfd -I../../binutils-2.24/gas/config -I../../binutils-2.24/gas/../include -I../../binutils-2.24/gas/.. -I../../binutils-2.24/gas/../bfd -DLOCALEDIR="\"/opt/z80/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT output-file.o -MD -MP -MF .deps/output-file.Tpo -c -o output-file.o ../../binutils-2.24/gas/output-file.c ../../binutils-2.24/gas/output-file.c: In function ‘output_file_cre ate’: ../../binutils-2.24/gas/output-file.c:37:43: error: ‘TARGET_FORMAT ’ undeclared (first use in this function) else if (!(stdoutput = bfd_openw (name, TARGET_FORMAT))) ^ ../../binutils-2.24/gas/output-file.c:37:43: note: each undeclared identifi er is reported only once for each function it appears in The configure command was: ../binutils-2.24/configure --target=z80-none-elf --prefix=/opt/z80 The same happes both with 2.24 and with git HEAD. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/17065] Building z80-none-elf fails: gas/output-file.c:37:43: error: ‘TARGET_FORMAT’ undeclared (first use in this function)
https://sourceware.org/bugzilla/show_bug.cgi?id=17065 --- Comment #1 from hpa at zytor dot com --- The build host in question was a Linux x86-64 system running current Fedora 20 (binutils-2.23.88.0.1-13.fc20.x86_64 and gcc-4.8.2-7.fc20.x86_64). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/17065] Building z80-none-elf fails: gas/output-file.c:37:43: error: ‘TARGET_FORMAT’ undeclared (first use in this function)
https://sourceware.org/bugzilla/show_bug.cgi?id=17065 hpa at zytor dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from hpa at zytor dot com --- Nevermind, looks like only z80-none-coff is supported, not z80-none-elf. I would have expected configure to fail for an unsupported configuration, but it looks like that doesn't actually happen. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #5 from hpa at zytor dot com --- On January 30, 2016 9:08:32 AM PST, "hjl.tools at gmail dot com" wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #3 from H.J. Lu --- >(In reply to H.J. Lu from comment #2) >> pfx_compressed, which is __pm_code_lma, is wrong: >> >> section .prefix nowrite progbits align=16 >> pfx_start dd _start ; Start of raw chunk >> pfx_compressed dd __pm_code_lma; Start of compressed chunk >> pfx_cdatalendd lzo_data_size; Pointer to compressed size >field >> %if IS_ISOLINUX >> pfx_checksumdd bi_length; File length and checksum >fields >> %else >> pfx_checksumdd 0; No checksum >> %endif >> pfx_maxlma dd MaxLMA ; Maximum size >> >> 9770 B __pm_code_lma > >bios/core/ldlinux.elf is built with -pie. The value of __pm_code_lma >won't be known until run-time: > >Relocation section '.rel.dyn' at offset 0x1ba34 contains 1435 entries: > Offset InfoTypeSym.Value Sym. Name >... >0004 00010d01 R_386_32 9770 __pm_code_lma >8f62 00010d01 R_386_32 9770 __pm_code_lma > >Peter, am I missing something? ldlinux.elf shouldn't be build pie, so that would explain why. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #6 from hpa at zytor dot com --- On January 30, 2016 12:53:18 PM PST, hpa at zytor dot com wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #5 from hpa at zytor dot com --- >On January 30, 2016 9:08:32 AM PST, "hjl.tools at gmail dot com" > wrote: >>https://sourceware.org/bugzilla/show_bug.cgi?id=19538 >> >>--- Comment #3 from H.J. Lu --- >>(In reply to H.J. Lu from comment #2) >>> pfx_compressed, which is __pm_code_lma, is wrong: >>> >>> section .prefix nowrite progbits align=16 >>> pfx_start dd _start ; Start of raw chunk >>> pfx_compressed dd __pm_code_lma; Start of compressed chunk >>> pfx_cdatalendd lzo_data_size; Pointer to compressed size >>field >>> %if IS_ISOLINUX >>> pfx_checksumdd bi_length; File length and checksum >>fields >>> %else >>> pfx_checksumdd 0; No checksum >>> %endif >>> pfx_maxlma dd MaxLMA ; Maximum size >>> >>> 9770 B __pm_code_lma >> >>bios/core/ldlinux.elf is built with -pie. The value of __pm_code_lma >>won't be known until run-time: >> >>Relocation section '.rel.dyn' at offset 0x1ba34 contains 1435 entries: >> Offset InfoTypeSym.Value Sym. Name >>... >>0004 00010d01 R_386_32 9770 __pm_code_lma >>8f62 00010d01 R_386_32 9770 __pm_code_lma >> >>Peter, am I missing something? > >ldlinux.elf shouldn't be build pie, so that would explain why. What I genuinely can't remember offhand is whether or not it is a combination of pic and non-pic objects... -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #11 from hpa at zytor dot com --- On January 30, 2016 2:18:51 PM PST, "hjl.tools at gmail dot com" wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #8 from H.J. Lu --- >(In reply to h...@zytor.com from comment #6) >> >> > >> >ldlinux.elf shouldn't be build pie, so that would explain why. >> >> What I genuinely can't remember offhand is whether or not it is a >> combination of pic and non-pic objects... > >It may be used for EFI. But that is not built in core/bios. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #13 from hpa at zytor dot com --- On January 30, 2016 4:19:57 PM PST, "hjl.tools at gmail dot com" wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #12 from H.J. Lu --- >(In reply to h...@zytor.com from comment #11) >> >> But that is not built in core/bios. > >core/Makefile has > ># Set up the NASM and LD options for the architecture >NASM_ELF = "unknown" >LD_PIE = "unknown" >ifeq ($(ARCH),i386) >NASM_ELF = elf >LD_PIE = -pie >endif >ifeq ($(ARCH),x86_64) >NASM_ELF = elf64 >#LD_PIE = --pic-executable >LD_PIE = >endif And that is true for most of the modules. Let me look into it later. However, part of the weirdness is that it is a partly pic and partly non-pic object. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 hpa at zytor dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #15 from hpa at zytor dot com --- So ldlinux.elf on BIOS is an odd duck. It contains bits that are relocated and bits that are not relocated, but the two components cross-call, and both have symbols that need to be exported. 2.25 generates output that has the unrelocated values (that is, what would be exported from the linker script without -pie) in the output sections, and R_386_RELATIVE relocations in .rel.dyn. At the same time, I also observe that with 2.25, there seem to be R_386_RELATIVE annotations for locations which reference ABS symbols, which seems very odd; fortunately that particular code is all executed before relocation is performed. I'm going to muck with the linker script to see if I can improve the situation. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #17 from hpa at zytor dot com --- Created attachment 8966 --> https://sourceware.org/bugzilla/attachment.cgi?id=8966&action=edit Linker script -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #16 from hpa at zytor dot com --- I have tried removing -pie (which shouldn't actually be necessary); however, when I do so, ld no longer generates the sections which are necessary to export symbols to dynamic libraries. The command line looks like: ld -m elf_i386 -Bdynamic -Bsymbolic -Bsymbolic-functions \ -E --hash-style=gnu -T /home/hpa/syslinux/git/core/i386/syslinux.ld -M -o ldlinux.elf ldlinux.o \ --start-group libcom32.a --whole-archive /home/hpa/syslinux/git/bios/com32/lib/libcom32core.a libldlinux.a --end-group \ > ldlinux.map ... and I will attach the linker script. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #18 from hpa at zytor dot com --- Note that despite the use of -pie the only reason for including that option at this time is to export the necessary symbols. However, this appears to have been there from the start in order to actually generate the dynamic output sections. This is confusing to me, because the two would seem unrelated to me. Adding KEEP to the relevant sections have appeared to make no difference. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #20 from hpa at zytor dot com --- What I'm telling you is that without either -pie or at least one undefined symbol *and* a shared library specified to the linker, all the dynamic sections disappear. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #22 from hpa at zytor dot com --- The output file exports symbols to other ELF modules which are loaded (ldlinux.elf includes the dynamic linker.) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #23 from hpa at zytor dot com --- So to summarize: 1. ldlinux.elf is an executable which does not depend on any other object 2. It does not require relocation 3. ldlinux.elf *includes* an ELF dynamic linker as well as a core library 4. The symbols from the core library should be exported to dynamic ELF objects which are loaded later -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #24 from hpa at zytor dot com --- ... and when linking with "-Bdynamic" without "-pie", ld removes all the sections related to dynamic linking when there are no undefined symbols which need resolution, with the result that loading the dynamic modules fail. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #26 from hpa at zytor dot com --- When compiled in that fashion I cannot reproduce the original problem. However, I will shortly upload a test case for -Bdynamic without -pie. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #27 from hpa at zytor dot com --- Created attachment 8967 --> https://sourceware.org/bugzilla/attachment.cgi?id=8967&action=edit Test case for -Bdynamic without -pie This test case shows how dynamic symbols are not exported without -pie, despite -Bdynamic. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #28 from hpa at zytor dot com --- When building *without* --disable-x86-relax-relocations then the test case I submitted exhibits the problem that causes syslinux to fail to build: you can see offset 0x30 (xyzzy_ptr) of with-pie/test1.bin is zero, rather than 0x1f as would be expected. When compiled with --disable-x86-relax-relocations the expected value is obtained. However, it would be better to not need the -pic at all. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #30 from hpa at zytor dot com --- tools/relocs.c isn't actually used, so it won't make any difference (I deleted it from my private tree to verify, together with several other unused files.) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 hpa at zytor dot com changed: What|Removed |Added Version|2.27 (HEAD) |2.26 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #31 from hpa at zytor dot com --- I have now removed the unused files from the Syslinux git tree. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #35 from hpa at zytor dot com --- With that patch, syslinux builds but is non-functional; the header looks correct but there is a problem somewhere else. I have uploaded the entire build to: http://www.zytor.com/~hpa/syslinux/syslinux-ld.tar.xz The directory "git" was build with binutils.git git ID 8e50258985f01270b142d0537d7b80e789e4d7d7 plus your patch. The directory "git.ref" was build with binutils-2.25-15.fc23.x86_64 from Fedora, and works. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #37 from hpa at zytor dot com --- On February 10, 2016 3:33:00 PM PST, "hjl.tools at gmail dot com" wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #36 from H.J. Lu --- >(In reply to h...@zytor.com from comment #35) >> With that patch, syslinux builds but is non-functional; the header >looks >> correct but there is a problem somewhere else. > >The header is correct without my linker patch. > >> I have uploaded the entire build to: >> >> http://www.zytor.com/~hpa/syslinux/syslinux-ld.tar.xz >> >> The directory "git" was build with binutils.git git ID >> 8e50258985f01270b142d0537d7b80e789e4d7d7 plus your patch. >> >> The directory "git.ref" was build with binutils-2.25-15.fc23.x86_64 >from >> Fedora, and works. > >I need the linker command line for creating ldlinux.elf. You can just do: rm -f bios/core/ldlinux.* make bios |& tee make.log That will give you the linker command line, as well as the postprocessing. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #38 from hpa at zytor dot com --- On February 10, 2016 3:33:00 PM PST, "hjl.tools at gmail dot com" wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #36 from H.J. Lu --- >(In reply to h...@zytor.com from comment #35) >> With that patch, syslinux builds but is non-functional; the header >looks >> correct but there is a problem somewhere else. > >The header is correct without my linker patch. > >> I have uploaded the entire build to: >> >> http://www.zytor.com/~hpa/syslinux/syslinux-ld.tar.xz >> >> The directory "git" was build with binutils.git git ID >> 8e50258985f01270b142d0537d7b80e789e4d7d7 plus your patch. >> >> The directory "git.ref" was build with binutils-2.25-15.fc23.x86_64 >from >> Fedora, and works. > >I need the linker command line for creating ldlinux.elf. I suspect my changes to the linker script to make the LMA symbols absolute might have fixed the header problem, but the small test case should still show it. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #41 from hpa at zytor dot com --- On February 10, 2016 4:15:39 PM PST, "hjl.tools at gmail dot com" wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #39 from H.J. Lu --- >(In reply to h...@zytor.com from comment #38) >> >> I suspect my changes to the linker script to make the LMA symbols >absolute >> might have fixed the header problem, but the small test case should >still >> show it. > >We may have more than one issues here: > >1. Without -pie, no dynamic symbols. I tried the small testcase with >binutils 2.25.2: > >[hjl@gnu-6 without-pie]$ >/export/build/gnu/binutils-misc/build-x86_64-linux/ld/ld-new -m >elf_i386 -Ttext >0 -Bdynamic -Bsymbolic -E -o test1.elf test1.o >[hjl@gnu-6 without-pie]$ >/export/build/gnu/binutils-misc/build-x86_64-linux/ld/ld-new -v >GNU ld (GNU Binutils) 2.25.2 >[hjl@gnu-6 without-pie]$ nm -Dn test1.elf >nm: test1.elf: no symbols > >There is no dynamic symbol either. > >[hjl@gnu-6 without-pie]$ > >2. With -pie, still doesn't work. Please tell me what is wrong in >the binary generated by 2.26. In the test case, byte 0x30 of test1.bin should be 0x1f. In the output I believe I sent it is 0x00 from ld 2.26. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #40 from hpa at zytor dot com --- On February 10, 2016 4:15:39 PM PST, "hjl.tools at gmail dot com" wrote: >https://sourceware.org/bugzilla/show_bug.cgi?id=19538 > >--- Comment #39 from H.J. Lu --- >(In reply to h...@zytor.com from comment #38) >> >> I suspect my changes to the linker script to make the LMA symbols >absolute >> might have fixed the header problem, but the small test case should >still >> show it. > >We may have more than one issues here: > >1. Without -pie, no dynamic symbols. I tried the small testcase with >binutils 2.25.2: > >[hjl@gnu-6 without-pie]$ >/export/build/gnu/binutils-misc/build-x86_64-linux/ld/ld-new -m >elf_i386 -Ttext >0 -Bdynamic -Bsymbolic -E -o test1.elf test1.o >[hjl@gnu-6 without-pie]$ >/export/build/gnu/binutils-misc/build-x86_64-linux/ld/ld-new -v >GNU ld (GNU Binutils) 2.25.2 >[hjl@gnu-6 without-pie]$ nm -Dn test1.elf >nm: test1.elf: no symbols > >There is no dynamic symbol either. > >[hjl@gnu-6 without-pie]$ > >2. With -pie, still doesn't work. Please tell me what is wrong in >the binary generated by 2.26. Yes, 1 really should be a separate enhancement PR. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19617] New: ELF: Allow -E to work without -pic/-pie/-shared in the absence of undefined symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19617 Bug ID: 19617 Summary: ELF: Allow -E to work without -pic/-pie/-shared in the absence of undefined symbols Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Target Milestone: --- If neither -pic, -pie, or -shared is specified, *and* there are no undefined symbols in the executable, ld produces no dynamic sections. However, if -E is specified, the executable is supposed to export its symbols to modules loaded in the future. This configuration is common in embedded environments, including boot loaders. The current workaround is to use -pie, but that generates a manifest .rel.dyn section which is pure waste if -pie isn't actually required. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19617] ELF: Allow -E to work without -pic/-pie/-shared in the absence of undefined symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19617 hpa at zytor dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19538] ld >= 2.26 breaks syslinux (bios) build
https://sourceware.org/bugzilla/show_bug.cgi?id=19538 --- Comment #44 from hpa at zytor dot com --- With that branch, Syslinux builds and runs correctly. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19617] ELF: Allow -E to work without -pic/-pie/-shared in the absence of undefined symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19617 --- Comment #3 from hpa at zytor dot com --- The patch works. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20046] New: x86 feature request: build an instruction including rex and modr/m
https://sourceware.org/bugzilla/show_bug.cgi?id=20046
Bug ID: 20046
Summary: x86 feature request: build an instruction including
rex and modr/m
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: enhancement
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: hpa at zytor dot com
Target Milestone: ---
In the Linux kernel, we constantly bump into the problem that we need to use
new instructions, but that backwards versions of gas which we still need to
handle don't support them. For plain instructions, it is fine to use .byte,
but it gets very suboptimal when the instructions takes registers or memory
operands.
I'm wondering if something like this might make sense:
.rex[/w] ,
.modrm ,
... which would generate the REX and modr/m (+SIB, displacement etc needed for
the addressing mode) bytes for an instruction with the given r and m operands.
r might be an integer immediate for cases where the register operand is used as
an opcode extension.
This would allow a gcc inline of the form:
asm(".byte 0xf3 ; .rex/w %0,%1 ; .byte 0x0f, 0x99 ; .modrm %0,%1"
: "=rm" (...) : "r" (...));
... for some random new instruction with the SDM description F3 0F 99 /r.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20046] x86 feature request: build an instruction including rex and modr/m
https://sourceware.org/bugzilla/show_bug.cgi?id=20046 --- Comment #3 from hpa at zytor dot com --- I thought about it some more, and a better choice that .rex[/w] would be something like .inspfxs[bwlq] , that would be able to generate 66, 67, or REX prefixes as appropriate. The possible combinations would be: can be a register or an immediate in the range 0-7. If it is a register, it sets the default operand size. If a register, it controls REX.R for .inspfxs. can be a register or a memory operand. If it is a register, it sets the default operand size. If a register, it controls REX.B; if a memory operand it controls REX.B and REX.X for .inspfxs. If neither nor is a register, and the memory operand isn't size-specified with the PTR argument (in Intel syntax), then [bwlq] has to be provided to the .inspfxs operation, (as with any other instruction). It doesn't matter for .modrm, of course. b - no 66 prefix nor REX.W in any mode w - 66 prefix in 32- or 64-bit mode l - 66 prefix in 16-bit mode q - REX.W (only valid in 64-bit mode) A 67 prefix would be generated if appropriate for the memory operand. .vex and .evex pseudo-ops could be added as well. However, scaled SIB and all the various EVEX modes would make that much more complicated. It is unlikely we would use those in the Linux kernel, but there might be user-space programs that might be interested. I would suggest treating that as a potential future extension if it turns out to be desirable. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20046] x86 feature request: build an instruction including rex and modr/m
https://sourceware.org/bugzilla/show_bug.cgi?id=20046 --- Comment #4 from hpa at zytor dot com --- "Register" at least for .inspfxs would mean any of GPR, segment, BND, CR, DR, MM or XMM registers. Since YMM, ZMM, or K registers are not encodable without VEX/XOP/EVEX prefixes those presumably should be supported if and when .vex/.xop/.evex are added. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20046] x86 feature request: build an instruction including rex and modr/m
https://sourceware.org/bugzilla/show_bug.cgi?id=20046 --- Comment #5 from hpa at zytor dot com --- x87 registers use a different encoding than modr/m; the upper two bits can be something other than 11 for a register operation. However, it seems very unlikely that new x87 instructions will be added at this point, so I don't see any significant reason to add pseudoops to synthesize x87 instructions. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/29341] New: RISC-V: -march=rv32imcb fails
https://sourceware.org/bugzilla/show_bug.cgi?id=29341 Bug ID: 29341 Summary: RISC-V: -march=rv32imcb fails Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Target Milestone: --- Specifying -march=rv32imcb (or any other combination that includes the "b" extension) invariably causes the error message: [hpa@tazenda tmp]$ riscv32-unknown-elf-as -march=rv32imcb -o b-ext.o b-ext.s Assembler messages: Error: cannot find default versions of the ISA extension `b' b-ext.s:2: Error: unrecognized opcode `clz a0,a0' ... many more ... Enumerating sub-extensions work: riscv32-unknown-elf-as -march=rv32imc_zba_zbb_zbc_zbs -o b-ext.o b-ext.s This is using b-ext.s from gas/testsuite/gas/riscv/b-ext.s as test case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29341] RISC-V: -march=rv32imcb fails due to cannot find default versions of the ISA extension `b'
https://sourceware.org/bugzilla/show_bug.cgi?id=29341 hpa at zytor dot com changed: What|Removed |Added Summary|RISC-V: -march=rv32imcb |RISC-V: -march=rv32imcb |fails |fails due to cannot find ||default versions of the ISA ||extension `b' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29342] New: RISC-V 32: disassembly mishandles symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29342 Bug ID: 29342 Summary: RISC-V 32: disassembly mishandles symbols Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Target Milestone: --- It is common on embedded systems to put I/O registers in the high half of the address space; on RISC-V it is particularly desirable to put address space for I/O devices which only need a limited number of addresses in the high 2K, which means they can be addressed using negative offsets from (zero), avoiding the need for a base pointer. However, objdump disassembly shows addresses in the upper half of the address space as offsets from the highest-addressed symbol (possibly due to incorrectly treating them as 64-bit numbers before searching?) The result means disassembly is needlessly hard to read: iobase = 0xff00 .globl IOREG_FOO IOREG_FOO = iobase .globl IOREG_BAR IOREG_BAR = iobase + 4 .section ".text","ax" .globl _start _start: .if iobase >= 0xf800 sw a0, IOREG_FOO(zero) .else la t0, IOREG_FOO sw a0, (t0) .endif ret riscv32-unknown-elf-as -march=rv32i -o highsym.o highsym.s riscv32-unknown-elf-ld -o highsym.elf highsym.o riscv32-unknown-elf-objdump -d highsym.elf highsym.elf: file format elf32-littleriscv Disassembly of section .text: 00010074 <_start>: 10074: f0a02023sw a0,-256(zero) # ff00 10078: 8067ret -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29342] RISC-V 32: disassembly mishandles symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29342 --- Comment #1 from hpa at zytor dot com --- Created attachment 14198 --> https://sourceware.org/bugzilla/attachment.cgi?id=14198&action=edit highsym.s test case -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29342] RISC-V 32: disassembly mishandles symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29342 --- Comment #2 from hpa at zytor dot com --- Created attachment 14199 --> https://sourceware.org/bugzilla/attachment.cgi?id=14199&action=edit highsym.elf test case (compiled) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29342] RISC-V 32: disassembly mishandles negative symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=29342 H. Peter Anvin changed: What|Removed |Added Summary|RISC-V 32: disassembly |RISC-V 32: disassembly |mishandles symbols |mishandles negative symbols -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30752] New: RFE: Z80: allow relaxed syntax of instructions using register A
https://sourceware.org/bugzilla/show_bug.cgi?id=30752 Bug ID: 30752 Summary: RFE: Z80: allow relaxed syntax of instructions using register A Product: binutils Version: unspecified Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Target Milestone: --- In the official Z80 syntax, register A is supposed to be written out when, and only when, the same instruction takes other operands, like HL: ADD A,L ; Because ADD HL,DE XOR L; No other XOR In practice, this is needlessly confusing for the programmer; as a result, many (probably most) legacy Z80 assemblers allow: ADD L ... and at least some also allow ... XOR A,L Allowing this relaxed syntax would definitely help porting legacy code. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30752] RFE: Z80: allow relaxed syntax of instructions using register A
https://sourceware.org/bugzilla/show_bug.cgi?id=30752 H. Peter Anvin changed: What|Removed |Added Version|unspecified |2.42 (HEAD) Target||z80-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30753] New: RFE: Z80: enable ! as line separator character
https://sourceware.org/bugzilla/show_bug.cgi?id=30753 Bug ID: 30753 Summary: RFE: Z80: enable ! as line separator character Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Target Milestone: --- Legacy 8080/Z80 assemblers, at least the ones originating in the CP/M world, allow the use of the ! character as a line separator (similar to ; in most other gas targets, but ; is the comment character in Z80 syntax.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30753] RFE: Z80: enable ! as line separator character
https://sourceware.org/bugzilla/show_bug.cgi?id=30753 H. Peter Anvin changed: What|Removed |Added Target||z80-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30754] New: RFE: Z80: allow ? in symbol names
https://sourceware.org/bugzilla/show_bug.cgi?id=30754 Bug ID: 30754 Summary: RFE: Z80: allow ? in symbol names Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Target Milestone: --- Legacy 8080/Z80 code from the CP/M world generally *requires* the character ? to be permitted in symbol names. Enabling this in gas would make porting such legacy code easier. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30754] RFE: Z80: allow ? in symbol names
https://sourceware.org/bugzilla/show_bug.cgi?id=30754 H. Peter Anvin changed: What|Removed |Added Severity|normal |enhancement Target||z80-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30752] RFE: Z80: allow relaxed syntax of instructions using register A
https://sourceware.org/bugzilla/show_bug.cgi?id=30752 --- Comment #1 from H. Peter Anvin --- At least for the basic Z80 instruction set this is applicable to the following instructions: Make "A," optional for: ADD ADC ABC Optionally allow "A," for: SUB AND OR XOR CP -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30755] New: RFE: z80: enable OBJ_COMPLEX_RELOC
https://sourceware.org/bugzilla/show_bug.cgi?id=30755 Bug ID: 30755 Summary: RFE: z80: enable OBJ_COMPLEX_RELOC Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hpa at zytor dot com Target Milestone: --- Some legacy Z80 object formats, like the z80asm object format used by z88dk, allows arbitrary expressions on global symbols. The z88dk has expressed an interest in switching to GNU binutils z80-*-elf, but this issue has held it up due to concerns about breaking existing code. As far as I can tell -- and experimentation seems to confirm -- this simply requires defining OBJ_COMPLEX_RELOC in gas/config/tc-z80.h; the rest is already handled in generic code. This would make GNU binutils support the same level of functionality, allowing this migration. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30755] RFE: z80: enable OBJ_COMPLEX_RELOC
https://sourceware.org/bugzilla/show_bug.cgi?id=30755 H. Peter Anvin changed: What|Removed |Added Target||z80-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/12627] New: ld from binutils 2.21.51.0.6 mishandles differences between two section-relative symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=12627 Summary: ld from binutils 2.21.51.0.6 mishandles differences between two section-relative symbols Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassig...@sources.redhat.com ReportedBy: h...@zytor.com Created attachment 5344 --> http://sourceware.org/bugzilla/attachment.cgi?id=5344 Linker script Defining two section-relative symbols in a linker script and subtracting them produces the wrong result (specifically, they end up with the section base added in.) See attached test case; in particular, %ecx gets 0x500 loaded into it instead of the expected 0x100. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12627] ld from binutils 2.21.51.0.6 mishandles differences between two section-relative symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=12627 --- Comment #1 from hpa at zytor dot com 2011-03-31 01:21:57 UTC --- Created attachment 5345 --> http://sourceware.org/bugzilla/attachment.cgi?id=5345 Assembly file as --32 -o symerr.o symerr.s ld -T symerr.ld -o symerr.elf symerr.o -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12627] ld from binutils 2.21.51.0.6 mishandles differences between two section-relative symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=12627 --- Comment #3 from hpa at zytor dot com 2011-04-01 04:10:58 UTC --- I just downloaded binutils-2.21.51.06.tar.bz2 from your repository on kernel.org and built it myself, and I could reproduce the bug there. The date part of the version number is different from your trace below, though (and the date part agrees with what is in Fedora 15 Alpha): : tazenda 135 ; nm symerr.elf 0500 A __bss16_dwords 1400 B __bss16_end 1400 B __bss16_len 1000 B __bss16_start 800f T __text16_end 8000 T __text16_start 8000 T _start : tazenda 136 ; objdump -dw symerr.elf symerr.elf: file format elf32-i386 Disassembly of section .text16: 8000 <__text16_start>: 8000: bf 00 10 00 00 mov$0x1000,%edi 8005: b9 00 05 00 00 mov$0x500,%ecx 800a: 31 c0 xor%eax,%eax 800c: f3 a5 rep movsl %ds:(%esi),%es:(%edi) 800e: c3 ret : tazenda 137 ; ld -V GNU ld (Linux/GNU Binutils) 2.21.51.0.6.20110118 Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om : tazenda 138 ; On 03/31/2011 04:15 PM, hjl.tools at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=12627 > > --- Comment #2 from H.J. Lu 2011-03-31 23:15:21 > UTC --- > I got > > [hjl@gnu-6 pr12627]$ make > ./usr/local/bin/as --32 -o x.o x.s > ./usr/local/bin/ld -m elf_i386 -T x.ld -o x x.o > nm x > 0100 A __bss16_dwords > 1400 B __bss16_end > 0400 A __bss16_len > 1000 B __bss16_start > 800f T __text16_end > 8000 T __text16_start > 8000 T _start > objdump -dw x > > x: file format elf32-i386 > > > Disassembly of section .text16: > > 8000 <__text16_start>: > 8000:bf 00 10 00 00 mov$0x1000,%edi > 8005:b9 00 01 00 00 mov$0x100,%ecx > 800a:31 c0xor%eax,%eax > 800c:f3 a5rep movsl %ds:(%esi),%es:(%edi) > 800e:c3 ret > [hjl@gnu-6 pr12627]$ ./usr/local/bin/ld -V > GNU ld (Linux/GNU Binutils) 2.21.51.0.6.20110123 > Supported emulations: >elf_x86_64 >elf32_x86_64 >elf_i386 >i386linux >elf_l1om > [hjl@gnu-6 pr12627]$ > > It looks OK to me. > -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12627] ld from binutils 2.21.51.0.6 mishandles differences between two section-relative symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=12627 --- Comment #4 from hpa at zytor dot com 2011-04-01 04:14:06 UTC --- Just tested binutils 2.21.51.0.7. It does NOT appear to have the same problem. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
