-
Couldn't load subscription status.
- Fork 99
Remove typedef in generated 'debug_defines.h' #1122
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
base: main
Are you sure you want to change the base?
Conversation
The pull request riscv#858 introduces four typedef in debug_defines.h that are not welcome by the coding style of project aimed at using these generated files, e.g. by OpenOCD coding style. Since all the typedef are for C struct, simply define the struct with their name and, for temporarily backward compatibility, keep defining the typedef but mark then as deprecated in a comment. Drop the suffix '_t' used by the new types. Only for 'riscv_debug_reg_field_list_t', that had same name for struct and typedef, add a #define to handle both use cases. Signed-off-by: Antonio Borneo <[email protected]>
Drop the use of types defined with typedef and use the names of the struct. Signed-off-by: Antonio Borneo <[email protected]>
The local function riscv_debug_reg_field_to_s() has a parameter not used and this causes the compiler to issue a warning. Drop the unused parameter. Signed-off-by: Antonio Borneo <[email protected]>
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.
@borneoa, thank you for the change!
One more question: should this stileguide be documented somewhere?
| "\tstruct riscv_debug_reg_field_list (*get_next)(struct riscv_debug_reg_ctx context);\n" + | ||
| "};\n" + | ||
| "/* deprecated, prefer 'struct riscv_debug_reg_field_list' to 'struct riscv_debug_reg_field_list_t' */\n" + | ||
| "#define riscv_debug_reg_field_list_t riscv_debug_reg_field_list\n" + |
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.
I believe it's okay to break this interface from version to version since it's not the part of the spec itself.
@rtwfroody, @pdonahue-ventana, could you please share your opinion?
|
@pdonahue-ventana, this change does not affect the specification, so perhaps it can be merged? What is the appropriate process for such changes? |
|
@ved-rivos: What's the process for handling this PR which affects only autogenerated .h files but not the spec itself? Does anyone besides OpenOCD rely on these files? I wonder if this script should be moved out to another project which then refers to this one (as a submodule or via some other mechanism). Then the script can change at any time without the need to make changes here. |
|
@pdonahue-ventana if the .h file and/or the script needs an update to match the ratified spec then we should update to fix that issue. |
|
The .h file changes have more to do with C syntax than with the actual debug spec content. This comment basically summarizes it: The change does, for example, have |
The pull request #858 introduces four typedef for some struct in the generated 'debug_defines.h'
Using typedef is not welcome by every project that should include these generated files.
For example, OpenOCD coding style requires not adding new typedef.
This series:
I still have doubts if I should keep the backward compatibility. Please let me know!