Request: Allow opening executables without loading symbols

[avivzgroundcover]

Hey everyone!
I have a request for a use case which might seem weird at start. I would like for link.OpenExecutable to have an optional flag or configuration which skips the symbol loading phase.
This might seem weird, but it's already accepted by the community that certain situations require the users to know the symbols by themselves. This is why the library already supports passing arbitrary address+offset pairs when placing uprobes.

A real life example of this is problem is probing golang processes - since golang has known issues with uretprobes, the current popular replacement to a uretprobe is manually finding the return addresses of the probed function and applying uprobes to every single return instruction.
This method works perfectly with the address+offset methods, but makes the loading of symbols uneeded to begin with.

The reason this is even an issue is that symbol tables tend to be large, especially when analyzing golang processes; skipping the loading could dramatically increase memory efficiency for some programs, especially when probing many processes.

Thank you and let me know what you think!

[lmb]

cc @mmat11. Maybe we could make loading the symbol table lazy by default? If possible I'd like to avoid adding extra API.

[florianl]

Besides lazy loading of symbols from executables, Executable also does not have a proper way at the moment to attach an eBPF program using address+offset pairs.
UprobeOptions provides an option to define address and offset, which overwrites symbol as input to Executable.Uprobe(..) or Executable.Uretprobe.
So I think Executable should be extended to explicitly support attaching an eBPF program using only address and offset.

[mmat11]

So I think Executable should be extended to explicitly support attaching an eBPF program using only address and offset.

@florianl are you still refering to kprobe-type programs? could you make an example of how the new API would look like?

[lmb]

This method works perfectly with the address+offset methods, but makes the loading of symbols uneeded to begin with.

I should've asked earlier: you don't need to load symbols because you already parse them yourself, or is there another way to get the addresses?

[florianl]

[..] you don't need to load symbols because you already parse them yourself [..]

I can only speak for the use cases I know. Using symbols to attach something is the most easy and straight forward one. But there are use cases where symbols are not available or there are known issues, like iovisor/bcc#1320. Anyway - getting the correct address + offset combination can also be provided by external tools like disassemblers.

could you make an example of how the new API would look like?

At the moment Executable.Uprobe(..) or Executable.Uretprobe(..) require symbol as argument. Some API functionallity without symbol as input argument would be great. Maybe something like:

// DirectUprobe attaches the given eBPF program to a perf event that fires when the given address + offset combination starts executing in the given Executable.
func (ex *Executable) DirectUprobe(prog *ebpf.Program, opts *UprobeOptions) (Link, error) {..}

Naming, like DirectUprobe, is of course subject of change.

[brycekahle]

Another example would be a Go binary with symbols stripped, but still has the Go symbol and line number tables.

[avivzgroundcover]

@lmb Indeed, in my case I'm using an external disassembler to find the required addresses.

[lmb]

@florianl can you create an issue to track not requiring symbol?