R_BPF_64_64.
The BPF object is just a relocatible object, not an executable or
a shared library, so assign ELF type to REL only in bpf_reloc.def.
Tested locally with building pahole with this patch and
pahole is able to display structures in bpf object file properly.
Signed-off-by: Yonghong
R_BPF_64_64.
The BPF object is just a relocatible object, not an executable or
a shared library, so assign ELF type to REL only in bpf_reloc.def.
Signed-off-by: Yonghong Song
---
backends/ChangeLog | 7 +
backends/Makefile.am| 2 +-
backends/bpf_init.c
-backtrace-dwarf.sh
FAIL: vdsosyms
The offending map entry
7f269223d000-7f269226b000 r-xp 00:50 10224326387095067468
/home/...
has an inode number beyond the valid range of type "long".
This patch set fixed the problem in libdwfl and tests respectively.
Yonghong
%*lu", &start, &end, &offset);
Fix the test with inode format string "%*s" then.
Signed-off-by: Yonghong Song
---
tests/backtrace-data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/backtrace-data.c b/tests/backtrace-data.c
index 3a91
offending map entry:
7f269246b000-7f269246c000 rw-p 0002e000 00:50 10224326387095067468 /home/...
This patch changed sscanf inode number type from PRIi64 to PRIu64
and fixed the problem.
Signed-off-by: Yonghong Song
---
libdwfl/linux-proc-maps.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
On 1/29/19 12:50 PM, Mark Wielaard wrote:
> On Fri, Jan 25, 2019 at 01:20:09PM -0800, Yonghong Song wrote:
>> The backtrace-data.c parsed the inode in /proc/pid/maps with
>> format "%*x".
>> This caused failure if inode is big. For example,
>>7f269223
${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
data: no main
-bash-4.4$
The reason is errno is ERANGE.
Fix the test with inode format string "%*u" as inode here is presented
as decimal numbers.
Suggested-by: Mark Wielaard
Signed-off-by: Y
