-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Full tracepoint support in Clang front-end #602
Conversation
@4ast @drzaeus77: A bunch of tests are failing on the build bots with the following error:
I know I introduced regexes in this PR, but ... it works on my machine. All tests are passing. This could be due to the libstdc++ version, or I'm not sure what else. Is there any way to debug what's happening on the build bots? Get a complete stack trace of the exception? Edited to add: It looks like some older versions of gcc might have had incomplete support for |
Actually, fedora buildbot got a different error. Here is the backtrace of the ubuntu one:
|
@drzaeus77 Thanks for the stack trace, it looks like this libstdc++ version thinks the regex is invalid. I haven't seen something like this before, would appreciate any suggestions. |
The update I just pushed should fix the issue on the Fedora bot, I accidentally removed the |
@drzaeus77: it would be great to see what the error type was in frame 6. |
Tested, works, thanks! I'll update the examples/tracing/urandomread.py to be this: #!/usr/bin/python
#[...]
from __future__ import print_function
from bcc import BPF
# load BPF program
b = BPF(text="""
TRACEPOINT_PROBE(random, urandom_read) {
bpf_trace_printk("%d\\n", args->got_bits);
return 0;
};
""")
# header
print("%-18s %-16s %-6s %s" % ("TIME(s)", "COMM", "PID", "GOTBITS"))
# format output
while 1:
try:
(task, pid, cpu, flags, ts, msg) = b.trace_fields()
except ValueError:
continue
print("%-18.9f %-16s %-6d %s" % (ts, task, pid, msg)) Pretty nice! I'm wondering if I should keep the old version of urandomread.py somewhere, since it still works, and demonstrates a different method that might be useful in some unforeseen case. |
Tried, wasn't able to get it. However, I did reproduce with the following minimal program: // g++ x.cc -std=c++11; ./a.out
#include <regex>
using namespace std;
int main(int argc, char **argv) {
regex type_regex("(?:struct|class)\\s+tracepoint__(\\S+)__(\\S+)");
return 0;
} Test machine was laptop with Ubuntu 14.04. Nothing else special. Taking a different tact, though, might be to avoid regex altogether. If I read the code right, you are using regex to determine when a type is a tracepoint arg. I have a similar problem with the packet parsing rewrites that I get when using structs from proto.h. In there, I define a struct with the trailer BPF_PACKET_HEADER. This adds a meaningless (to the syntax) attribute to the type, which I then search for in the frontend action. I can do this in an exact way, since the type is reachable from the variable declaration. That then triggers the rewrite logic. Have you noticed this infra, and considered it as an alternative? |
@drzaeus77: The thing is that I am using regexes to actually extract data from these strings. If I simply wanted a marker, I guess the
I guess there isn't much choice though, and the older Ubuntu libstdc++ doesn't support |
When a function in the BPF program starts with "tracepoint__", parse the rest of the name as a tracepoint category and name and attach the tracepoint automatically. For example: ``` int tracepoint__sched__sched_switch(...) ``` As a result, the sched:sched_switch tracepoint is enabled and the function is attached to that tracepoint.
When a probe function refers to a tracepoint arguments structure, such as `struct tracepoint__irq__irq_handler_entry`, add that structure on-the-fly using a Clang frontend action that runs before any other steps take place. Typically, the user will create tracepoint probe functions using the TRACEPOINT_PROBE macro, which avoids the need for specifying the tracepoint category and event twice in the signature of the probe function.
@drzaeus77: The latest commit moves from the
Is it related to my PR at all? |
@drzaeus77: I'd really appreciate if you could take a look, I'm really not sure what's failing the build here. |
ACK, will look at in a bit, still in weekend mode :)
|
I guess it was just an intermittent issue. |
if (D->isExternallyVisible() && D->hasBody()) { | ||
// If this function has a tracepoint structure as an argument, | ||
// add that structure declaration based on the structure name. | ||
for (auto arg : D->params()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to have the same problem as was fixed in #600. Can you modify accordingly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drzaeus77: Done. Thanks.
Older versions of GCC don't support std::regex even though they support most of C++11. To avoid breaking the build on older systems, such as Ubuntu 14.04, use manual parsing instead of std::regex.
lgtm |
This should close #587 by providing full support for tracepoints in the Clang front-end. Namely, probe functions for tracepoints can now be defined using the
TRACEPOINT_PROBE
macro. For example: