More conservative field resolution in MLIL/HLIL for bitfields

[jpenalbae]

What is the feature you'd like to have?
The new bitfield support in structures is awesome, but until bitfield resolution is added to MLIL/HLIL (#7533), I think there should be at least an option to disable displaying bitfield accessors on MLIL/HLIL.

Is your feature request related to a problem?
For example when using the SVD loader plugin, a bunch of registers will include bitfields, and HLIL will always defaults to the first bitfield. This is my opinion produces misleading output and makes you think the code is dealing with a bitfield when it is really not.

Here are two examples:

Are any alternative solutions acceptable?
I see two possible ways:

• Add an option to enable/disable using bitfields in the MLIL/HLIL views
• In the SVD plugin, add an option to not create bitfields in the structures

The second option is not very good as the problem will persist for any structure using bitfields which wasn't created by the SVD plugin.

Additional Information:
One clear example where printing bitfields will be misleading is working with an MCP server. Any LLM accessing the MLIL/HLIL view produced by binary ninja will think that is bitfield being accessed and totally mess up....

[emesare]

This is likely going to be the next step prior to actually resolving, I had originally intended to shut down the bitfield accesses altogether in MLIL and HLIL but opted not to because of the possible side effects to do with our existing manual field resolution for union accesses, instead keeping the original behavior prior to even adding bitfields to the type system. Not to say this should not be done, just trying to add some context as to what the thought process was.