[Bug gas/28919] New: powerpc e500mc Error: unrecognized opcode: `isel'
https://sourceware.org/bugzilla/show_bug.cgi?id=28919 Bug ID: 28919 Summary: powerpc e500mc Error: unrecognized opcode: `isel' Product: binutils Version: 2.38 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: judge.packham+glibc at gmail dot com Target Milestone: --- When building with -mcpu=e500mc the assembler reports produces the following error [ALL ]/tmp/ccafVatb.s: Assembler messages: [ERROR]/tmp/ccafVatb.s:143: Error: unrecognized opcode: `isel' [ERROR]/tmp/ccafVatb.s:146: Error: unrecognized opcode: `isel' [ERROR]/tmp/ccafVatb.s:502: Error: unrecognized opcode: `isel' [ERROR]/tmp/ccafVatb.s:3781: Error: unrecognized opcode: `isel' According to the EREF manual isel is a valid instruction for e500mc and GCC certainly thinks it is free to use it but gas doesn't allow it. I'll try and narrow things down to a simple reproduction. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28919] powerpc e500mc Error: unrecognized opcode: `isel'
https://sourceware.org/bugzilla/show_bug.cgi?id=28919 --- Comment #1 from Chris Packham --- Created attachment 13993 --> https://sourceware.org/bugzilla/attachment.cgi?id=13993&action=edit assembly file emitted by GCC -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28919] powerpc e500mc Error: unrecognized opcode: `isel'
https://sourceware.org/bugzilla/show_bug.cgi?id=28919 --- Comment #2 from Chris Packham --- Debugging a bit further looks like the generated assembly listing has a ".machine ppc" directive in it which overrides the -me500mc from the command line. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28919] powerpc e500mc Error: unrecognized opcode: `isel'
https://sourceware.org/bugzilla/show_bug.cgi?id=28919 --- Comment #3 from Chris Packham --- This might be resolve by https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=cebc89b9328;hp=9cbed90ee623d75e31994e7943960c997ba565f2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28919] powerpc e500mc Error: unrecognized opcode: `isel'
https://sourceware.org/bugzilla/show_bug.cgi?id=28919 Chris Packham changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Chris Packham --- Yep looks like that commit resolves the issue. I'll mark the issue as resolved. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/31320] New: binutils-2.42 build failure on macos - error: 'uchar.h' file not found
https://sourceware.org/bugzilla/show_bug.cgi?id=31320
Bug ID: 31320
Summary: binutils-2.42 build failure on macos - error:
'uchar.h' file not found
Product: binutils
Version: 2.42
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: judge.packham+glibc at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Just updating crosstool-ng to the latest binutils and github's macOS makers
complained
Error:
/Users/runner/work/crosstool-ng/crosstool-ng/.build/aarch64-unknown-linux-gnu/src/binutils/gold/output.cc:32:10:
fatal error: 'uchar.h' file not found
Full log is available at
https://github.com/crosstool-ng/crosstool-ng/actions/runs/7704312122/artifacts/1204824789
I don't personally do macOS but I'm guessing uchar.h is not available on that
platform (or at least the version of it used by github).
The uchar.h usage looks like a recent addition from commit 5e9091dab88 ("gold:
Use char16_t, char32_t instead of uint16_t, uint32_t as character types"), but
that appears to be addressing an issue with newer libc++ versions so I'm not
sure what the fix would be.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/31320] binutils-2.42 build failure on macos - error: 'uchar.h' file not found
https://sourceware.org/bugzilla/show_bug.cgi?id=31320 --- Comment #2 from Chris Packham --- It looks like is a C11 thing so maybe instead of __APPLE__ some check around that would be better. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/31320] binutils-2.42 build failure on macos - error: 'uchar.h' file not found
https://sourceware.org/bugzilla/show_bug.cgi?id=31320 --- Comment #3 from Chris Packham --- Looks like it could be imported from gnulib https://www.gnu.org/software/gnulib/manual/html_node/uchar_002eh.html for systems that don't have it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/32016] New: ld.gold error unsupported -mbss-plt code
https://sourceware.org/bugzilla/show_bug.cgi?id=32016 Bug ID: 32016 Summary: ld.gold error unsupported -mbss-plt code Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: judge.packham+glibc at gmail dot com CC: ian at airs dot com Target Milestone: --- I'm experimenting with adding ld.gold as an option to our toolchains but I'm hitting an error. This happens to be from the lxcfs package which tries to use ld.gold if it's available. This only seems to affect our powerpc 32 builds. Other architectures seem fine. I've tried with and without -mbss-plt in $CFLAGS. I'm not sure if this is a compiler issue, linker issue or just a problem with the flags we are passing The error is $ powerpc-e500mc-linux-gnu-gcc -o liblxcfs.so liblxcfs.so.p/src_bindings.c.o liblxcfs.so.p/src_cgroups_cgfsng.c.o liblxcfs.so.p/src_cgroups_cgroup.c.o liblxcfs.so.p/src_cgroups_cgroup2_devices.c.o liblxcfs.so.p/src_cgroups_cgroup_utils.c.o liblxcfs.so.p/src_cgroup_fuse.c.o liblxcfs.so.p/src_cpuset_parse.c.o liblxcfs.so.p/src_lxcfs.c.o liblxcfs.so.p/src_proc_cpuview.c.o liblxcfs.so.p/src_proc_fuse.c.o liblxcfs.so.p/src_proc_loadavg.c.o liblxcfs.so.p/src_sysfs_fuse.c.o liblxcfs.so.p/src_utils.c.o -Wl,--as-needed -Wl,--allow-shlib-undefined -shared -fPIC -Wl,--gc-sections -Wl,-z,relro -Wl,-z,now -Wl,-fuse-ld=gold --sysroot=/usr/src/output/ppc_e500mc/lxcfs/staging -pthread -Wl,--start-group /usr/src/output/ppc_e500mc/lxcfs/staging/usr/lib/libfuse3.so -lpthread -Wl,--end-group /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/crtbeginS.o: unsupported -mbss-plt code /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/crtbeginS.o: unsupported -mbss-plt code /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/crtbeginS.o: unsupported -mbss-plt code /usr/bin/../lib/gcc/powerpc-e500mc-linux-gnu/13.2.0/../../../../powerpc-e500mc-linux-gnu/bin/ld.gold: error: liblxcfs.so.p/src_bindings.c.o: unsupported -mbss-plt code ... I don't really understand what ld.gold is complaining about. My options right now are to not build that package for powerpc 32 or to not have ld.gold available for powerpc 32. Both of those options aren't too terrible but if it were a case of simply passing the right arguments then having ld.gold available would be nicer. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/32016] ld.gold error unsupported -mbss-plt code
https://sourceware.org/bugzilla/show_bug.cgi?id=32016 Chris Packham changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Chris Packham --- Alan Modra explained on the binutils mailing list: Around 2007, the powerpc ABI (and gcc and binutils) gained what I called secure-plt. Prior to that, the powerpc plt section was a bss section that was written with code generated by ld.so. This required a section that was both writable and executable, and therefore somewhat of a target for malicious code. The new secure-plt ABI doesn't use an executable plt, but the code generated to make a call via the plt is a little slower than bss-plt in moderately sized executables and libraries. Your gcc might be configured to generate bss-plt code by default, so to use ld.gold when linking shared libraries or PIEs you'd need to pass -msecure-plt to gcc when compiling. If your project has assembly that makes bss-plt style calls then more work will be needed. -- You are receiving this mail because: You are on the CC list for the bug.
