[PATCH] libelf: Sync elf.h from glibc
Adds new RISC-V relocations. * elf.h: Update from glibc. Signed-off-by: Andreas Schwab --- libelf/elf.h | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/libelf/elf.h b/libelf/elf.h index 4bc0e429..89fc8021 100644 --- a/libelf/elf.h +++ b/libelf/elf.h @@ -210,7 +210,7 @@ typedef struct #define EM_68HC12 53 /* Motorola M68HC12 */ #define EM_MMA 54 /* Fujitsu MMA Multimedia Accelerator */ #define EM_PCP 55 /* Siemens PCP */ -#define EM_NCPU56 /* Sony nCPU embeeded RISC */ +#define EM_NCPU56 /* Sony nCPU embedded RISC */ #define EM_NDR157 /* Denso NDR1 microprocessor */ #define EM_STARCORE58 /* Motorola Start*Core processor */ #define EM_ME1659 /* Toyota ME16 processor */ @@ -559,7 +559,7 @@ typedef struct /* Possible bitmasks for si_flags. */ #define SYMINFO_FLG_DIRECT 0x0001 /* Direct bound symbol */ -#define SYMINFO_FLG_PASSTHRU 0x0002 /* Pass-thru symbol for translator */ +#define SYMINFO_FLG_PASSTHRU 0x0002 /* Pass-through symbol for translator */ #define SYMINFO_FLG_COPY 0x0004 /* Symbol is a copy-reloc */ #define SYMINFO_FLG_LAZYLOAD 0x0008 /* Symbol bound to object to be lazy loaded */ @@ -728,6 +728,7 @@ typedef struct #define PT_GNU_STACK 0x6474e551 /* Indicates stack executability */ #define PT_GNU_RELRO 0x6474e552 /* Read-only after relocation */ #define PT_GNU_PROPERTY0x6474e553 /* GNU property */ +#define PT_GNU_SFRAME 0x6474e554 /* SFrame segment. */ #define PT_LOSUNW 0x6ffa #define PT_SUNWBSS 0x6ffa /* Sun Specific segment */ #define PT_SUNWSTACK 0x6ffb /* Stack segment */ @@ -1223,6 +1224,9 @@ typedef struct #define AT_HWCAP2 26 /* More machine-dependent hints about processor capabilities. */ +#define AT_RSEQ_FEATURE_SIZE 27 /* rseq supported feature size. */ +#define AT_RSEQ_ALIGN 28 /* rseq allocation alignment. */ + #define AT_EXECFN 31 /* Filename of executable. */ /* Pointer to the global system page used for system calls and other @@ -3998,8 +4002,11 @@ enum #define R_RISCV_SET32 56 #define R_RISCV_32_PCREL 57 #define R_RISCV_IRELATIVE 58 +#define R_RISCV_PLT32 59 +#define R_RISCV_SET_ULEB12860 +#define R_RISCV_SUB_ULEB12861 -#define R_RISCV_NUM59 +#define R_RISCV_NUM62 /* RISC-V specific values for the st_other field. */ #define STO_RISCV_VARIANT_CC 0x80/* Function uses variant calling -- 2.41.0 -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] backends: Update list of RISC-V relocations
* backends/riscv_reloc.def: Add IRELATIVE, PLT32, SET_ULEB128, SUB_ULEB128. Signed-off-by: Andreas Schwab --- backends/riscv_reloc.def | 4 1 file changed, 4 insertions(+) diff --git a/backends/riscv_reloc.def b/backends/riscv_reloc.def index 2bd3513e..f52f6489 100644 --- a/backends/riscv_reloc.def +++ b/backends/riscv_reloc.def @@ -81,3 +81,7 @@ RELOC_TYPE (SET8, REL) RELOC_TYPE (SET16, REL) RELOC_TYPE (SET32, REL) RELOC_TYPE (32_PCREL, REL) +RELOC_TYPE (IRELATIVE, EXEC|DYN) +RELOC_TYPE (PLT32, REL) +RELOC_TYPE (SET_ULEB128, REL) +RELOC_TYPE (SUB_ULEB128, REL) -- 2.41.0 -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[Bug debuginfod/30589] New: debuginfod can't find sources even though they exist on disk
https://sourceware.org/bugzilla/show_bug.cgi?id=30589
Bug ID: 30589
Summary: debuginfod can't find sources even though they exist
on disk
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: debuginfod
Assignee: unassigned at sourceware dot org
Reporter: russell at shotover dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
I'm trying to create a debuginfod server for our internal codebase, and would
like it to be able to serve correct sources, even for arbitrary old versions of
our software. We package as .deb, but the docs are pretty clear that that
doesn't support serving sources. So, I'm passing -ffile-prefix-map to where I
will eventually copy the sources, but debuginfod doesn't seem to want anything
to do with it:
```
echo 'int main() {}' > test.c
gcc -g -O0 test.c -Wl,--build-id=0xaabbccdd
-ffile-prefix-map=`pwd`=`pwd`/servefrom
mkdir servefrom
mv test.c a.out servefrom
rm ~/.debuginfod.sqlite
DEBUGINFOD_URLS="" debuginfod -F . -vvv
...
rm -rf ~/.cache/debuginfod_client
DEBUGINFOD_URLS="http://localhost:8002"; debuginfod-find source
aabbccdd `pwd`/test.c
```
fails. Fetching the executable or debuginfo succeeds.
The debuginfod log shows:
```
[Tue 27 Jun 2023 12:13:24 AM GMT] (496432/496443): 127.0.0.1:49688
UA:elfutils/0.189,Linux/x86_64,arch/ XFF: GET
/buildid/aabbccdd/source/tmp/asdf/servefrom/test.c
404 9 0+0ms
```
However, the same thing without the map works:
```
echo 'int main() {}' > test.c
gcc -g -O0 test.c -Wl,--build-id=0xaabbccdd
rm ~/.debuginfod.sqlite
DEBUGINFOD_URLS="" debuginfod -F . -vvv
...
rm -rf ~/.cache/debuginfod_client
DEBUGINFOD_URLS="http://localhost:8002"; debuginfod-find source
aabbccdd `pwd`/test.c
```
I must have some incorrect assumption about how -F mode finds source
filesit seems like what I'm doing should be supported
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk
https://sourceware.org/bugzilla/show_bug.cgi?id=30589 --- Comment #1 from Russell Greene --- er, the correct command for the non-working case should be DEBUGINFOD_URLS="http://localhost:8002"; debuginfod-find source aabbccdd `pwd`/servefrom/test.c -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk
https://sourceware.org/bugzilla/show_bug.cgi?id=30589 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com Last reconfirmed||2023-06-27 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from Frank Ch. Eigler --- In my tests here on f38, the gcc -ffile-prefix-map option resulted in highly sus dwarf: % gcc -g -O0 test.c -Wl,--build-id=0xaabbccdd -ffile-prefix-map=`pwd`=`pwd`/servefrom % eu-readelf -w a.out Directory table: [path(line_strp)] 0 /home/fche/[...]/servefrom/servefrom (61) i.e., the suffix was added twice. On another test, where the map target was to a non-subdirectory like /tmp/foo, gcc produced correct looking dwarf, and debuginfod took it like a champ. gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk
https://sourceware.org/bugzilla/show_bug.cgi?id=30589 --- Comment #3 from Russell Greene --- Yeah, that looks like an issue for sure. Clang seems to omit more sane dwarf: Directory table: [path(line_strp)] 0 /home/russell/debuginfod_test/servefrom (0) But debuginfod still doesn't seem to like it. Interestingly, the actual deployment didn't use a subpath, so I need to see what's exactly going wrong with it--this issue here may actually be unrelated to what I'm running into. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/30589] debuginfod can't find sources even though they exist on disk
https://sourceware.org/bugzilla/show_bug.cgi?id=30589
--- Comment #4 from Russell Greene ---
% mkdir servefrom
% echo 'int main(){}' > test.c
% gcc -g test.c -ffile-prefix-map=`pwd`=`pwd`/servefrom -o test_gcc
% clang -g test.c -ffile-prefix-map=`pwd`=`pwd`/servefrom -o test_clang
% mv test.c servefrom
% gdb test_gcc -ex 'break main' -ex run -ex quit od
1 int main() {}
% gdb test_clang -ex 'break main' -ex run -ex quit od
1 int main() {}
% lldb test_gcc -o 'b main' -o 'run' -o 'quit'
( no source)
% lldb test_clang -o 'b main' -o 'run' -o 'quit'
-> 1int main(){}
LLDB is not thrilled with whatever gcc is emitting here either. Maybe a GCC
bug? Think they would want this reported?
Regardless, this bug is pretty minor as mapping to a subdirectory seems to me a
pretty rare thing. I'll open a different bug report if I'm able to track the
bug I'm running into on (if it's not just a misconfiguration).
--
You are receiving this mail because:
You are on the CC list for the bug.
