Hello list,
In OpenWrt's forum a user raised a topic about being unable to use
Asterisk on his armeb xscale device. We narrowed it down to sqlite.
Asterisk was unable to insert a simple table.
Couldn't prepare statement 'CREATE TABLE IF NOT EXISTS astdb(key
VARCHAR(256), value VARCHAR(256), PRIMARY KEY(key))': malformed database schema
(?)
Couldn't create astdb table: malformed database schema (?)
ASTdb initialization failed. ASTERISK EXITING!
The user added that the last working version is from years ago (OpenWrt
Barrier Breaker, sqlite 3.8.7.4).
I don't have access to xscale armeb hardware so I ended up using
qemu-armeb. 3.8.7.4 was indeed working. I did a git bisect between that
version and 3.12.0 (can't really recall why I picked 3.12.0).
I ended up with this:
329428e2088aabb1db2dc6e48108b76551405a8e is the first bad commit
commit 329428e2088aabb1db2dc6e48108b76551405a8e
Author: drh <d...@noemail.net>
Date: Tue Jun 30 13:28:18 2015 +0000
Remove the use of htonl() in the previous check-in due to linkage issues.
Add the get2byteAligned() macro and use it for access to the cell offsets
on btree pages for about a 1% performance gain.
FossilOrigin-Name: 79ff36b7170c9e7e7a9935c8b9d1665867771087
:100644 100644 a786e15afe8632e66350667d25015afd3b8b6a9a
cfb68a89fa85fc5a367d2fdf967a5b222aeab3dc M manifest
:100644 100644 e1a76f6457307e3aa2d3f97a71d81b00aa71e288
0e8e09954965f5d56a6285b6b9c9cbf6a5f8e5a3 M manifest.uuid
:040000 040000 192f172deef1f2c552740c6cca11f2757b78f036
575334b08e6514e2941915a9d7dd5c780e251287 M src
That commit added get2byteAligned(). And then I saw this:
#ifndef SQLITE_BYTEORDER
# if defined(i386) || defined(__i386__) || defined(_M_IX86) || \
defined(__x86_64) || defined(__x86_64__) || defined(_M_X64) || \
defined(_M_AMD64) || defined(_M_ARM) || defined(__x86) || \
defined(__arm__) || defined(_M_ARM64)
# define SQLITE_BYTEORDER 1234
# elif defined(sparc) || defined(__ppc__)
# define SQLITE_BYTEORDER 4321
# else
# define SQLITE_BYTEORDER 0
# endif
#endif
So for everything where the compiler defines __arm__ little endian is
assumed. Why did this work out before? - Because the other macros that
get used when "SQLITE_BYTEORDER" is "1234" are accessing 4 Byte. And
armeb is able to deal with that (see
https://en.wikipedia.org/wiki/Endianness#Bi-endianness). But for 2 Bytes
(get2byteAligned!) this doesn't work.
At first we just removed "defined(__arm__)" and this worked out fine.
But I think it'd be better to replace it with:
#if defined (__ARMEB__) || (__AARCH64EB__)
for BE and
#if define (__ARMEL__) || (__AARCH64EL__)
for LE.
There are other macros that could be used, of course (see
https://sourceforge.net/p/predef/wiki/Endianness/ for a list of them).
But I don't want to hang my head too far out of the window :)
The "_M_ARM" and "_M_ARM64" macros seem to be from MS VS. So there the
ARM generalization could also cause problems, but I don't know what
other macros they have there.
Do you agree with the above? Do you want me to send a patch?
Kind regards,
Seb
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
