LLIL errors logged after spurious calls to `Architecture.get_instruction_low_level_il`

[droe]

Version and Platform (required):

• Binary Ninja Version: 5.1.7929-dev (2a0bcecd), as well as 5.0 and 4.2 release versions
• Edition: Personal
• OS: macOS
• OS Version: 15.5
• CPU Architecture: arm64

Bug Description:
When clicking and then hovering over certain integer values in HLIL, a Python architecture plugins's Architecture.get_instruction_low_level_il gets called spuriously with an empty LowLevelILFunction passed as the il argument. The spurious call is a single call only for a single instruction/address roughly where hovered over, not for the entire function.

If during these spurious calls, the Architecture plugin uses LowLevelILFunction.add_label_for_address to create labels for addresses, e.g. for use with il.if_expr or il.goto, then core will subsequently log the following concerning-looking warning and error:

[Default] LLIL if target 7 (instruction 0 in 0x0) does not have a marked label
[Default] LLIL out of bounds in function 0x0 0x7

These errors only happen after the spurious calls. They do not happen after the initial pass over the entire function, which seems to get lifted correctly.

The 7 in the log output seems to come from unresolved LowLevelILLabel instances that for some reason always have operand 7 while being unresolved (which might be a separate bug).

Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

1. Install https://github.com/droe/binja-bpf/tree/repro/upstream-issue/7099
2. Load any BPF program, e.g. https://github.com/droe/binja-bpf/tree/repro/upstream-issue/7099/examples or https://tmp.roe.ch/0x4061a0_0x728_bpfcode.bin
3. Switch to HLIL
4. Click on and then hover over a constant such as 0x1fff
5. Notice the errors in the log

Expected Behavior:
One of:

• No spurious calls into Architecture.get_instruction_low_level_il with empty il to lift a single instruction, or
• No errors from core after spurious calls return with unresolved labels

Workaround:
A seemingly workable workaround is for an Architecture's get_instruction_low_level_il to return 0 when addr != 0 and len(il) == 0, but this only works in my case because there is only ever a single function, at offset 0.

[zznop]

Thanks for reporting. I was able to reproduce the issue. It is caused by mouseover dialog that is meant to display a instruction summary. It calls get_instruction_low_level_il out-of-band on the current instruction's opcode bytes. This dialog is causing a number of issues with architecture plugins where more context is needed than just the opcode bytes in order to successfully lift an instruction. I've initiated a discussion internally and will get back to you soon.