Bpftrace: functions with dots are not accepted

Created on 16 Apr 2019  路  10Comments  路  Source: iovisor/bpftrace

There are several kernel functions that include dots in their names. I assume the linker renamed / splitted them, but I'm not 100% sure (OT: if someone could point me to why this happens, I will appreciate it, my search-fu failed me 馃槩)

Aaand bpftrace fails when trying to attach a kprobe to them, but trace.py seems to be happy with them (don't have example of the errors in this machine, sorry! but IIRC it fails in the lexing).

Anyone against adding support for them? One one hand we are listing them bpftrace -l 'kprobe*' | grep '\.' and other tracing tools seem to work ok with them, but on the other hand not sure if this makes sense? 馃槃

priority

Most helpful comment

As part of fixing this, I think I'm going to move the probe definition (eg kprobe:vfs_read) parsing out of the parser and into a custom class or something. It's getting really hairy to unambiguously add new probe types. cc @fbs who I discussed this with a while ago.

Going to start on this in a few days, please let me know before that if you want to NAK it.

All 10 comments

See https://github.com/iovisor/bpftrace/pull/304

That just allowed matching them in wildcards, since that was easy -- the dot is hidden from the lexer behind the "*". As I said there, some more work needed to be done so we can use dots directly in a probe name. Please do a PR if you want to work on this. :-)

TIL about isra symbols! Thanks :)

This also makes golang tracing ugly.

bpftrace -e 'uprobe:/home/bgregg/Lang/go/func:main.add { @++ }'
1.38: syntax error, unexpected ., expecting {

I can workaround it with wildcards ("main*add"), but we should support ".".

It looks like we tried to fix this before, and there's a test for it: https://github.com/iovisor/bpftrace/pull/166

Sounds like it should work with the function name quoted:
uprobe:/home/bgregg/Lang/go/func:"main.add"

Ah, ok, it does. Which is fine as a workaround. But do we ever want to support it without the quotes? The quotes also stop wildcards from working, and things like "main."* don't work either. main* does work, but... The current behavior looks like it'll be a source of issues for newbies, who would likely expect both main.add and main.* to work.

In the long term, is uprobe:/home/bgregg/Lang/go/func:main.add expected to ever work?

I don't think there'd be anything wrong with allowing dots outside of quotes, but the problem is where do we draw the line?
From the linked ticket, this is a valid symbol in Go: main.(*ExampleStruct).PtrRecv.

Hmm. Yeah. Go has a lot of those.

Well, we have to draw a line with *, since that's already the wildcard character. So there has to be a line somewhere. Maybe include dot and nothing more than that?

As part of fixing this, I think I'm going to move the probe definition (eg kprobe:vfs_read) parsing out of the parser and into a custom class or something. It's getting really hairy to unambiguously add new probe types. cc @fbs who I discussed this with a while ago.

Going to start on this in a few days, please let me know before that if you want to NAK it.

1117 is the refactor

Was this page helpful?
0 / 5 - 0 ratings