[Openmcl-devel] Troubleshooting FFI calls on ARM

[Timothy Moore]

On 6/21/19 6:09 PM, Jeremy Shoemaker wrote:
> Okay, I thought I had tried this already, but it definitely works with "printf" using both methods. I was using "getpid" because it's the first example in the documentation. I had already tried the underlying EXTERNAL-CALL approach with "getpid", it segfaults both ways.
> 
> I went back and tried the other examples there. "getpid" and "log2" both segfault, but the example with "write" works. I was thinking maybe there might be some connection between which library they're part of, but the first and last are both posix functions and "log2" is from libc.
> 
> Any ideas on how I can go about figuring out why some of them work and the others don't?
I don't know if this is relevant, but there is a lot of magic associated with the "simple" system calls like getpid in that they may not be function calls, implemented instead as direct access to kernel-mapped memory, whereas printf is most likely a simple C function call. I encountered this years ago when implementing shared library access for CMUCL.

Tim
> 
> Thanks,
> Jeremy
> 
> On Fri, Jun 21, 2019 at 10:03 AM lsxvdqe <lsxvdqe at gmail.com <mailto:lsxvdqe at gmail.com>> wrote:
> 
>     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 <mailto: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 <mailto:ron at flownet.com>> wrote:
>     > >
>     > >>
>     > >> On Jun 19, 2019, at 2:04 PM, Jeremy Shoemaker <jeremy at codingkoi.com <mailto: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 <mailto:Openmcl-devel at clozure.com>
>     > https://lists.clozure.com/mailman/listinfo/openmcl-devel
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>