Re: [gpsd-dev] Half the port problems are solved; seeking help with RTCM2 driver

[Bernd Zeimetz]

On 04/25/2012 09:48 AM, Eric S. Raymond wrote:
> Bernd Zeimetz <address@hidden>:
>> armel: no regressions
>> armhf: no regressions
>> hurd-i386: no regressions
>> i386: no regressions
>> ia64: no regressions
>> kfreebsd-amd64: no regressions
>> kfreebsd-i386: no regressions
>> powerpc: no regressions
>> ppc64: no regressions
>  
> Excellent.  That is bit-for-bit identical handling of binary protocols
> on quite a range of architectures, endiannesses and word sizes.  Not a
> small achievement!
> 
>> It would be nice if the regress-driver would just fail if there is a pty 
>> issue
>> instead of spitting out a  lot of diffs.
> 
> I agree.  Can you think of a way to test for this from a shellscript?


Only something like calling a few lines of Python code...


>> Where ever the issue is, it doesn't seem to be related to endianess issues.
>> Sparc, s390 and s390x (the 64bit s390 port) seem to be the only architectures
>> with issues so far.
> 
> Yes, as I said I'm pretty sure this is down to #pragma pack(1) not being
> implemented on those machines.


I'm kinda sure it is implemented, but my guess would be that you hit the
architectures where aligned access is required for some datatypes.
Unaligned access usually throws a sigbus on sparc, but my wild guess is
that you work around that somehow...

To find the issue do something like
- (hex)-dump buf in rtcm2_unpack
- print each struct member after the
    struct rtcm2_msg_t *msg = (struct rtcm2_msg_t *)buf;
  call

do this on a working and a non-working architecture with the same
endianess and compare the results. That should at least show where the
issue resides, but I doubt it is easily fixable without rewriting the
whole thing into something that splits buf into pieces and fills sane
(sane as in: ensure there is no unaligned access, do not use #pragma
pack...) structs manually (actually, looking at the code I think that
would be easy to do, just a lengthy amount of work).


>> As you can see on
>> http://buildd.debian-ports.org/status/package.php?p=gpsd&suite=sid
>> we even have some really exotic unofficial architectures - unfortunately not 
>> all
>> build-dependencies are available there. If there is an interest in making 
>> gpsd
>> build on one of the listed architectures, please let me know (I think the 
>> main
>> issue is QT not being available...).
> 
> alpha, hppa, sh4, and m68k would be good checks to have.  Missing Qt is
> not a problem for the regression tests; that only affects the client side.

sh4 managed to build the package in the meantime, no issues.
I'll have a look what needs to be done to build it on the other platforms.

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F