[Openmcl-devel] Troubleshooting FFI calls on ARM

[lsxvdqe]

Do other functions (like printf) segfault as well?
What happens if you call some foreign function with EXTERNAL-CALL?
#_getpid comes from the interface database, so try to FFI directly.
You will have to do this anyway, if you want to make some bindings.

On Thu, Jun 20, 2019 at 09:31:33AM -0500, Jeremy Shoemaker wrote:
> I decided this morning to make sure everything on the device is sane, at
> least as far as this particular function is concerned. Writing a C program
> that just calls getpid and prints the result works fine with no segfaults.
> It seems like it's definitely something on the CCL side of things.
> 
> Jeremy
> 
> On Wed, Jun 19, 2019 at 9:36 PM Jeremy Shoemaker <jeremy at codingkoi.com>
> wrote:
> 
> > Okay, that was my thinking though I couldn't remember exactly how to get
> > function pointers in C. After some fun setting up a cross-compiler, I got
> > the test C program on the device, and then wrote the following Lisp code to
> > try to duplicate the code.
> >
> > -----------------------------------------------------
> > (defun peek-getpid-memory ()
> >   (let* ((addr (%ptr-to-int (foreign-symbol-address "getpid"))))
> >     (loop for offset from 0 to 15
> >        do
> >          (format t "~X " (%get-unsigned-long (%int-to-ptr (+ addr (* 4
> > offset))))))))
> > (peek-getpid-memory)
> > -----------------------------------------------------
> >
> > I hope I did that right. I'm not terribly familiar with CCL's FFI yet.
> > Given that I got the exact same output, I think it means I did.
> >
> > -----------------------------------------------------
> > remarkable: ~/ ./test
> > ee1d2f70 e52d7004 e5123454 e3530000 da000002 e1a00003 e49d7004 e12fff1e
> > 1a000003 e5121458 e3510000 11a03001 1afffff7 e3a07014 ef000000 e3530000
> > remarkable: ~/ ccl/armcl -l test.lisp
> > EE1D2F70 E52D7004 E5123454 E3530000 DA000002 E1A00003 E49D7004 E12FFF1E
> > 1A000003 E5121458 E3510000 11A03001 1AFFFFF7 E3A07014 EF000000 E3530000
> > -----------------------------------------------------
> >
> > That seems to indicate it's pointing at the same place. Assuming that the
> > address coming back from (foriegn-symbol-address "getpid") is the same
> > thing that is invoked by the reader macro in (#_getpid), then it's
> > confusing that I'm getting a segfault.
> >
> > Any other ideas?
> >
> > Jeremy
> >
> > On Wed, Jun 19, 2019 at 4:26 PM Ron Garret <ron at flownet.com> wrote:
> >
> >>
> >> On Jun 19, 2019, at 2:04 PM, Jeremy Shoemaker <jeremy at codingkoi.com>
> >> wrote:
> >>
> >> > One suggestion: use %get-signed-long to read out a few bytes of memory
> >> at the location reported by (external "getpid”) and then write a little C
> >> program that does the same thing and see if you get the same result.
> >>
> >> I'm not sure I entirely follow, at least the C program part. Are you
> >> suggesting peeking at the memory pointed to by the `getpid` function in C?
> >>
> >>
> >> Yes.  Exactly.
> >>
> >> I'm not quite sure how to do that, but my C is pretty rusty.
> >>
> >>
> >> #include <unistd.h>
> >> #include <stdio.h>
> >>
> >> int main() {
> >>   unsigned int *p = (unsigned int *)getpid;
> >>   for (int i=0; i<16; i++) printf("%x ", *(p+i));
> >> }
> >>
> >>

> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel