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.
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