proposed same patch as already submitted for opensuse at https://build.opensuse.org/request/show/286595
Michel Normand (1): avoid smscb test failure for ppc/ppc64 archi
include/osmocom/gsm/protocol/gsm_03_41.h | 37 ++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
as reported on https://build.opensuse.org/request/show/286595 libosmocore 0.7.0 avoid smscb test failure for ppc/ppc64 that is big-endian x === x 7. testsuite.at:45: testing smscb ... x ./testsuite.at:48: $abs_top_builddir/tests/smscb/smscb_test x --- expout 2015-02-17 16:19:24.010024039 +0000 x +++ /home/abuild/rpmbuild/BUILD/libosmocore/tests/testsuite.dir/at-groups/7/stdout x @@ -1,4 +1,4 @@ x -(srl) GS: 1 MSG_CODE: 1 UPDATE: 0 x +(srl) GS: 0 MSG_CODE: 256 UPDATE: 1 x (msg) msg_id: 1293 x -(dcs) group: 1 language: 0 x +(dcs) group: 0 language: 1 x (pge) page total: 1 current: 1 x 7. testsuite.at:45: 7. smscb (testsuite.at:45): FAILED (testsuite.at:48) x ===
Signed-off-by: Michel Normand normand@linux.vnet.ibm.com --- include/osmocom/gsm/protocol/gsm_03_41.h | 37 ++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
diff --git a/include/osmocom/gsm/protocol/gsm_03_41.h b/include/osmocom/gsm/protocol/gsm_03_41.h index 0ece6cc..af00503 100644 --- a/include/osmocom/gsm/protocol/gsm_03_41.h +++ b/include/osmocom/gsm/protocol/gsm_03_41.h @@ -11,6 +11,26 @@ #define GSM341_7BIT_PADDING '\r'
/* Chapter 9.3.2 */ +#if defined(__powerpc__) && (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) +struct gsm341_ms_message { + struct { + uint8_t gs:2; + uint8_t code_hi:6; + uint8_t code_lo:4; + uint8_t update:4; + } serial; + uint16_t msg_id; + struct { + uint8_t group:4; + uint8_t language:4; + } dcs; + struct { + uint8_t current:4; + uint8_t total:4; + } page; + uint8_t data[0]; +} __attribute__((packed)); +#else struct gsm341_ms_message { struct { uint8_t code_hi:6; @@ -29,8 +49,24 @@ struct gsm341_ms_message { } page; uint8_t data[0]; } __attribute__((packed)); +#endif
/* Chapter 9.4.1.3 */ +#if defined(__powerpc__) && (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) +struct gsm341_etws_message { + struct { + uint8_t gs:2; + uint8_t alert:1; + uint8_t popup:1; + uint8_t code_hi:4; + uint8_t code_lo:4; + uint8_t update:4; + } serial; + uint16_t msg_id; + uint16_t warning_type; + uint8_t data[0]; +} __attribute__((packed)); +#else struct gsm341_etws_message { struct { uint8_t code_hi:4; @@ -44,6 +80,7 @@ struct gsm341_etws_message { uint16_t warning_type; uint8_t data[0]; } __attribute__((packed)); +#endif
#define GSM341_MSG_CODE(ms) ((ms)->serial.code_lo | ((ms)->serial.code_hi << 4))
I'm wondering if we shouldn't just refuse to build alltogether on big-endian.
It's known to be broken.
This might be the only instance picked up by the test case, but pretty much the whole 'gsm' part is dependent on little endian snce we used those 'struct' construct to represent gsm messages all over the place.
Cheers,
Sylvain
baseband-devel@lists.osmocom.org