#39 Endian issue, pcapsipdump not working on big endian
Hi all,
I'd like to update pcapsipdump on OpenWrt from 0.2 to a current trunk snapshot. I ran into two problems.
1) I get errors like these:
/home/sk/tmp/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.4.0_musl/bin/g++-uc: line 22: [: s: integer expression expected
In file included from trigger.cpp:9:0:
pcapsipdump_lib.h:18:34: error: 'time_t' does not name a type; did you mean 'size_t'?
const time_t t);
^~~~~~
size_t
To get around this I moved the <sys/stat.h> from pcapsipdump_lib.cpp to pcapsipdump_lib.h (patch attached).
2) When starting the cross-compiled binary on my Big Endian host it just sits there and does nothing. The old 0.2 pcapsipdump on the other hand works fine.
The problem for me is that pcapsipdump.h only checks if __LITTLE_ENDIAN or __BIG_ENDIAN is defined and then "does stuff". When looking at line 31:
if !defined (__LITTLE_ENDIAN) && !defined (__BIG_ENDIAN)
it's clear that checking the defines later on to base decisions on doesn't make sense: They're both defined. So the first check will always be true (Little Endian). Which is why pcapsipdump works there, no doubt, but on BE it doesn't.
I changed the tests to
#if __BYTE_ORDER == __LITTLE_ENDIAN
...
#elif __BYTE_ORDER == __BIG_ENDIAN
...
and that seems to work out fine. pcapsipdump now does its job.
I'll attach the patch for that, too. Not sure if you want to do it like this or some other way.
Kind regards,
Seb
Here's the endian patch I used.
time_t fix is in [r150], thanks!
Related
Commit: [r150]
Diff:
Re: endinannes though - that is not what is going on here.
__LITTLE_ENDIANor__BIG_ENDIANare used to construct packet header structs. On most systems, one of them is defined to indicate endianness (not both). If neither is defined, then, as a fallback__BYTE_ORDERis probed, and either__LITTLE_ENDIANor__BIG_ENDIANis defined locally.Do you complile this natively on BE host? Which gcc/libc? Can you try to compile lines 31..42 of pcapsipdump.h standalone to see if this is what compliler chokes on?
Hello Aex,
I crosscompile on x86_64 with OpenWrt buildroot. gcc is 7.4.0 and libc in this case is musl. Will try tonight.
I think
__LITTLE_ENDIANand__BIG_ENDIANcan't be used for tests, because they seem to be defined both at the same time. I put an #error belowif !defined (__LITTLE_ENDIAN) && !defined (__BIG_ENDIAN)and the build never reached this error. Also, pcapsipdump testing like this ("do this if both
__LITTLE_ENDIANand__BIG_ENDIANaren't defined") suggests this is normal.I found this site: https://sourceforge.net/p/predef/wiki/Endianness/. It suggests that the two are just values that are used by
__BYTE_ORDERmacros.And the system headers used them like this, which is why testing
__BYTE_ORDERfor__LITTLE_ENDIANand__BIG_ENDIANworks. You can probably also check if either__LITTLE_ENDIAN__or__BIG_ENDIAN__are defined according to the website (mind the trailing underscores).Kind regards,
Seb
PS: argh, SF doesn't seem to show all the underscores that I typed in the last paragraph there :(
EDIT (aexaey): I've edited your comment above to add backtick around keywords. That preserves underscores in SF's markdown dialect.
Last edit: Aex Aey 2019-10-07
Ok, I you are right. I was confused beween solaris-style defines (either
_LITTLE_ENDIAN == 1or_BIG_ENDIAN == 1; other one undefined) and BSD/Linux-style defines (either__BYTE_ORDER == __LITTLE_ENDIANor__BYTE_ORDER == __BIG_ENDIAN; all three always defined), so trunk since [r139] was broken on BE systems. Should be fixed in [r151], can you give it a try?Related
Commit: [r139]
Commit: [r151]
Sure, will try when I get home and ping you back. Thanks!
Hello Aex,
It's working fine now without patches. I compile-tested on x86_64, once a native compile and once a cross-combile for MIPS BE, endian was properly detected during both. Run-tested on MIPS BE.
Thank you very much!
Regards,
Seb
P.S.: I didn't see a way to close this ticket. Maybe you can close it when you get around to it.