-
Notifications
You must be signed in to change notification settings - Fork 514
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
Bugfix parse_cpp_datatype not stripping volatile tag #510
base: main
Are you sure you want to change the base?
Conversation
Makes sense. The test corpus was limited. |
I forgot to also add it to cpp_symbols dict for the PR, but I've now noticed that actually places |
This places the volatile keyword after the variable name - special handling in TypeDesc.__str__ (like it already has for const) may be necessary for complex types.
I'll have to do some language layering here. Is "pointer to volatile" a thing? EDIT: it is. |
@Henri-J-Norden do you have small reproducers that demonstrate this? The ideal would be a simple C file we could compile and observe this on (using pyelftools) |
@eliben Here's code with some (not necessarily reasonable, but certainly compileable) examples, and the elf binary compiled with const int c;
const int* c_p;
int* const p_c;
// const->array->const->int
const int c_2[2];
// array->pointer->const->int
const int* c_p_2[2];
// const->array->const->pointer->int
int* const p_c_2[2];
// const->array->const->pointer->const->int
const int* const c_p_c_2[2];
// volatile->int
volatile int v;
// const->volatile->int
const volatile int cv;
volatile const int vc;
// pointer->const->volatile->int
const volatile int *cv_p;
volatile const int *vc_p;
// volatile->const->pointer->int
int *const volatile p_cv;
int *volatile const p_vc;
// volatile->const->pointer->const->volatile->int
const volatile int *const volatile cv_p_cv;
const volatile int *volatile const cv_p_vc;
volatile const int *const volatile vc_p_cv;
volatile const int *volatile const vc_p_vc;
// volatile->const->pointer->volatile->const->pointer->const->volatile->int
volatile const int *volatile const *volatile const vc_p_vc_p_vc;
// volatile->const->array->const->volatile->int
volatile const int vc_2[2];
// volatile->const->array->volatile->const->pointer->const->volatile->int
volatile const int *const volatile vc_p_cv_2[2];
int main(void)
{
return 0;
} I added a script for debugging the types in https://github.com/Henri-J-Norden/pyelftools/blob/7fd850b21efaf999654e6880d63f8aff1bfa1258/examples/dwarf_var_types.py
And I guess it's also possible to have C++ references in the mix? |
I always felt uneasy about datatype recovery. We needed it because it was the cost of the llvm-dwarfdump autotest, but I suspect that the general case of it is too hairy a problem, and our implementation, whatever it is like, will end up mimicking the quirks of llvm-dwarfdump (which may evolve as the tool evolves). Point is, add your binary to the the dwarfdump autotest directory, run the autotest, and see where it lands. |
I actually only looked at using As for the test, it fails at the first, simplest variable:
|
If the subset of datatype recovery logic that you need is different from what the |
What I think we should do for the viability of the API, we should further decouple datatype discovery from C++ declaration string composition. This way, the former can evolve towards correctness (hopefully) while the latter can evolve towards matching what llvm-dwarfdump provides, and users can supply their own type+name generation logic, if needed. If only there was a corpus of C++ sources aimed at spanning the gamut of datatype options (more generally, language features) out there... For the short term, I'll try and see what can/should be done about |
No description provided.