Hi We have sqlite (v3.3.7) running on an os-less ARM based platform - we use MINGW cross compilers (GCC3.4.4) - from CodeSourcery.
There was an issue earlier on that seems to be an issue with 64 bit support - we switched off the 64bit support in the compilation of the sqlite library and this for now has got the data base up and running on our platform. Richard -----Original Message----- From: Nuno Lucas [mailto:[EMAIL PROTECTED] Sent: 11 September 2006 21:12 To: sqlite-users@sqlite.org Subject: Re: [sqlite] met "ARM7TDMI raised an exception,data abort" when executing sqlite3Parser() in ARM environment [forgot to reply to the list] ---------- Forwarded message ---------- From: Nuno Lucas <[EMAIL PROTECTED]> Date: Sep 11, 2006 9:07 PM Subject: Re: Re: [sqlite] met "ARM7TDMI raised an exception,data abort" when executing sqlite3Parser() in ARM environment To: [EMAIL PROTECTED] On 9/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I don't think NULL callback and error pointer will be the reason. > Because I've seen this kind of usage in the list for several times. As I said earlier, I don't think this is the reason also. Just one more thing you could check. > Anyway, I'll try later and report the result to the list. > > If it is a misaligned-pointer problem, what can I do? > > I don't make any change to the sqlite source code, how should this > happen? I can run it correctly on PC(windows XP), why can't in an > embedded environment? I'm confused... You are aware they are completely different architectures, don't you? You also didn't specify what OS you are running, which could make it easier to get help from other experienced programmers for your platform (if you are using CodeWarrior I would guess it's not Windows CE). A misaligned-pointer can never occur on Windows (desktop editions, not Windows CE), because Windows only runs on the Intel x86 processor family, which mask that kind of things from you (although you usually have a performance hit). Basically it means you are accessing memory that is not aligned to the minimum granularity the processor supports (which depends on the processor and processor mode, but usually is 32 bits - 4 bytes - for 32-bits cpus, 64 bits - 8 bytes - for 64-bits cpus, etc). I don't know if that is your case, but I have seen it before on Windows CE (using a StrongArm processor) and because there aren't so many people using SQLite with those processors, the code path is not so much tested as the x86 case (which doesn't trigger a cpu exception, only a performance hit). It's up to you to confirm this is the case, but there are other things which can be wrong, like little/big endian problems, compiler bugs (recent platforms don't have so much testing as older ones), bad compiler/linker options, stack overflows (because in embedded systems you usually have a much lower default stack size), etc. Without more info that's all I can say. Regards, ~Nuno Lucas ------------------------------------------------------------------------ ----- To unsubscribe, send email to [EMAIL PROTECTED] ------------------------------------------------------------------------ ----- _________________________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. Dansk - Deutsch - Espanol - Francais - Italiano - Japanese - Nederlands - Norsk - Portuguese - Svenska: www.cardinalhealth.com/legal/email ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
