Changeset View
Standalone View
sys/tools/amd64_vdso.sh
- This file was added.
#!/bin/sh | |||||
set -e | |||||
jrtc27: I feel like these should probably just be normal makefile rules; is there a reason they're not? | |||||
Done Inline ActionsThis is how I (tried to) do it initially. It appeared to be too painful to use for dev/debugging purposes. With the script, I can do rebuild after tweaking linker options manually within less than 1 sec, while with files.XXX and custom target I need to reconfigure/depend/buildkernel often with removal of the build directory. [Almost 60% of the time spent on this patch was with making linkers do what I wanted, both lld and ld.bfd] kib: This is how I (tried to) do it initially. It appeared to be too painful to use for… | |||||
${CC} -x assembler-with-cpp -DLOCORE -fPIC -nostdinc -c \ | |||||
-o sigtramp.pico -I. -I${S} -include opt_global.h \ | |||||
${S}/amd64/amd64/sigtramp.S | |||||
# We need to make vdso as compact as possible, for it to leave space | |||||
# for other things in the shared page. For this, we pack everything | |||||
# into single loadable segment. | |||||
# | |||||
# -z rodynamic is undocumented lld-specific option, seemingly required | |||||
# for lld to avoid putting dynamic into dedicated writeable segment, | |||||
# despite ldscript placement. It is ignored by ld.bfd but ldscript | |||||
# alone is enough there. | |||||
${LD} --shared -Bsymbolic -soname="elf-vdso.so.1" \ | |||||
-T ${S}/conf/vdso_amd64.ldscript \ | |||||
--eh-frame-hdr --no-undefined -z rodynamic -z norelro -nmagic \ | |||||
--hash-style=sysv --fatal-warnings --strip-all \ | |||||
-o elf-vdso.so.1 sigtramp.pico | |||||
${OBJCOPY} --input-target binary \ | |||||
--output-target elf64-x86-64 --binary-architecture i386:x86-64 \ | |||||
Done Inline ActionsUse a template asm file rather than the slightly hacky objcopy approach? (I guess a sys/kern/vdso.S a la sys/kern/firmw.S) jrtc27: Use a template asm file rather than the slightly hacky objcopy approach? (I guess a… | |||||
Done Inline ActionsWhat's wrong with objcopy? acpi trampoline uses the same way to generate .o from binary. Hm, the one thing that is better with firmw.S is that it all goes to .rodata instead of .data. I will consider it later, this is a little tweak in big picture. kib: What's wrong with objcopy? acpi trampoline uses the same way to generate .o from binary.
Hm… | |||||
Done Inline ActionsAs for why objcopy isn't the best: for architectures that have more than one ABI, e_flags stores the ABI and needs to match what it's linked with. objcopy doesn't have a way to pass a precise -mabi, so you just get a bunch of zeroes which is often, but not always, what the kernel wants. It's not a problem for amd64, but we've been purging all uses of objcopy for this purpose in MI places as all our pure-capability CHERI kernels have an ABI that's not encoded as 0 downstream, so if this is ever going to hit arm64 or riscv then it will become a problem. And yes, as you say, template asm files give you full control over exactly what you export and how, whereas objcopy just gives you whatever binutils maintainers decided 20+ years ago might make sense and hard-coded into the tool that LLVM and elftoolchain had to copy. jrtc27: As for why objcopy isn't the best: for architectures that have more than one ABI, e_flags… | |||||
Done Inline Actionsstat isn't a bootstrap tool, and on Linux it's stat -c %s, so this will break the cross-build support. I think wc -c is the only portable way to do this? jrtc27: stat isn't a bootstrap tool, and on Linux it's stat -c %s, so this will break the cross-build… | |||||
elf-vdso.so.1 elf-vdso.so.o | |||||
${NM} -D elf-vdso.so.1 | \ | |||||
awk '/__vdso_sigcode/{printf "#define VDSO_SIGCODE_OFFSET 0x%s\n",$1}' \ | |||||
>vdso_offsets.h | |||||
Done Inline Actionswc -c < elf-vdso.so.1 won't print the file name, if you care about having to have the awk jrtc27: wc -c < elf-vdso.so.1 won't print the file name, if you care about having to have the awk | |||||
Done Inline ActionsI prefer awk kib: I prefer awk |
I feel like these should probably just be normal makefile rules; is there a reason they're not?