[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 --- Comment #9 from Michael Brown --- (In reply to Ed Maste from comment #8) Thanks for taking a look. The multiple sections all with virtual memory addresses of zero are correct: there are genuinely multiple disjoint address spaces at runtime. For example: the real-mode code segment (.text16) and real-mode data segment (.data16) may be placed arbitrarily in base memory once loaded, and virtual addresses within those segments are just 16-bit offsets from the start of each segment, dereferenced against %cs or %ds as applicable. The load memory addresses (LMA) that we create within the ELF file represent the offsets at which we expect each section to appear in the file generated by "objcopy -O binary". Looking at the output of "objdump -h bin/ipxe.dsk.tmp" I see e.g.: objdump -h bin/ipxe.dsk.tmp bin/ipxe.dsk.tmp: file format elf32-i386-freebsd Sections: Idx Name Size VMA LMA File off Algn 0 .prefix 090d 0154 2**0 CONTENTS, ALLOC, LOAD, CODE ... 7 .textdata 000ce040 1370 14c0 2**5 CONTENTS, ALLOC, LOAD, CODE which correctly shows that we have (at least) two sections with a VMA of , but that .prefix should appear at offset and .textdata at offset 1370 within the "-O binary" output file based on the LMA of each section. The binutils objcopy does behave this way: it will use the load memory addresses as the file offsets for "-O binary" (with the first byte in the output file corresponding to the lowest load memory address present in the output). The binutils objcopy behaviour seems correct to me: since "-O binary" is intended to create a raw binary image then the LMA (rather than the VMA) is the relevant value for the offset within this binary image. Could the elftoolchain objcopy be made to match this behaviour? Thanks, Michael -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 --- Comment #8 from Ed Maste --- It appears that each section is copied to the output binary at an offset specified by the section's Addr, in an some (unspecified) order - i.e., both .textdata and .zinfo specify an address of 0, and the output is .textdata overlaid with .zinfo. [ 6] .textdata PROGBITS 001830 0c9ec8 00 WAX 0 0 4 [ 8] .zinfoPROGBITS 0cb6f8 80 00 A 0 0 1 $ readelf -x .zinfo ipxe.pxe.tmp | less Hex dump of section '.zinfo': 0x 434f5059 b10c 1000 COPY ... 0x0070 4157 db03 1000 ADDW $ readelf -x .textdata ipxe.pxe.tmp Hex dump of section '.textdata': 0x 8b542404 8b042489 02896204 .T$...$...b. ... 0x0070 6883 0089c1ba 3f00 e8cac002 h...?... 0x0080 00c9c353 89c389d0 0fb75260 895314c6 ...S..R`.S.. 0x0090 431800ba 0100 e8adab01 00b9fff0 C... ... 0x000c9ec0 d5570300 dd520300 .W...R.. $ hexdump -Cv output 43 4f 50 59 00 00 00 00 b1 0c 00 00 10 00 00 00 |COPY| ... 0070 41 44 44 57 db 03 00 00 10 00 00 00 00 00 00 00 |ADDW| 0080 00 c9 c3 53 89 c3 89 d0 0f b7 52 60 89 53 14 c6 |...S..R`.S..| ... 000c9ec0 d5 57 03 00 dd 52 03 00 |.W...R..| 000c9ec8 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 Michael Brown changed: What|Removed |Added CC||mc...@ipxe.org --- Comment #7 from Michael Brown --- I have updated the iPXE build process to place the (meaningless) load addresses for the various NOLOAD sections earlier than the .zinfo section. This change is in commit https://github.com/ipxe/ipxe/commit/fe52f8e8b and eliminates the harmless "moving loadable section" warning. However, there seems to be something else very broken in the elftoolchain implementation of "objcopy -O binary". Extracting a single section using e.g. objcopy -O binary -j .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.zinfo works as expected. Extracting multiple sections using e.g. objcopy -O binary -R .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.bin or even just objcopy -O binary bin/ipxe.pxe.tmp wtf produces a binary file with no discernible relation to the input. It looks vaguely as though objcopy is ignoring the load addresses and just placing the sections semi-randomly within the output file. For now, I've modified the iPXE build process to check for the elftoolchain version of objcopy and refuse to use it (https://github.com/ipxe/ipxe/commit/1fea8ce06). It would be good to get a proper fix for this, if anyone has time to dig into how the elftoolchain objcopy is handling "-O binary". Michael -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 238607] devel/folly: clang 8 crashes during build
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238607 Dimitry Andric changed: What|Removed |Added Status|Open|Closed Resolution|--- |Overcome By Events --- Comment #5 from Dimitry Andric --- 12.1-RELEASE expires 2021-01-31. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 251886] clang: error: clang frontend command failed due to signal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251886 --- Comment #16 from igor.polov...@gmail.com --- New strange behaviour with LDFLAGS.lld+= -Wl,--no-threads in make.conf. clang++ -O2 -pipe -fno-common -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/contrib/llvm-project/llvm/lib/Target/AArch64 -I/usr/src/contrib/llvm-project/llvm/lib/Target/ARM -I/usr/src/contrib/llvm-project/llvm/lib/Target/$ Stack dump: 0. Program arguments: clang++ -O2 -pipe -fno-common -I/usr/obj/usr/src/amd64.amd64/lib/clang/libllvm -I/usr/src/contrib/llvm-project/llvm/lib/Target/AArch64 -I/usr/src/contrib/llvm-project/llvm/lib/Target/ARM -I/usr/src/contrib/llv$ 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module '/usr/src/contrib/llvm-project/llvm/lib/Transforms/IPO/Attributor.cpp'. #0 0x038320be PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x03830335 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18 #2 0x03834341 HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:77:5 #3 0x03834341 CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:382:51 #4 0x0470a100 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 clang++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2) Target: x86_64-unknown-freebsd12.2 Thread model: posix InstalledDir: /usr/bin clang++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. clang++: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang++: note: diagnostic msg: /tmp/Attributor-1e1087.cpp clang++: note: diagnostic msg: /tmp/Attributor-1e1087.sh clang++: note: diagnostic msg: *** Error code 254 Stop. make[6]: stopped in /usr/src/lib/clang/libllvm *** Error code 1 *** Error code 1 *** Error code 1 *** Error code 1 *** Error code 1 *** Error code 1 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
