Re: Parameter corruption in the FFI for PPC64?

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1469717647-1166713183=:72856
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

When I compile the enclosed C function in 64-bit mode and run it on
a G5 under 10.4.8, it seems to behave the same way as the lisp code
in your message does (generates a -65540 error code.)


[~] gb@ronin> cc -m64 -g mdns.c -o mdns
[~] gb@ronin> ./mdns
error =3D -65540

I tried to make the C code do exactly what the lisp code does.
Do you see any difference ?

If not, I'm tempted to say that this isn't an OpenMCL ppc64 FFI
issue.

When I compile the C code in 32-bit mode, it seems to work
as expected:

[~] gb@ronin> cc -m32 -o mdns32 mdns.c
[~] gb@ronin> ./mdns32
error =3D 0

I don't know enough about Bonjour to understand why this is the
case, but I do know of cases where ppc64 library functions have
bugs that their 32-bit counterparts don't share.

From=20what I can tell, DNSServiceRegister packs its parameters
into a structure, sends the contents of that structure to
some other process over a socket, then receives a replay from
that other process over the same socket.  The reply contains
the -65540 error code.

It could be the case that the 64-bit implementation of=20
the code that packs things into the structure doesn't align
things the way that it's supposed to.

If you find some way in which the C code that fails when compiled
in 64-bit mode differs from the lisp code and think that this might
in fact be an FFI bug, I'll look at things again.  I did step
through some of DNSServiceRegister in GDB, and all of its parameters
seemed to been put in the right registers/stack locations by the
FFI.

On Thu, 21 Dec 2006, Sebasti=E1n Gonz=E1lez wrote:

> Hi,
>
> I see no apparent reason for the following FFI code to fail.
> It's about using the DNS Service Discovery API (i.e. Apple's Bonjour)
> in OpenMCL 1.0.
>
> It works without problem on a PPC32 machine, but it fails on a PPC64
> machine.
>
> #-----------------------------
>
> (ccl:defcallback register-service-reply (:address sd-ref
>                                          :unsigned-fullword flags
>                                          :signed-fullword error-code
>                                          (:* :char) name
>                                          (:* :char) regtype
>                                          (:* :char) domain
>                                          (:* :void) context
>                                          :void)
>     (format t "registered!~%"))
>
> (let* ((record-entry "path=3D/ide/")
>        (record (format nil "~c~a" (length record-entry) record-entry)))
>   (ccl:rlet ((cservice-ref :address))
>     (ccl:with-cstrs ((cname "Test")
>                      (ctype "_http._tcp")
>                      (crecord record))
>       (ccl:external-call "_DNSServiceRegister"
>                          (:* :void) cservice-ref
>                          (:unsigned 32) 0
>                          (:unsigned 32) 0
>                          (:* :char) cname
>                          (:* :char) ctype
>                          (:* :char) (ccl:%null-ptr)
>                          (:* :char) (ccl:%null-ptr)
>                          (:unsigned 16) 9001
>                          (:unsigned 16) (length record)
>                          (:* :void) crecord
>                          (:* :void) register-service-reply
>                          (:* :void) (ccl:%null-ptr)
>                          (:signed 32)))))
>
> #----------------------------
>
> DNSServiceRegister returns the -65540 error code, which means "bad
> parameter".
>
> (see http://developer.apple.com/documentation/Networking/Reference/
> DNSServiceDiscovery_CRef/dns_sd/index.html)
>
> I get the following in the log of the PPC64 machine:
>
> > tail /var/log/system.log
> ...
> Dec 21 10:44:13 einstein mDNSResponder: ERROR:
> handle_regservice_request - service->type_as_string bad
>
> From the code of mDNSResponder at http://darwinsource.opendarwin.org/
> 10.4.2/mDNSResponder-107/mDNSShared/uds_daemon.c, one can see that
> the line printing this log entry is the following:
>
> if (!*service->type_as_string || !MakeDomainNameFromDNSNameString
> (&service->type, service->type_as_string))
>     =09{ LogMsg("ERROR: handle_regservice_request - service-
> >type_as_string bad %s", service->type_as_string); goto bad_param; }
>
> It seems as if service->type_as_string was null in C, but I passed
> "_http._tcp" from Lisp.
>
> I wrote a tiny test in C, and it works on the PPC64 machine. Hence,
> the problem doesn't seem to be located in libSystem.dylib (where
> DNSServiceRegister is defined). My next guess is that something is
> wrong with OpenMCL's FFI for PPC64, specially because PPC32 does not
> exhibit the same problem.
>
> _______________________________________________
> Bug-openmcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>
--0-1469717647-1166713183=:72856
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=mdns.c
Content-Transfer-Encoding: BASE64
Content-ID: <[email protected]>
Content-Description: 
Content-Disposition: attachment; filename=mdns.c

I2luY2x1ZGUgPGRuc19zZC5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQoNCnZv
aWQNCmNhbGxiYWNrKEROU1NlcnZpY2VSZWYgc2RSZWYsDQogICAgICAgICBE
TlNTZXJ2aWNlRmxhZ3MgZmxhZ3MsDQogICAgICAgICBETlNTZXJ2aWNlRXJy
b3JUeXBlIGVycm9yQ29kZSwNCiAgICAgICAgIGNvbnN0IGNoYXIgKm5hbWUs
DQogICAgICAgICBjb25zdCBjaGFyICpyZWd0eXBlLA0KICAgICAgICAgY29u
c3QgY2hhciAqZG9tYWluLA0KICAgICAgICAgdm9pZCAqY29udGV4dCkNCnsN
CiAgZnByaW50ZihzdGRlcnIsICJNYWRlIGl0IHRvIGNhbGxiYWNrXG4iKTsN
Cn0NCg0KbWFpbigpDQp7DQogIEROU1NlcnZpY2VSZWYgcmVmOw0KICBjaGFy
ICpyZWNvcmQgPSAiXDAxMnBhdGg9L2lkZS8iOw0KICBpbnQgZXJyb3I7DQog
IA0KICBlcnJvciA9IEROU1NlcnZpY2VSZWdpc3RlcigmcmVmLA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAwLA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAwLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi
VGVzdCIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICJfaHR0cC5f
dGNwIiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgTlVMTCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgOTAwMSwNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgMTEsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJl
Y29yZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FsbGJhY2ss
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5VTEwpOw0KICBmcHJp
bnRmKHN0ZGVyciwgImVycm9yID0gJWRcbiIsIGVycm9yKTsNCn0NCg0KICAg
ICAgICAgDQo=

--0-1469717647-1166713183=:72856
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Bug-openmcl mailing list
[email protected]
http://clozure.com/mailman/listinfo/bug-openmcl

--0-1469717647-1166713183=:72856--