Remove typedef in generated 'debug_defines.h'#1122
Remove typedef in generated 'debug_defines.h'#1122borneoa wants to merge 3 commits intoriscv:mainfrom
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 <borneo.antonio@gmail.com>
Drop the use of types defined with typedef and use the names of the struct. Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
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 <borneo.antonio@gmail.com>
| "\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.
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 |
4 participants
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!