| Summary: | Can't do anything with void * | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | Tom Zanussi <zanussi> |
| Component: | translator | Assignee: | Frank Ch. Eigler <fche> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | fche |
| Priority: | P1 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Bug Depends on: | |||
| Bug Blocks: | 907 | ||
This bug should be forked into two parts. I'm assigning to Roland for initial assessment of elfutils readiness. The first problem is that void* values should be castable to integers the same way as any other pointers. But it seems like the "& * (pointer)" loc2c hack does ont work for void*. The second problem is that there should be a way to cast pointers to different types. This is especially important to down/upcast pointers, as nested structures are frequently used in the kernel for "subclassing". So the question to elfutils is whether there is a mechanism to recast a pointer type (to another one visible in scope) value during loc2c traversal. (I suppose this could subsume the first problem, by explicit casting to char* from void* in script land.) void * is encoded specially in dwarf and I had not taken account of it before. I think it can be handled with some minor tweaks to the loc2c code. Supporting casts really is a separate feature that should be filed separately. It's doable but we should discuss the details of how you want it to work. (In reply to comment #2) > void * is encoded specially in dwarf and I had not taken account of it before. > I think it can be handled with some minor tweaks to the loc2c code. > Great - I think this is the only really necessary part. > Supporting casts really is a separate feature that should be filed separately. > It's doable but we should discuss the details of how you want it to work. I was thinking mainly of being able to access the data in user-supplied structs e.g. filp->private_data in VFS. Maybe something like ((struct my_device *)$filp->private_data)->member0 but usually these things are first assigned to local variables before use, and therefore could be accessed using systemtap's normal local variable access. I doubt it's worth the trouble at this point. I'm not sure there is any loc2c limitation here. e.g. loc2c-test is happy on a void * variable/field. Reassigning to Frank to plan any related translator work. Commenting out the lines in tapsets.cxx:1128 // if (dwarf_attr_integrate (typedie, DW_AT_type, attr_mem) == N\ULL) // throw semantic_error (....) appears to cause no regressions and make this test case work. Do you why these two lines are there? I will run the testsuite, and remove suspect lines if they cause no regressions. patch committed |
At minimum, you should be able to log the value of a void * as you can with any other pointer, e.g. log(hexstring($dentry->d_inode)) works, but the below doesn't. Seems like you shouldn't have to know the type to just log the address. probe kernel.function("dentry_open") { log(hexstring($dentry->d_fsdata)); } semantic error: cannot get type of pointer: no error: identifier '$dentry' at void-ptr-bugzilla.stp:3:16 semantic error: no match for probe point while: resolving probe point kernel.function("dentry_open") Pass 2: analysis failed. Try again with '-v' (verbose) option. Also, there are times you would like to be able to cast a void * to a known type and access member variables contained within.