Hi,

Great to see the missing debug tool for ebpf has finally come~

However, I can't install edb successfully, the error messages are listed below:

> go install github.com/dylandreimerink/[email protected]
go install: github.com/dylandreimerink/[email protected] (in github.com/dylandreimerink/[email protected]):
The go.mod file for the module providing named packages contains one or
more replace directives. It must not contain directives that would cause
it to be interpreted differently than if it were the main module.

Could u pls take a look?

BTW, I just built the code manually and got the right binary.

./edb graph ./hello-debug.o hello -o aa.txt
Error: load collection: file ./hello-debug.o: section "tracepoint/syscalls/sys_enter_execve": string is not stack allocated: not supported
Usage:
  edb graph {ELF} {program name} [flags]

Flags:
  -f, --format string   The output format: dot, svg, pdf or png (default "svg")
  -h, --help            help for graph
  -o, --output string   output to given file path or - for stdout, instread of opening in browser

load collection: file ./hello-debug.o: section "tracepoint/syscalls/sys_enter_execve": string is not stack allocated: not supported

bpf code:

cat ../hello_bpf/hello.c
#include <linux/bpf.h>
#define SEC(NAME) __attribute__((section(NAME), used))

static int (*bpf_trace_printk)(const char *fmt, int fmt_size,
                               ...) = (void *)BPF_FUNC_trace_printk;

SEC("tracepoint/syscalls/sys_enter_execve")
int bpf_prog(void *ctx) {
  const char *msg = "Hello, BPF World!";
  bpf_trace_printk(msg, sizeof(msg));
  return 0;
}

char _license[] SEC("license") = "GPL";

Any idea? Error for bpf_trace_printk？

One handy feature other debuggers have is the ability to list and inspect variables of the current scope. This feature can be implemented in the following steps:

1. Index DW_TAG_subprogram and DW_TAG_inlined_subroutine DWARF tags in reverse index so we can find the most specific function scope from at any given instruction(should we include other scopes like loops? Do those have seperate DWARF tags). (Only one at load time)
2. Find the most specific scope for the current PC(Program counter) and get all DW_TAG_variable and DW_TAG_formal_parameter tags.
3. variables or parameters without DW_AT_location attribute should be displayed but marked as inlined
4. variables with the DW_AT_location class of loclistptr should pick a valid location expression from the referenced location-list. If non are valid of the current PC, we should still show the var/param but mark is as unavailable.
5. If a valid location expression can be found, execute it using a stack machine and current memory/registers, get the pointer to the data.
6. Copy the data from the register/memory as byte slice
7. Use BTF to lookup the size of the param/variable type, which can be gotten from the DW_AT_type attribute of the tag.
8. Use the BTF type plus the byte slice and attempt to 'inflate' the bytes into a C literal definition to show the user.

DWARF spec for reference: https://dwarfstd.org/doc/DWARF4.pdf

In the course of developing EDB so far I have encounters a number of bugs, these are often only reproducible after following a very specific set of steps and a specific ELF file. It would be very hard for users to communicate a clear list of steps to reproduce the issue, therefor I want to add a "crash dump" system which will record all information that might be necessary to reproduce bugs.

The primary use case for such dumps would be to present them to the user when we recover from a panic with the request to upload them or send them privately. Additionally, calling the dump command should output the path to the dump file/folder to the user so they can send dumps of subtle bugs.

With this addition, I would also like to add a logging framework like you would use on a server application, its output would be part of the crash dump so we can add debug messages and data which can be used to see if we hit certain code paths.

These dumps should include the following elements:

• A history of all commands (together with the output in ASCIIcast format?)
• The output created by EDB
• The contents of ELF and CTX files loaded
• Source code referenced by the ELF file
• The contents of the debug log
• The version/commit information of the EDB version
• Any error message / panic
• ? Core dump (dump the processes memory so we can inspect it with delve)

This would have some serious implications since we will be capturing potentially sensitive information, which in itself isn't an issue, but we have to communicate this very clearly before asking people for the dumps. We should clearly outline what is in them (for example by including a readme in the dump dir) so it is an informed decision to send source code publicly or privately.

Currently, list shows us the source code at the current location. This issues proposes to extend its functionality by adding some optional parameters. It would, for example be handy to pick how many lines above and below the current line you want to see, so specifying a count like list 40 would show 20 lines above and 20 lines below the current point instead of the default.

The second idea is to allow users to specify a start and end line number within the current or another file like: list 100-120 for the current file and list somefile.h:100-120 to specify some specific file.

Thirdly, it would be handy to be able to list a function, for example by saying list @func123, or a function within a specific file like list [email protected]. Perhaps this can extends to symbols in general.

Since #13 and 484f163 we have the tools to determine in which function/scope we are and where we came from. The locals command uses the current scope to look for variables, but there is no reason why we can't also inspect variables in functions to which we have yet to return. To would be nice if we could for example do locals -1 and it will show the locals of our parents scope.

Another idea would be to assign indexes to each scope starting from 0 which is our main program and then increasing, this would require you to first execute callstack/cs to get a index.

Yet another approach might be to be able to "switch" scope. We wouldn't be able to continue execution without going back to the actual scope of the current instruction, but it could be some temporary state to browse around the callstack to inspect the locals for example.

The step command we currently have always steps into functions, this is fine if we want to follow execution in detail, but it is very frustrating at times to have to step through every sub-function call there is. So it would be a nice feature to have a step-over command which will step to the next line within the same scope. A very similar, yet good command to have would be the step-out which will go the the first line outside of the current scope, which can be used to correct if you used step instead of step-over, or if you just want to leave the current function.

This issue proposes to add commands with which the contents of registers and memory can be updated. The purpose of this feature is to explore conditions which normally don't occur or are difficult to recreate while in a debugging session. For example if you want to explore an error case, you can break just before evaluating something and change the value of R1 to trigger an artificial error.

The MVP version of the feature is to have it just work on registers, but being able to change local/global variables would be nice, completely or specific struct members. Additionally to also modify memory we don't have variables for like changing bytes as specific memory locations to change a packet for example.

This issue proposes to add log points, which are a type of "breakpoint" that, instead of actually breaking the program will log a message and/or expression to some log buffer along with the location of the point. It is the fancy version of print statements in code, but in some situations it helps to be able to just see the order of logs instead of having to keep track of 30 times you were stopped by a breakpoint.

These log points should come in the conditional and non-conditional variants.