lenary wrote:
How does this work now that LLDB doesn't stop on the first unknown instruction?
I thought it now printed `` for that and kept going, but maybe that's
not right?
https://github.com/llvm/llvm-project/pull/164413
___
lldb-commits mailing l
lenary wrote:
That seems reasonable, can you document the reasoning in the commit message
please?
https://github.com/llvm/llvm-project/pull/163405
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinf
@@ -602,7 +604,104 @@ GetValObjFromFPRegs(Thread &thread, const
RegisterContextSP ®_ctx,
value, ConstString(""));
}
// we should never reach this, but if we do, use the integer registers
- return GetValObjFromIntRegs(thread, reg_c
https://github.com/lenary approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/163405
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
lenary wrote:
Can I ask why? And why 6+?
Have particular issues been seen with these?
https://github.com/llvm/llvm-project/pull/163405
___
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commi
lenary wrote:
> We don't have any big endian riscv ArchSpec entry today or I'd add a big
> endian riscv instruction decoding test too.
We're starting to get Big Endian support for RISC-V in LLVM, but I've asked
that those patches wait until after the branch as there's a lot of work to make
bi
lenary wrote:
> I didn't realize that the riscv instructions had a scheme for indicating
> their lengths, very convenient.
It "doesn't". LLVM objdump implements the scheme described in the spec, but for
>32-bit instructions, that scheme is not ratified so it could change in the
future (the no
lenary wrote:
> Doesn't seem the ideal format given that we have a known size, today most
> often 16/32/64, and I guess 48 for funsies.
Standard instructions are right now only 16/32, but custom instructions can be
any multiple of 16. This was the change to llvm-objdump to group bytes like gnu
lenary wrote:
To also respond to something earlier in the thread, where there is a little
complexity:
> The missing part is knowing how to split up that encoding value isn't it. For
> AArch64 you'd just print it because we only have 32-bit, Intel you would roll
> dice to randomly decide what
