<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Ok, not a full answer yet, but ...<br><br>Also have a fresh svn tree, built and got similar results.<br><br>Redirected build output to a text file, copied and pasted the line compiling unitstr file to batch file. ADDED -Cpcortexm3 and rebuilt.<br><br>Disassembled the resulting object file and got:<br><br><br>stm32f103.o: file format elf32-littlearm<br><br><br>Disassembly of section .text.n_stm32f103__fpc_haltproc:<br><br>00000000 <STM32F103__FPC_HALTPROC>:<br> 0: e7fe b.n 0 <STM32F103__FPC_HALTPROC><br> 2: 46f7 mov pc, lr<br><br>Disassembly of section
.text.n_stm32f103__fpc_start:<br><br>00000000 <STM32F103__FPC_START>:<br> 0: f8df 1034 ldr.w r1, [pc, #52] ; 38 <STM32F103__FPC_START+0x38><br> 4: 4a0d ldr r2, [pc, #52] ; (3c <STM32F103__FPC_START+0x3c>)<br> 6: 4b0e ldr r3, [pc, #56] ; (40 <STM32F103__FPC_START+0x40>)<br> 8: 429a cmp r2, r3<br> a: bf9e ittt ls<br> c: f851 0b04 ldrls.w r0, [r1], #4<br>
10: f842 0b04 strls.w r0, [r2], #4<br> 14: e7f8 bls.n 8 <STM32F103__FPC_START+0x8><br> 16: 4906 ldr r1, [pc, #24] ; (30 <STM32F103__FPC_START+0x30>)<br> 18: 4a06 ldr r2, [pc, #24] ; (34 <STM32F103__FPC_START+0x34>)<br> 1a: f04f 0000 mov.w r0, #0<br> 1e: 4291 cmp r1, r2<br> 20: bf9c itt ls<br> 22: f841 0b04
strls.w r0, [r1], #4<br> 26: e7fa bls.n fffffff8 <PASCALMAIN+0xfffffff8><br> 28: f7ff bffe b.w 0 <PASCALMAIN><br> 2c: f7ff bffe b.w 0 <STM32F103__FPC_START><br> ...<br> 44: 00000048 .word 0x00000048<br> 48: 46f7 mov pc, lr<br> 4a: 46f7 mov pc, lr<br><br>This looks more like what I would expect for Thumb mode, so it's a build problem where the cpu is not getting set to Thumb2 mode when it builds the Thumb2 RTL
files.<br><br>John<br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><br><div style="font-family:arial, helvetica, sans-serif;font-size:10pt"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> David Welch <dwelch@dwelch.com><br><b><span style="font-weight: bold;">To:</span></b> FPC developers' list <fpc-devel@lists.freepascal.org><br><b><span style="font-weight: bold;">Sent:</span></b> Sun, August 21, 2011 12:24:34 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [fpc-devel] Arm Thumb2 - Stellaris status<br></font><br>
<br>thumb2 is an extension to thumb not arm, you can mix thumb and arm in T variants like the v4T v5T and anything after that v6 on up, except for the cortex-m variants which are thumb+thumb2 only and cannot execute ARM 32 bit instructions (yes thumb2 32 bit thumb extensions but nothing from the ARM instruction set).<br><br>Here is an example of the problem I am seeing:<br><br>took a clean copy from svn<br><br><span>svn co <a target="_blank" href="http://svn.freepascal.org/svn/fpc/trunk">http://svn.freepascal.org/svn/fpc/trunk</a> fpc</span><br><br>cd fpc<br><br>make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm INSTALL_PREFIX=/fpcarm<br><br><br>---- test.pp ----<br>procedure Wait(d : dword);<br> begin<br> while d<>0 do<br> dec(d);<br>end;<br><br>begin<br><br> while true do<br> begin<br> Wait($20000);<br> end;<br>end.<br>---- test.pp
----<br><br><br>./compiler/ppcrossarm -Parm -Tembedded -Wpstm32f103re -Cpcortexm3 test.pp<br>Free Pascal Compiler version 2.7.1 [2011/08/20] for arm<br>Copyright (c) 1993-2011 by Florian Klaempfl and others<br>Target OS: Embedded<br>Compiling test.pp<br>Assembling program<br>Linking test<br>/opt/embarm/arm-embedded-ld: warning: library search path "/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/" is unsafe for cross-compilation<br>14 lines compiled, 0.0 sec<br><br>then dumped the binary:<br><br>08000000 <_START-0x158>:<br> 8000000: 2000fffc strdcs pc, [r0], -ip<br> 8000004: 08000405 stmdaeq r0, {r0, r2, sl}<br> 8000008: 08000405 stmdaeq r0, {r0, r2, sl}<br> 800000c: 08000405 stmdaeq r0, {r0, r2, sl}<br> 8000010:
08000405 stmdaeq r0, {r0, r2, sl}<br> 8000014: 08000405 stmdaeq r0, {r0, r2, sl}<br> 8000018: 08000405 stmdaeq r0, {r0, r2, sl}<br>...<br>08000194 <PASCALMAIN>:<br> 8000194: 46ec mov ip, sp<br> 8000196: e92d 4800 stmdb sp!, {fp, lr}<br> 800019a: f1ac 0b04 sub.w fp, ip, #4<br> 800019e: b08a sub sp, #40 ; 0x28<br> 80001a0: f000 f844 bl 800022c <FPC_INITIALIZEUNITS><br> 80001a4: e004 b.n 80001b0
<PASCALMAIN+0x1c><br> 80001a6: bf00 nop<br> 80001a8: f44f 3000 mov.w r0, #131072 ; 0x20000<br> 80001ac: f7ff ffd8 bl 8000160 <P$PROGRAM_WAIT$LONGWORD><br> 80001b0: e7fa b.n 80001a8 <PASCALMAIN+0x14><br> 80001b2: f000 f8ff bl 80003b4 <FPC_DO_EXIT><br> 80001b6: 46dd mov sp, fp<br> 80001b8: b001 add sp, #4<br> 80001ba: e91d 8800 ldmdb sp, {fp, pc}<br> 80001be: bf00
nop<br>...<br>08000404 <STM32F103__FPC_START>:<br> 8000404: e59f103c ldr r1, [pc, #60] ; 8000448 <STM32F103__FPC_START+0x44><br> 8000408: e59f203c ldr r2, [pc, #60] ; 800044c <STM32F103__FPC_START+0x48><br> 800040c: e59f303c ldr r3, [pc, #60] ; 8000450 <STM32F103__FPC_START+0x4c><br> 8000410: e1520003 cmp r2, r3<br> 8000414: 94910004 ldrls r0, [r1], #4<br><br><br>First off 0x08000405 implies a thumb target but it is not thumb code, it is arm code so 0x08000404 would be correct but that is still wrong because cores with that vector table (cortex-m) cannot execute arm instructions.<br><br>Looking at that
first instruction in the reset handler<br><br>08000404 <STM32F103__FPC_START>:<br> 8000404: e59f103c ldr r1, [pc, #60] ; 8000448 <STM32F103__FPC_START+0x44><br><br> IPUBWL<br>1110 01011001 r15, r1, 0x03C<br><br>And that was properly decoded by objdump, immediate offset rn+offset12, load, word sized, etc.<br>PC is 0x800040C at that time so load address is 0x800040C+0x03C = 0x8000448<br><br>You can tell both by 32 bit numbers in the dump but the dominance of an 0xE as the first nibble also implies these are arm instructions not thumb (need to see a long chunk of code to see the pattern). Had they been thumb instructions but decoded wrong by the disassembler then the first and fourth nibbles would have been dominated by like 6's and 7's or at least would stand out compared to the other<br>nibbles.<br><br>if we decode this as
thumb/thumb2<br><br>0xE59F<br><br>//B(2) unconditional branch<br> if((inst&0xF800)==0xE000)<br> {<br> rb=(inst>>0)&0x7FF;<br> if(rb&(1<<10)) rb|=(~0)<<11;<br> rb<<=1;<br> rb+=pc;<br> rb+=2;<br> write_register(15,rb);<br> return(0);<br> }<br><br>1110010110011111<br><br>11100 10110011111<br><br>...11111110110011111<br>...111111101100111110<br>...11 1111 1011 0011 1110<br><br>pc = 0x405+4 = 0x409<br>pc + 0x...FFB3E =<br>0x409 - (0x4C1 + 1) = 0x7FFFF47<br><br>Unconditional branch to 0x07FFFF47 so it is a valid instruction, but doesnt make much sense<br><br><br>This does though, the start code from stm32f103.pp<br><br> .globl _start<br>
.text<br>_start:<br> <br> // Copy initialized data to ram<br> ldr r1,.L_etext<br> ldr r2,.L_data<br> ldr r3,.L_edata<br>.Lcopyloop:<br> cmp r2,r3<br> ittt ls<br> ldrls r0,[r1],#4<br> strls r0,[r2],#4<br> bls .Lcopyloop<br><br>The instructions the assembler was able to encode it did:<br><br> 8000404: e59f103c ldr r1, [pc, #60]<br> 8000408: e59f203c ldr r2, [pc, #60]<br> 800040c: e59f303c ldr r3, [pc, #60]<br> 8000410: e1520003 cmp r2, r3<br> 8000414: 94910004 ldrls r0, [r1], #4<br>....<br>
8000448: 08000468 stmdaeq r0, {r3, r5, r6, sl}<br> 800044c: 20000000 andcs r0, r0, r0<br> 8000450: 20000048 andcs r0, r0, r8, asr<br><br><br>0x08000468 is the word aligned address for the end of the text segment and 0x20000000 the beginning of text for this example so that is correct as well.<br><br>and interestingly the ittt ls instruction is discarded.<br><br>The code from stm32f103.pp<br><br> ldr r1,.L_etext<br> ldr r2,.L_data<br> ldr r3,.L_edata<br>.Lcopyloop:<br> cmp r2,r3<br> ittt ls<br> ldrls r0,[r1],#4<br> strls r0,[r2],#4<br> bls .Lcopyloop<br><br>when assembled should look like this<br><br>00000000 <.text>:<br> 0: 4904
ldr r1, [pc, #16] ; (14 <.text+0x14>)<br> 2: 4a05 ldr r2, [pc, #20] ; (18 <.text+0x18>)<br> 4: 4b05 ldr r3, [pc, #20] ; (1c <.text+0x1c>)<br> 6: 429a cmp r2, r3<br> 8: bf9e ittt ls<br> a: f851 0b04 ldrls.w r0, [r1], #4<br> e: f842 0b04 strls.w r0, [r2], #4<br> 12: e7f8 bls.n 6 <.text+0x6><br>
14: 00000001 andeq r0, r0, r1<br> 18: 00000002 andeq r0, r0, r2<br> 1c: 00000003 andeq r0, r0, r3<br><br>with different addresses of course...when assembled for thumb.<br><br>So it doesnt look like that is happening<br><br>Pascal main is definitely thumb+thumb2.<br><br>08000194 <PASCALMAIN>:<br> 8000194: 46ec mov ip, sp<br> 8000196: e92d 4800 stmdb sp!, {fp, lr}<br> 800019a: f1ac 0b04 sub.w fp, ip, #4<br> 800019e: b08a sub sp, #40 ; 0x28<br><br>More info about my setup:<br><br>svn info<br><br><span>
URL: <a target="_blank" href="http://svn.freepascal.org/svn/fpc/trunk">http://svn.freepascal.org/svn/fpc/trunk</a></span><br><span>Repository Root: <a target="_blank" href="http://svn.freepascal.org/svn/fpc">http://svn.freepascal.org/svn/fpc</a></span><br>Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2<br>Revision: 18278<br>Node Kind: directory<br>Schedule: normal<br>Last Changed Author: florian<br>Last Changed Rev: 18278<br>Last Changed Date: 2011-08-19 18:06:52 -0400 (Fri, 19 Aug 2011)<br><br>Ubuntu 10.4 or something like that 64 bit host.<br>Linux dwelch-desktop 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 x86_64 GNU/Linux<br><br>fpc is what you apt-get so probably a little behind but stable in the eyes of ubuntu or debian.<br><br> fpc<br>Free Pascal Compiler version 2.4.0-2ubuntu1.10.04 [2011/06/17] for x86_64<br>Copyright (c) 1993-2009 by Florian Klaempfl<br>/usr/lib/fpc/2.4.0/ppcx64 [options] <inputfile>
[options]<br>Put + after a boolean switch option to enable it, - to di<br><br>GNU assembler (Sourcery G++ Lite 2011.03-42) 2.20.51.20100809<br>Copyright 2010 Free Software Foundation, Inc.<br>This program is free software; you may redistribute it under the terms of<br>the GNU General Public License version 3 or later.<br>This program has absolutely no warranty.<br>This assembler was configured for a target of `arm-none-eabi'.<br><br><br><br><br>So what did I do wrong? and what is the unsafe thing about?<br><br>Thanks,<br>David<br><br><br><br>On 08/20/2011 11:23 AM, Jeppe Gręsdal Johansen wrote:<br>> Den 20-08-2011 16:46, David Welch skrev:<br>>> I was hoping for thumb support but I now see that the choices are<br>>> limited to arm and thumb+thumb2 (without any separation between thumb<br>>> and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2<br>>> mix, so I will ride this along for a while and see
what comes up,<br>>> otherwise limit my use to ARM targets, or start working on a thumb<br>>> backend. Adding backends as well as arm embedded are of interest to me<br>>> so I may work on a little of both.<br>> Why thumb support? The choices are indeed currently only either ARM or<br>> Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length<br>> instruction set that looks like an arm+thumb mix, so I guarantee you<br>> that it works :)<br>> _______________________________________________<br>> fpc-devel maillist - <a ymailto="mailto:fpc-devel@lists.freepascal.org" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><span>> <a target="_blank" href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a></span><br>> .<br><br>_______________________________________________<br>fpc-devel maillist - <a
ymailto="mailto:fpc-devel@lists.freepascal.org" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br><a href="http://lists.freepascal.org/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a><br></div></div>
</div></body></html>