Re: Parameter corruption in the FFI for PPC64?

Hi Gary, you're absolutely right, I hadn't realised that I was  =

compiling my tiny C test in 32-bit mode instead of 64.

The C code you made is indeed equivalent to the Lisp counterpart, and  =

it proves that something is wrong with the implementation of  =

mDNSResponder for PPC64, rather than with OpenMCL.

I'll try to solve this issue with the mDNSResponder guys (luckily it  =

is also an open source project).

Many thanks!

On 21 Dec 2006, at 15:59, Gary Byers wrote:

> 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 what 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 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))
>>     	{ 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
>>
>> <mdns.c>