================
@@ -1670,13 +1670,14 @@ lldb::ValueObjectSP DoGuessValueAt(StackFrame &frame,
ConstString reg,
break;
case Instruction::Operand::Type::Immediate: {
----------------
labath wrote:
> What exactly is an immediate here? It's not a literal value, if it were we
> wouldn't load anything from anywhere. So it's going to be some address or
> offset from something, that then points to a value, correct?
All of this is in an `if (instruction_sp->IsCall()) {` block (line 1633), so
the immediate is the address that you jump to (in a "direct" call instruction).
So, in an instruction like `callq 0xdead` it would be the `0xdead` part.
In reality the actual instruction encodes the value in a PC-relative form
(offset from the address of the call instruction), but the disassembler
corrects for that. However, it still uses the file address of the instruction
(or the virtual address as ELF calls it). It doesn't use the actual address of
source instruction in memory.
> And the file address is relative to the normal location of the file in
> memory, or maybe to the file itself. Either way, we can know where it was
> loaded to and correct for that, which handles anything ALSR may move about.
> Right?
Yes, but it's kind of the opposite: we don't need to correct for ASLR because
we are already in the "address relative to file" space. We are doing this to
find the target of the call instruction and this is already because the debug
info and symbol table will contain the unrelocated "file" addresses. The
original code was trying to get out of the load address space for no reason.
I hope that makes sense.
https://github.com/llvm/llvm-project/pull/128512
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
