|
sl@0
|
1 |
The cryptography libraries should not build thumb.
|
|
sl@0
|
2 |
|
|
sl@0
|
3 |
On EKA1 they cannot build on thumb because the long long support files (supplied by base) contain instructions that are not supported on that platform. This has the knock-on effect that those components that include bigint code in their build (and thus require the long long support files too) also cannot build thumb. The entire list of components affected is as follows:
|
|
sl@0
|
4 |
|
|
sl@0
|
5 |
the cryptography library cryptography.dll
|
|
sl@0
|
6 |
tasn1 (use CopyL, operator ==, operator < and operator *=)
|
|
sl@0
|
7 |
tx509, twtlscert (both use operator < and > which are not exported from TInteger)
|
|
sl@0
|
8 |
|
|
sl@0
|
9 |
|
|
sl@0
|
10 |
On EKA2 it should not build thumb either, because it has been deemed to be too slow.
|
|
sl@0
|
11 |
|
|
sl@0
|
12 |
Thus the cryptography library must be built on the ARMi platform to substitute for the thumb binary where a thumb set of binaries is required (eg for Lubbock roms). The ARMi build should occur first in the build order. To speed up the build process, I've stopped our testcode building ARMi where it's not required to do so.
|
|
sl@0
|
13 |
|
|
sl@0
|
14 |
Some information (from Chris Mokes) about how to prevent the cryptography library building on thumb, and how to manage ROM building follows:
|
|
sl@0
|
15 |
|
|
sl@0
|
16 |
|
|
sl@0
|
17 |
(a) To stop thumb being built do this in the PRJ_MMPFILES section of bld.inf
|
|
sl@0
|
18 |
|
|
sl@0
|
19 |
#if !defined(MARM_THUMB)
|
|
sl@0
|
20 |
mmpfilename
|
|
sl@0
|
21 |
#endif
|
|
sl@0
|
22 |
|
|
sl@0
|
23 |
or I think you can specify -THUMB in bld.inf but that'll stop everything being build for thumb.
|
|
sl@0
|
24 |
|
|
sl@0
|
25 |
|
|
sl@0
|
26 |
(b) You need to build the dll for ARMI, but still build a thumb lib file for thumb binaries which use the dll to be linked with. Thumb and armi dlls are interchangable, armi code linked with the armi lib can call exports in a thumb dll and the other way around.
|
|
sl@0
|
27 |
|
|
sl@0
|
28 |
As you've seen the rombuild downgrades to armi if the thumb binary isn't present., so if you have built the armi version and not the thumb one it will pick up the correct one.
|
|
sl@0
|
29 |
|
|
sl@0
|
30 |
Euser has its own define EUSER_ABI in the rombuilding scripts. EUSER_ABI is ARM4 in an ARM4 build and ARMI for thumb and armi builds.
|
|
sl@0
|
31 |
|
|
sl@0
|
32 |
The nicest solution is to add to epoc32\rom\include\header.iby to define a CRYPTO_ABI which will be basically the same as the euser one.
|
|
sl@0
|
33 |
|
|
sl@0
|
34 |
Thus,
|
|
sl@0
|
35 |
|
|
sl@0
|
36 |
header.iby
|
|
sl@0
|
37 |
<snip>
|
|
sl@0
|
38 |
#ifdef _ARM4
|
|
sl@0
|
39 |
define DESIRED_ABI ARM4
|
|
sl@0
|
40 |
define EUSER_ABI ARM4
|
|
sl@0
|
41 |
define ELOCL_ABI ARM4
|
|
sl@0
|
42 |
define CRYPTO_ABI ARM4
|
|
sl@0
|
43 |
#endif
|
|
sl@0
|
44 |
|
|
sl@0
|
45 |
#ifdef _ARMI
|
|
sl@0
|
46 |
define DESIRED_ABI ARMI
|
|
sl@0
|
47 |
define EUSER_ABI ARMI
|
|
sl@0
|
48 |
define ELOCL_ABI ARM4
|
|
sl@0
|
49 |
define CRYPTO_ABI ARMI
|
|
sl@0
|
50 |
#endif
|
|
sl@0
|
51 |
|
|
sl@0
|
52 |
#ifdef _THUMB
|
|
sl@0
|
53 |
define DESIRED_ABI THUMB
|
|
sl@0
|
54 |
define EUSER_ABI ARMI
|
|
sl@0
|
55 |
define ELOCL_ABI ARM4
|
|
sl@0
|
56 |
define CRYPTO_ABI ARMI
|
|
sl@0
|
57 |
#endif
|
|
sl@0
|
58 |
<snip>
|
|
sl@0
|
59 |
|
|
sl@0
|
60 |
|
|
sl@0
|
61 |
Then use CRYPTO_ABI rather than ABI_DIR in cryptalg.iby.
|
|
sl@0
|
62 |
|
|
sl@0
|
63 |
So, the simplest way is the just build armi and arm4 and the armi one will be downgraded to in a thumb rom. This is the situation at present. The most complex but best is to use the define CRYPTO_ABI as explained above. This cannot be done until the cryptography libraries are submitted to the build and the Master Codeline accepts divergence from 7.0s release.
|