Index
> Non-x86 architectures > FASMARM v1.44 - Cross assembler for ARM CPUsGoto page Previous 1, 2, 3 ... 22, 23, 24 ... 31, 32, 33 Next |
| Author |
|
|
revolution 11 Jul 2012, 05:07
cwpjr wrote: I have fasm working in a FASM directory on my pc running Ubuntu. I downloaded and unzipped the FASMARM full zip to FASM/FARM directory. The linux executables (ex: ARMELF) don't run. Is this because of ubuntu? den_po wrote: error: value out of range. |
|||
11 Jul 2012, 05:07 |
|
|
revolution 11 Jul 2012, 05:29
Version 1.28 now available:
Quote: v1.28 2012-Jul-11 |
|||
|
11 Jul 2012, 05:29 |
|
|
MSimon 29 Aug 2012, 12:30
revolution wrote: It has always been a personal interest of mine to build small CPU boards for various things. Later it evolved into building high-performance and low-power computing platforms (with ARM of course, x86 can't do it) in my job. But fasmarm is 100% my personal project. I now use it in my job but it has never been my job to write or update it. I have never received any remuneration of any kind for fasmarm. I will never ask for donations. I will never post advertisements on the webpage. It will be free forever. Thanks for all you have done. In return you might like this for making boards: http://www.ecnmag.com/blogs/2012/04/beauty _________________ Engineering is the art of making what you want from what you can get at a profit. |
|||
|
29 Aug 2012, 12:30 |
|
|
malpolud 30 Aug 2012, 19:39
I've got a question concerning code placement in the memory. I want my code to appear in certain place in memory. First of all I use org directive. Manual says:
Quote: org directive sets address at which the following code is expected to appear in memory. It should be followed by numerical expression specifying the address. This directive begins the new addressing space, the following code itself is not moved in any way, but all the labels defined within it and the value of $ symbol are affected as if it was put at the given address. However it's the responsibility of programmer to put the code at correct address at run-time. So all org does is adjusting the labels in the code. To place the code in the right place in the memory I can either compile a binary file and while writing to memory tell the device where the code should appear or I can place format elf directive in the source file, compile the code to an object file and then link the object file telling the linker where I want my code to appear. The liker outputs a nice elf file which I can write with my device without telling where particular code should be placed. Is there a way to do the above with some directive? I mean compile with FASMARM to an elf file with right code placing as raw bin file does not contain information about code location. E: Does this sentence explain it all? Quote: Relocations for ELF and PE are not supported at this time. _________________ There's nothing special about it, It's either there when you're born or not. |
|||
|
30 Aug 2012, 19:39 |
|
|
revolution 31 Aug 2012, 00:25
With x86 we can do this:
Code: mov eax,[absolute_address] Instead it is common to do one of two things: Code: ldr r1,[pc+offset_to_the_data] ;method one, requires no relocation Code: ldr r0,[pc+offset_to_the_pointer] ldr r1,[r0] ;read the data ;... pointer dw absolute_address_of_the_data ;method two, requires relocation With method one above the offset is limited to +/-4096 bytes in ARM mode and +4096/-256 in Thumb mode. This can be extended by doing the following: Code: movw r0,offset_to_the_data and 0xffff movt r0,offset_to_the_data shr 16 ldr r1,[pc,r0] ;requires no relocation malpolud wrote: E: Does this sentence explain it all? Last edited by revolution on 31 Aug 2012, 10:09; edited 1 time in total |
|||
|
31 Aug 2012, 00:25 |
|
|
malpolud 31 Aug 2012, 10:01
Thank you for your wide reply. I guess I messed here a little. What I really meant is in fact relocation (after: http://en.wikipedia.org/wiki/Relocation_(computer_science) ) What I wanted to achieve is an elf file with sections assigned to specified memory regions. Previously I did it by linking the object elf file and the linker did it.
I just achieved the job by putting Code: format elf dwarf executable ;config code here section ".text" readable executable at 8000000h align 4 And it seems that the section was relocated properly. (please correct me if I am wrong) The file works brilliant - non OS device. I would like to test relocation in an elf file on OS running ARM device, could you please give me some tips? Basically do I just want to compile an elf file similarly to the file above? FASMARM rejects combinations of Code: format elf executable ;and section ".text" readable executable By the way thank you revolution for FASMARM, its marvelous. Edit by revolution: Fixed URL _________________ There's nothing special about it, It's either there when you're born or not. |
|||
|
31 Aug 2012, 10:01 |
|
|
revolution 31 Aug 2012, 10:21
section is only valid for DWARF format. Try with segment instead.
|
|||
|
31 Aug 2012, 10:21 |
|
|
malpolud 31 Aug 2012, 10:35
With:
Code: format elf executable segment readable executable It compiles, but no address (relocation) of segment and no name can't be specified. |
|||
|
31 Aug 2012, 10:35 |
|
|
revolution 31 Aug 2012, 23:06
It might take some lengthy time for me to figure this out. I have no idea what I am doing with regard to ELF format and sections/segments.
|
|||
|
31 Aug 2012, 23:06 |
|
|
malpolud 01 Sep 2012, 05:55
Well how it works now is perfectly fine for me. My debugger supports elf dwarf, and that is all I need. I was just curious if this is possible.
|
|||
|
01 Sep 2012, 05:55 |
|
|
revolution 01 Sep 2012, 09:33
From what I have read about with regard to the ELF formats it seems that the sections are supposed to be for non-binary purposes; things like debug information, symbol tables, relocations, line numbers and other meta-data related to linking and loading but generally not used at runtime by the code. And segments are supposed for the executable code, initialised data, string tables and other runtime related things.
So what fasmarm does with the section directive is probably going against the original intention of the word because it is actually generating a segment. And perhaps this is what is causing the confusion. Since the actual section information is generated automatically by fasmarm and not controllable directly from the source I think that it might be prudent to completely merge the section and segment directives and make them do the same thing for all of the output formats; elf, elf executable and elf dwarf. That way all of the source code definable attribute definitions would be the same across all output formats. And specifying either the section or segment directives will just generate a segment in the output and the sections in the output will still be generated automatically. I hope that made sense. If I get some time in the next few days I will look into more details about whether merging it all into a common directive is sensible, or whether there is something that I missed that somehow forces me to look into another solution. |
|||
|
01 Sep 2012, 09:33 |
|
|
malpolud 03 Sep 2012, 08:56
Thank you for your attention rev
Well regarding to DWARF, section works at least partially as section for the ELF format with the proper naming. The section was created, the debugging information (relocation) was attached to the section of the file as intended. Segment for the ELF file works as well at least partially properly according to the naming. We can define whether the part of the binary code is supposed to be readable, writable or executable. In my opinion the way it works now is good, optionally adding section functionality for elf format would be desirable for me. I have some free time now, it's time to start reading FASMARM source  |
|||
|
03 Sep 2012, 08:56 |
|
|
revolution 24 Dec 2012, 03:12
Version 1.29 now available:
Quote: v1.29 2012-Dec-24 |
|||
|
24 Dec 2012, 03:12 |
|
|
cwpjr 20 Feb 2013, 02:23
Thanks Revolution. In using other to be uinamed tools their advice for symbol files I could use for debugging referenced Gnu binutils ReadElf yet the tool only output .axf.
IDE cover up crap yah know. Clyde _________________ Developing ARM Electronic Hobby Bench Stuff! |
|||
|
20 Feb 2013, 02:23 |
|
|
revolution 22 Feb 2013, 06:07
cwpjr: I don't get your meaning there. What is "uinamed tools"? Are you asking a question or suggesting some advice?
|
|||
|
22 Feb 2013, 06:07 |
|
|
Nukster2 27 Aug 2013, 07:27
Hi there,
I'm new to ARM assembler but I think there's a problem with LDRB, LDRH, STRB and STRH instructions in FASMARM 1.29: If I assemble the following source file: Code: locFeatureActivationCode equ 0119180h format ELF dwarf executable at 0 entry CheckFeatureActivation section 'one' executable readable writeable align 02h at locFeatureActivationCode ; Constants for Firmware 1.05 StackStart equ 010h StackFlag equ StackStart + 4h thumb CheckFeatureActivation: LDRB R0, [SP, StackFlag] STRB R0, [SP, StackFlag] LDRH R0, [SP, StackFlag] STRH R0, [SP, StackFlag] with "FASMARM SOURCEFILE.ASM" and disassemble the result with IDA pro in thumb mode, the result seems to be incorrect: Code: LOAD:00119180 ; --------------------------------------------------------------------------- LOAD:00119180 ; File Name : D:\xxx\SOURCEFILE.ASM LOAD:00119180 ; Format : ELF for ARM (Executable) LOAD:00119180 ; Imagebase : 119180 LOAD:00119180 ; LOAD:00119180 ; Options : EF_ARM_APCS_FLOAT LOAD:00119180 ; EABI version: 2 LOAD:00119180 ; LOAD:00119180 LOAD:00119180 ; Processor : ARM LOAD:00119180 ; Target assembler: Generic assembler for ARM LOAD:00119180 ; Byte sex : Little endian LOAD:00119180 LOAD:00119180 ; =========================================================================== LOAD:00119180 LOAD:00119180 ; Segment type: Pure code LOAD:00119180 AREA LOAD, CODE, READWRITE, ALIGN=1 LOAD:00119180 ; ORG 0x119180 LOAD:00119180 CODE16 LOAD:00119180 LOAD:00119180 EXPORT start LOAD:00119180 start LOAD:00119180 09 98 LDR R0, [SP,#0x14] LOAD:00119182 09 90 STR R0, [SP,#0x14] LOAD:00119184 09 98 LDR R0, [SP,#0x14] LOAD:00119186 09 90 STR R0, [SP,#0x14] LOAD:00119186 ; LOAD ends LOAD:00119186 LOAD:00119186 END start It looks like LDRB is encoded as LDR, STRB is encoded as STR, LDRH is encoded as LDR, STRH is encoded as STR, which results in a loss of the operand size. Is there anything I'm doing wrong ? |
|||
|
27 Aug 2013, 07:27 |
|
|
revolution 12 Sep 2013, 10:42
Nukster2 wrote: LDRB is encoded as LDR, I will upload a fix shortly. |
|||
|
12 Sep 2013, 10:42 |
|
|
revolution 12 Sep 2013, 12:24
Version 1.30 now available:
Quote: v1.30 2013-Sep-12 |
|||
|
12 Sep 2013, 12:24 |
|
|
Nukster2 16 Sep 2013, 00:04
revolution wrote: ...You are correct, it is a bug. Thank you very much! |
|||
|
16 Sep 2013, 00:04 |
|
| Goto page Previous 1, 2, 3 ... 22, 23, 24 ... 31, 32, 33 Next < Last Thread | Next Thread > |
Forum Rules:
|