Allow uprobe placement on arbitrary addresses when --unsafe is used.

[mzr]

Follow-up to #1282.
When there is no symbol found for requested address of uprobe placement and --unsafe is set, warning is emitted, and uprobe is placed as normally.

Checklist

• Language changes are updated in docs/reference_guide.md
• User-visible and non-trivial changes updated in CHANGELOG.md

[fbs]

nice, thanks for working on this!

Unsafe uprobe:bin:4377 not matching any symbol at address 0x1119

I think the message can be improved a bit. Matching a symbol isn't a requirement for bpftrace. All it wants to know is that it is not inserting a probe in the middle of an instruction and then crashing the tracee. Maybe something along the lines of WARNING: could not determine instruction boundary (binary appears stripped), misaligned probes can lead to tracee crashes

[mzr]

I don't think that's the correct warning either. At least it doesn't fit into the control flow in the source code. Originally it failed because there was no symbol defined at that address (if (!sym.start)).
Also as far as I understand, alignment within an instruction is checked later by calling the check_alignment.

How about

WARNING: Unsafe uprobe:bin:4377 not matching any symbol at address 0x1119. Skipping all alignment checks such as instruction boundary. Misaligned probes can lead to tracee crashes.

?

[fbs]

I don't think that's the correct warning either. At least it doesn't fit into the control flow in the source code. Originally it failed because there was no symbol defined at that address (if (!sym.start)).

Having a sym.start doesn't mean that there exists a symbol at that specific address. What it does, through the sym_address_cb, is finding a "function" that contains that address (func_start <= address <= func_end). That way it can use func_start as a starting point for checking instruction boundaries as func_start will always be aligned properly.

!sym.start can mean that the file is (partly) stripped from the required symbols or that the address is actually outside of function boundaries the current code doesn't really know which it is.

Maybe we could add some checks that at least verify that the address is not completely out of bounds, but that can be done in a later pr too.

[fbs]

Can you squash the commits into one? :)

[fbs]

@danobi what do you think of the warning message?

[danobi]

Seems reasonable to me. But I think documentation needs updating

[danobi]

Thanks!