Replies: 10 comments 17 replies
-
|
Continuing the discussion from here. |
Beta Was this translation helpful? Give feedback.
-
In the screenshot you shared in #7569 (comment), a red I can see that being useful. There is DWARF information that anchor-coverage throws away (e.g., column information). I can look into whether that could be incorporated into its output to show things like
In #7569 (comment), you said you were able to make it work with LiteSVM 0.6.1 on Solana 2.1.20. Can I ask what you did to make it work? |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to add a few remarks that do seem more like tough obstacles to overcome with this approach. First of all, in order to reduce byte code size and CUs Solana programs are aggressively optimized upon compilation. Moreover some functions result inlined and the SBPF code coverage generator remain blind for them. Setting Is it viable to allow bigger than 4k stack frames for Solana programs compiled without optimizations? And this would be only in the case when trying to get more accurate code coverage statistics? Probably there's a better approach? |
Beta Was this translation helpful? Give feedback.
-
This has been added in Solana 2.2.x. However I've only managed to make the SBPF coverage vault example work with 2.1.x (particularly 2.1.20). So in order to try building the program with dynamic stack frames my next step was to try to jump to 2.2.x or 2.3.x but unfortunately the addr2line/gimli crates don't seem to work with the SBPF debug information built along the vault program. The first difference between 2.1.x and 2.2.x I've spotted is the migration to a new Machine type in the ELF header: Solana 2.2.x and 2.3.x built programs make llvm-addr2line emit warnings like this: Probably this is an expected behavior since the machine type has changed and the standard llvm tools can't handle it correctly? Can you provide some clarification what has changed in the DWARF abbreviation definitions since 2.2.x? I may be wrong here but LiteSVM is tied to solana-program-runtime which is tied to the legacy SBPFVersion::V0 format. Doesn't it automatically deprive us of the ability to use dynamic stack frames in this setup in the first place? |
Beta Was this translation helpful? Give feedback.
-
A bug in Solana rustc's DWARF generation code was fixed in this PR: anza-xyz/llvm-project#159 I think that's what @LucasSte was referring to in #7569 (comment), and that's what you're seeing. The fix appears in Solana platform tools 1.51. I suspect it would be possible to patch an earlier version of the platform tools, but I haven't tried. |
Beta Was this translation helpful? Give feedback.
-
|
Now that we added an environment variable for the remote debugger ( |
Beta Was this translation helpful? Give feedback.
-
|
I re-opened anza-xyz/sbpf#71 with only the move of the instruction trace from the |
Beta Was this translation helpful? Give feedback.
-
|
Beyond having the parsed instruction alongside the register trace (anza-xyz/sbpf#71), it would also be nice to have the program ID of the executing program. To recover this currently, I have to do something like the following: Fwiw, I also resorted to forking sbpf to avoid tracing every instruction in favor of tracing JMP class opcodes only. |
Beta Was this translation helpful? Give feedback.
-
|
Alright, I think I found a solution (#8285) which should cover all the wishes:
One example of how it could be used: invoke_context.iterate_vm_traces(|instruction_context, executable, register_trace| {
let program_id = instruction_context.get_program_key().unwrap();
let instruction_data = instruction_context.get_instruction_data();
let borrowed_account = instruction_context.try_borrow_instruction_account(0).unwrap();
let first_instruction_account_key = borrowed_account.get_key();
let first_instruction_account_lamports = borrowed_account.get_lamports();
let first_instruction_account_data = borrowed_account.get_data();
let (_vm_addr, program) = executable.get_text_bytes();
let joined = register_trace
.iter()
.map(|registers| {
(
registers,
ebpf::get_insn_unchecked(program, registers[11] as usize),
)
})
.filter(|(_registers, insn)| insn.opc & 7 == ebpf::BPF_JMP && insn.opc != ebpf::BPF_JA);
// ... do your thing here
})With this most of LiteSVM/litesvm#221 should be solved upstream and the PR could be reduced to the part that writes the files to |
Beta Was this translation helpful? Give feedback.
-
|
I've filed a PR (#8407) that is related to this discussion. Briefly we have to be sure SBPF is in |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Aggregating the discussions in anza-xyz/sbpf#67 and #7569 here.
Beta Was this translation helpful? Give feedback.
All reactions