-
Notifications
You must be signed in to change notification settings - Fork 26
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
Dwarf2json can produce bitfield JSON that doesn't adhere to the schema #14
Comments
The following is the relevant
From the snippet above, I can see where |
It's more the null type that we'd need to deal with... 5:S Ironically the schema might allow the negative bit position, but the type isn't allowed to be null. I don't read DWARF output well enough to know how to resolve that, but anything to improve it or handle that case would be good. 5:) |
The reason the "type" is |
Thanks, so that generated symbols that passed the schema validation, but the field will be completely unusable (due to the -128 Is it valuable to know that it's a bitfield if all the other information about it is inaccurate? It probably won't matter to the user because I don't expect that type to ever get hit, but if it does I think generating a type with bad data is worse than saying the entire thing's a void. What are people's thoughts? |
For reference, it looks as though we already decided how to deal with unknown types in #7. 5:) |
I pushed another branch issue-14-omit-fields-with-unsupported-types that omits bitfields that have an unsupported type. This is probably a more consistent behavior, since non-bit fields with unsupported types were already being omitted. Let me know what you think of this approach or feel free to suggest another one. |
Hmm, I'm not seeing any change for the
Ideally this would be either (inaccurate but can be cast):
or nothing at all (slightly less inaccurate, but only due to omission rather than correctness). I'm not sure how to differentiate bad bitfields though (I don't know which is more accurate between negative values for bit_length/position, or a bad subtype)? |
Try the latest This is the output that I'm seeing:
|
Ah cool, I must've screwed up switching branches. Yep, all looks good! 5:) |
If we are happy with this solution, I can merge it into master via #16. |
Yeah, I think that's reasonable. We should keep an eye on the library, but I guess if it ever does start returning a valid type it won't get rejected anymore. Happy for #16 to be merged if you are... 5:) |
Hiya,
Having regenerated a bunch of profiles, including some new ones, it appears there are some bad values being produced. With jsonschema installed, trying to use one of these produces:
which turns out to be because of the followin code generated from dwarf2json:
which features a null value (which can be both enum or base). The bit_length and bit_position also look wrong. I've got the original KDK files for this that were used, and I'll attach the generated JSON. Shout if you need any more information... 5:)
The text was updated successfully, but these errors were encountered: