我在 readelf 实用程序的帮助下打开了我的对象 elf 文件： readelf -a ./my_object.o | less 结果我得到了很多有趣的信息。我在节表中看到了带有“GROUP”类型的“.group”节。有人可以解释一下，“.group”部分的任命是什么吗？
我通过静态链接 libc 库在 x86 arch 中为一个简单的程序构建了一个可执行文件。正如预期的那样，该可执行文件的重定位表为空：
$ readelf -r 测试 此文件中没有重定位。 $
当我通过静态链接 libc 库为同一程序构建可执行文件时，在 x86_64 arch 中，重定位表不为空：
$ readelf -r 测试 偏移量 0x1d8 处的重定位节“.rela.plt”包含 12 个条目： 偏移信息类型符号。价值符号。名称 + 加数 0000006c2058 000000000025 R_X86_64_IRELATIV 000000000042de70 0000006c2050 000000000025 R_X86_64_IRELATIV 00000000004829d0 0000006c2048 000000000025 R_X86_64_IRELATIV 000000000042dfe0 0000006c2040 000000000025 R_X86_64_IRELATIV 000000000040a330 0000006c2038 000000000025 R_X86_64_IRELATIV 0000000000432520 0000006c2030 000000000025 R_X86_64_IRELATIV 0000000000409ef0 0000006c2028 000000000025 R_X86_64_IRELATIV 0000000000445ca0 0000006c2020 000000000025 R_X86_64_IRELATIV 0000000000437f40 0000006c2018 000000000025 R_X86_64_IRELATIV 00000000004323b0 0000006c2010 000000000025 R_X86_64_IRELATIV 0000000000430540 0000006c2008 000000000025 R_X86_64_IRELATIV 0000000000430210 0000006c2000 000000000025 R_X86_64_IRELATIV 0000000000432400 $
我在谷歌上搜索了重定位类型“R_X86_64_IRELATIV”，但我可以找到有关它的任何信息。那么有人可以告诉我这是什么意思吗？ …
我无法找到适当的文档来解决我在内核和用户空间中生成一致的 HMAC 的问题。根据Linux Kernel Development中的 Robert Love 的说法，内存描述符mm->start_code和mm->end_code应该包含该.text段。在 ELF 文档中明确定义了在静态可执行文件中查找.text段，并且很容易理解。因此，给出以下两个代码片段，人们期望获得匹配的 HMAC：
核心：
__mm = get_task_mm(__task);
__retcode = ntru_crypto_hmac_init(__crypto_context);
if(__retcode != NTRU_CRYPTO_HMAC_OK)
return 1;
__retcode = ntru_crypto_hmac_update(__crypto_context, (const uint8_t*)__mm->start_code,
__mm->end_code - __mm->start_code);
if(__retcode != NTRU_CRYPTO_HMAC_OK)
return 1;
__retcode = ntru_crypto_hmac_final(__crypto_context, __hmac);
if(__retcode != NTRU_CRYPTO_HMAC_OK)
return 1;
return 0;
用户区：
for (j = 0; j < file_hdr32.e_shnum; j++)
{
if (!strcmp(".text", strIndex + section_hdr32[j]->sh_name))
{
retcode = ntru_crypto_hmac_init(__crypto_context());
if(retcode != NTRU_CRYPTO_HMAC_OK)
{ …[编辑]
这只是我进行的一个实验，我想看看是否可以欺骗内核从无名管道执行精灵，并使用 /lib64/ld-linux-x86-64.so 进行进程替换。 2，我知道这是在黑暗中进行的尝试，但我只是希望看看是否有人能给我一个答案，为什么它不起作用
$ /lib64/ld-linux-x86-64.so.2 <(gcc -c -xc <(echo $'#include <stdio.h>\n\nint main(){\nprintf("I work\\n");\nreturn 0;\n}') -o /dev/stdout)
/tmp/ccf5sMql.s: Assembler messages:
/tmp/ccf5sMql.s: Fatal error: can't write /dev/stdout: Illegal seek
as: BFD version 2.25.1-22.base.el7 assertion fail elf.c:2660
as: BFD version 2.25.1-22.base.el7 assertion fail elf.c:2660
/tmp/ccf5sMql.s: Fatal error: can't close /dev/stdout: Illegal seek
/dev/fd/63: error while loading shared libraries: /dev/fd/63: file too short
我认为由于我得到的结果不同，这可能是可能的。
$ /lib64/ld-linux-x86-64.so.2 <(gcc -fPIC -pie -xc <(echo $'#include
<stdio.h>\n\nint main(){\nprintf("I work\\n");\nreturn 0;\n}') -o
/dev/stdout|cat|perl -ne 'chomp;printf')
/dev/fd/63: error …我使用 crosstool-NG 使用 gcc 6.3.0 和 glibc 2.25 创建了 PowerPC 工具链。我有以下测试程序 test.c：
int main() { return 0; }
我用以下命令编译它：
powerpc-unknown-linux-gnu-gcc -s -Os -o test test.c
最终的二进制文件为 66904 字节，比预期大得多。节标题如下所示：
$ powerpc-unknown-linux-gnu-readelf -S test
There are 27 section headers, starting at offset 0x10120:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 10000154 000154 00000d 00 A 0 0 1
[ 2] .note.ABI-tag NOTE …手册页有这样的内容：
st_info This member specifies the symbol's type and binding
attributes:
STT_NOTYPE The symbol's type is not defined.
STT_OBJECT The symbol is associated with a data object.
STT_FUNC The symbol is associated with a function or other
executable code.
STT_SECTION The symbol is associated with a section. Symbol
table entries of this type exist primarily for
relocation and normally have STB_LOCAL bindings.
STT_FILE By convention, the symbol's name gives the name
of the source file associated with the …以下链接器 (ld) 标志之间有什么区别：
--unresolved-symbols=ignore-in-shared-libs
--allow-shlib-未定义
?
作为跟进，此命名法中未解析的符号和未定义的符号之间有什么区别？
我有一个 ELF 文件，我想从中获取我的代码的hex或文件。bin在终端中，如果 a do a file main，这是我的文件，它会显示：
main: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, not stripped
据我所知，objdump在 macOS 上不起作用，并且otool -l main出现以下错误：
llvm-objdump: 'main': Object is not a Mach-O file type.
ELF 文件是使用以下命令创建的：
riscv-none-gcc/8.2.0-2.1-20190425-1021/bin/riscv-none-embed-gcc --specs=nosys.specs main.c -o main
那么有没有办法做到呢？
多谢
当我尝试执行sudo ./mineonlyret加载 ebpf 程序的用户空间程序时，我在 ubuntu 19.04 上收到此错误消息，稍后对此进行描述。我在 ubuntu 18.04 上尝试了相同的配置，并且没有错误。导致此错误的原因可能是什么？\n如果您需要更多详细信息，请告诉我。
libbpf: Error loading ELF section .BTF: 0.\nmineonlyret_user.c
\n\n// SPDX-License-Identifier: GPL-2.0\n#include <stdio.h>\n#include <assert.h>\n#include <linux/bpf.h>\n#include "libbpf.h"\n#include <unistd.h>\n#include <arpa/inet.h>\n#include <linux/if_ether.h>\n\nint main(int ac, char **argv)\n{\n int sock, prog_fd;\n struct bpf_object *obj;\n char filename[256];\n\n if (bpf_prog_load("mineonlyret_kern.o", BPF_PROG_TYPE_SOCKET_FILTER,\n &obj, &prog_fd))\n return 1;\n\n /* open up a packet socket */\n sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); \n if(sock < 0){\n printf("socket");\n return -1;\n }\n\n /* attach the filter */\n assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, …这是一个非常简单的 C++ 程序：
// main.cpp
int main() {}
我Makefile生成以下命令来编译程序。
? make
g++ -O0 -fverbose-asm -o main main.cpp
我检查命令file以查看它是一个 ELF 可执行文件：
? file main
main: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=921d352e49a0e4262aece7e72418290189520782, for GNU/Linux 3.2.0, not stripped
一切似乎都很好，直到我尝试检查 ELF 标头：
? readelf -e main
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
...
Type: DYN …