[Vm-dev] Help Request: gdb usage et al

Eliot Miranda eliot.miranda at gmail.com
Thu Jul 28 21:02:53 UTC 2022


Hi Ken,

On Thu, Jul 28, 2022 at 1:20 PM <ken.dickey at whidbey.com> wrote:

>  Greetings,
>
> I am trying to gain runtime info for use of Alien on a RiscV64 Linux
> system, but [A] I have barely used gdb in the last couple of decades and
> [B] have hardly used Squeak in a decade or so, and [C] never used Alien.
>
> With that confession out of the way.. my proximate problem is trying to
> set a breakpoint in a thunk to capture where things are going into the
> weeds.
>
> The attached file has the gritty details.  I am trying
> Alien>>exampleCqsort
>
> The Smalltalk setup code is copying a hand assembled byteVector into an
> Alien.  I am catching the copy operation in gdb in IA32ABI.c:
> primAlianReplace to get the code address, then trying to set a
> breakpoint there -- which seems to fail.  Get SIGILL (illegal
> instruction) when the PC gets to the start of the thunk.
>
> So:
>    [A] How do I find out if the thunk memory is properly Executable?
>

If, when the processor executes the call instruction to the thunk, it
generates a SIGBUS, SIGILL or SIGSEGV then it's not executable. I think
it'll be SIGBUS, but these categories are a little fluid.  Is it an illegal
instruction, or a bus error, or a segmentation violation to call
instructions in non-executable memory?  I don't know :-)
Note
that platforms/Cross/plugins/IA32ABI/riscv64abicc.c:allocateExecutablePage
does the work.  SO putting a breakpoint in that and checking that the call
to mprotect succeeds is a first step.  (And I would delete all the
alternative guff for defined(MAP_JIT) & defined(_MSC_VER) ||
defined(__MINGW32__) unless RISCV is actually being used for MacOS or
win32.  So I guess that means just delete the defined(MAP_JIT) option.

And note that the first thunk allocated should be towards the start of the
first result of allocateExecutablePage.  So
- put a breakpoint in allocateExecutablePage
- run until that is hit, "finish" and see what it returns.
- put a breakpoint in the FFI callout
- continue
- now you're at a breakpoint in the callout and you know the address of the
first allocateExecutablePage, so you can disassemble at that address and
check if the thunk code looks correct and set a breakpoint in it if you
want to step through thunk invocation

   [B] RiscV64 is little-endian.  Are the bytes correctly ordered?
>

You'll be able to tell by disassembling a thunk. e.g.
gdb$ x/10i 0x12345678

>    [C] Is the math right for accessing the primEntryThunkAddress at
> thunkStart+0x28 ?
>

You'll have to work that out yourself.

> Any help appreciated.
>
> Thanks a bunch,
> -KenD
>

HTH

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220728/cec78b30/attachment.html>


More information about the Vm-dev mailing list