Initial no-op plumbing for BEAM (Erlang/Elixir) support#958
Conversation
christos68k
left a comment
christos68k
left a comment
There was a problem hiding this comment.
Thanks for doing the work, will do another pass!
GregMefford
force-pushed
the
beam_plumbing
branch
2 times, most recently
from
6d8c00a to
533aa36
Compare
fabled
left a comment
fabled
left a comment
There was a problem hiding this comment.
LGTM mostly. Regex needs fixup and some nits. Also I merged just #749 so this likely needs a rebase. Please also build and include the ebpf tracer binaries (docker run -it --mount "type=bind,src=$PWD,dst=/data" --rm otel/opentelemetry-ebpf-profiler-dev:latest "make amd64 arm64 -C /data/support/ebpf"). Currently the ebpf binaries are needed in Git so that ebpf-profiler can be just included in other projects without manual compilation steps.
GregMefford
force-pushed
the
beam_plumbing
branch
from
ff211a6 to
b9ca60d
Compare
|
I think I got your feedback addressed. Thanks for the handy command to rebuild the ebpf code for both architectures! I didn't realize it was that simple, so I was building it once on my M1 mac in a linux VM and once on a physical x86 linux box, which was pretty tedious. ❤️ |
fabled
left a comment
fabled
left a comment
There was a problem hiding this comment.
LGTM. Just missing the String for interpreter data. But approving at this time. Thanks!
christos68k
left a comment
christos68k
left a comment
There was a problem hiding this comment.
A few more nits, can you also rebase on top of main and fix merge conflicts? Then I can merge.
Co-authored-by: Christos Kalkanis <christos.kalkanis@elastic.co>
GregMefford
force-pushed
the
beam_plumbing
branch
from
89c6dba to
5f7b040
Compare
|
Thanks again for the feedback! I think it should be all squared up now. |
With #958 @GregMefford added the support of Erlang as HLL.
With #958 @GregMefford added the support of Erlang as HLL. Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
4 participants
Now that I've spiked out the proof-of-concept solution in #289, the purpose of this PR is to split out most of the mundane details so that it will hopefully be much easier to review and merge incrementally.
In this PR, I am just setting up the required types, structs, and plumbing to get the agent to identify BEAM processes and attach to them, sending back a single minimal stack frame to demonstrate that it's alive, without really doing anything more.
Here is an example of what those single-depth no-op stack frames look like in devfiler, by comparison to what's in the other PR discussion thread:
I am hoping that this is an acceptable strategy for getting things merged incrementally, or that we can come up with some way to make it safe-enough to merge by disabling something, since this part is pretty routine and about the same as the other interpreters. Then, it'll be much easier to focus on what's needed to get the actual unwinder code working smoothly, without having to deal with merge conflicts and other tedious changes at the same time.
I could potentially trim things down even more (for example, just print a message and return an error when I identify a BEAM process), but I thought this is the minimal path through the entire code, so it's more valuable to confirm that the unwinder code actually is called even if it's not doing anything useful.