Index
> Non-x86 architectures > FASMARM v1.44 - Cross assembler for ARM CPUsGoto page Previous 1, 2, 3 ... 27, 28, 29 ... 31, 32, 33 Next |
| Author |
|
|
Andrew Martin 06 Dec 2015, 12:24
Line number program:
Code: Special opcode 26: advance Address by 4 to 0x130 and Line by 2 to 168 Advance PC by 536870608 to 0x20000000 Special opcode 2: advance Address by 0 to 0x20000000 and Line by 2 to 170 Advance PC by 4 to 0x20000004 Extended opcode 1: End of Sequence Address 0x20000000 is in section ".data", which have only WRITE|ALLOCATE access, but no EXECUTE access. Maybe it does not matter. |
|||
06 Dec 2015, 12:24 |
|
|
revolution 06 Dec 2015, 15:02
I haven't made it look at the section attributes when defining the line numbers. I didn't see anywhere in the DWARF spec that talks about only numbering executable code, perhaps it is simply assumed or implied.
BTW: I also number the "section ..." lines since they also produce output data. But I don't number the "format ..." line. |
|||
|
06 Dec 2015, 15:02 |
|
|
Andrew Martin 06 Dec 2015, 16:02
There is no sense in the line numbering in data sections. It is necessary to link PC with line numbers in source code for step-by-step debug. In non-executable sections, address value in LNP is not the same as that PC.
Besides, in that executable, size of section ".data" = 0. |
|||
|
06 Dec 2015, 16:02 |
|
|
revolution 11 Apr 2016, 01:05
Version 1.38 now available:
Quote: v1.38 2016-Apr-11 |
|||
|
11 Apr 2016, 01:05 |
|
|
revolution 01 May 2016, 03:28
Version 1.39 now available:
Quote: v1.39 2016-May-01 For those interested in the 64-bit v8 instructions, ARM have a freely available document [ARM Cortex-A Series Programmer's Guide for ARMv8-A] with some useful information. [PDF is here] |
|||
|
01 May 2016, 03:28 |
|
|
krom 12 May 2016, 15:50
Hi revolution,
I just got the newest FASMARM with aarch64 support, but when I tried using the new instructions I get an error: "Error: Requires CPU64 capability V8, use direct" I am using both CODE64 & PROCESSOR CPU64_V8, I tried swapping the order of them, outputing to binary format. Also I tried compiling your EXAMPLES\ARM64\SemiHosting.asm file, but it gives the same error as above. I am using the windows FASMWARM.EXE binary from FASMARM_full.ZIP on Windows 10. Hope this helps, also thanks for the free ARM v8 pdf doc you linked. |
|||
|
12 May 2016, 15:50 |
|
|
revolution 13 May 2016, 00:01
Cannot reproduce:
Code: flat assembler for ARM version 1.39 (built on fasm 1.71.51) (3145344 kilobytes memory) 2 passes, 215 bytes. Your error message is truncated also, the full message should be "Requires CPU64 capability V8, use directive "processor" to select". |
|||
|
13 May 2016, 00:01 |
|
|
krom 13 May 2016, 09:41
Hi revolution, thanks for the quick response.
revolution wrote: Cannot reproduce I used the IDE FASMWARM.EXE once again to navigate to the EXAMPLES\ARM64\SemiHosting.asm file, & pressed the Run/Compile button & I got the same truncated error message. I then tried copying the SemiHosting.asm file into the root directory, where the command line FASMARM.EXE is, & used that to correctly compile the file, so it seems to be a problem with the IDE FASMWARM on Windows 10. revolution wrote: Your error message is truncated also, the full message should be "Requires CPU64 capability V8, use directive "processor" to select". As I can use the command line FASMARM to compile aarch64 now I am very happy, but would love for the IDE to work as it really speeds up my workflow. Anyway I hope this helps, sorry about the weirdness of this IDE bug in windows 10... P.S I also made sure to check I do not have any other FASMARM.EXE files on my hard-disk, so it is not picking up another executable from anywhere else... Last edited by krom on 13 May 2016, 10:27; edited 1 time in total |
|||
|
13 May 2016, 09:41 |
|
|
revolution 13 May 2016, 10:18
krom: Thank you for the report. I will look into the IDE problem.
|
|||
|
13 May 2016, 10:18 |
|
|
revolution 14 May 2016, 09:19
Version 1.40 now available:
Quote: v1.40 2016-May-14 |
|||
|
14 May 2016, 09:19 |
|
|
krom 14 May 2016, 11:08
Thanks revolution this new FASMARM v1.40 fixes all the IDE compilation problems I was having.
I'll have a lot of fun with this, great work =D |
|||
|
14 May 2016, 11:08 |
|
|
revolution 24 May 2016, 10:48
Relocations with ELF and ELF64
Looking for suggestions on how to specify relocation information for ELF and ELF64 output formats. Compared to x86 output there are a number of differences related to relocations. For simple things like a memory location using DW or DD there is no problem, but some instruction sequences require very specific information to be forwarded to the linker to correctly resolve the final address. The GNU assembler, AS, simply uses a variant of the link info internal name to specify the required relocation information. For example for 64-bit code we have this for a 48-bit address: Code: movz x1,:abs_g2:foo movk x1,:abs_g1_nc:foo movk x1,:abs_g0_nc:foo Code: adrp x1,:pg_hi21:foo add x1,x1,:lo12:foo Code: adrp x1,:pg_hi21:foo ldr x1,[x1,:lo12:foo] Code: movw r0,:lower16:foo movt r0,:upper16:foo For fasmarm I didn't want to start using such specific linker internal names because they are unintuitive and hard to remember, and I especially wanted to avoid the usage of the colons (:) and underscores (_) because they are tedious to type. My current thinking could be something like this: 64-bit absolute: Code: movz x1,quarter3 foo ;no overflow check needed for 64-bit movk x1,quarter2 foo ;no overflow check movk x1,quarter1 foo ;no overflow check movk x1,quarter0 foo ;no overflow check Code: movz x1,quarter2 foo ;overflow check movk x1,quarter1 foo ;no overflow check movk x1,quarter0 foo ;no overflow check Code: movz x1,quarter1 foo ;overflow check movk x1,quarter0 foo ;no overflow check Code: movz x1,quarter0 foo ;overflow check Code: adrp x1,foo ;overflow check add x1,x1,lower12 foo ;no overflow check Code: movw r1,half1 foo movt r1,half0 foo Using a single instruction to get a PC relative address: Code: adr r1,foo ;automatic overflow check Code: adr r1,half1 foo ;no overflow check add r1,half0 foo ;overflow check Code: adr r1,third2 foo ;no overflow check add r1,third1 foo ;no overflow check add r1,third0 foo ;overflow check The usage of quarter* can be used in thumb-16 code to produce the thumb specific absolute addresses: Code: add/mov r1,quarter3 foo ;overflow check add/mov r1,quarter2 foo ;no overflow check add/mov r1,quarter1 foo ;no overflow check add/mov r1,quarter0 foo ;no overflow check |
|||
|
24 May 2016, 10:48 |
|
|
l_inc 24 May 2016, 13:09
revolution
Did you have a look at the actual specifications? Base spec., ARM supplement, ARMv8 supplement . These define the r_info field and possible values for the ELF32_R_TYPE and ELF64_R_TYPE subfields, which seem to cover all the possible relocation requirements. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
24 May 2016, 13:09 |
|
|
revolution 24 May 2016, 13:24
Yes of course, but how to represent them in assembly code? Do you think I should use the same as AS? Or something else?
|
|||
|
24 May 2016, 13:24 |
|
|
l_inc 24 May 2016, 13:34
revolution
Oh, then it seems, I misunderstood the question. It's not about forwarding the information to the linker. It's about telling the translator what kind of relocation one needs. I think this information should not be explicitly specified, but rather derived from the expressions applied to the corresponding relocatable label. E.g., when you do movw r0,foo and $FFFF then the result of the expression foo and $FFFF still keeps the relocatability property. I guess you need significant improvements to the expression calculator though, but that's the correct way to do that. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
24 May 2016, 13:34 |
|
|
revolution 24 May 2016, 13:41
The problem is that the programmer needs to tell the assembler how many instructions to generate. Do you know that all of your addresses are less than <some number> of bits? If so then you might be able to always use only two instructions to get your address. And then you have to tell the assembler (and subsequently the linker) to compute addresses with a particular limit and error if something goes outside that range.
Basically there is no way for the assembler to know the full intent unless you tell it. Does "ADD r1,r1,my_address" mean you want the second, or the third, set of significant bits encoded? |
|||
|
24 May 2016, 13:41 |
|
|
revolution 24 May 2016, 13:44
BTW: It is not possible to say "foo and 0xffff" for a relocatable label. That value is unknown as assembly time. And for things like "ADR r1,foo", which bits would you mask? 0xff0000? 0xff00? 0x3fc000? There are a number of possibilities and the values change depending upon the actual address at link time.
|
|||
|
24 May 2016, 13:44 |
|
|
l_inc 24 May 2016, 14:15
revolution
Quote: And then you have to tell the assembler (and subsequently the linker) If I understand you correctly, the linker has nothing to do with the decision. It just evaluates the r_info field: the decision how to construct the field (or a multiple of them) has already been made by the translator and/or programmer. Quote: Does "ADD r1,r1,my_address" mean you want the second, or the third, set of significant bits encoded? add r1,r1,my_address means all of the bits of my_address must be preserved, which is not encodeable in general for a relocatable label. What you can do is to remove the relocatability property from some bits by applying an appropriate expression to the address. Quote: BTW: It is not possible to say "foo and 0xffff" for a relocatable label. That value is unknown as assembly time. Sure it's not known. That's why we have fixups. But the relocatable labels can still be calculated with. Current fasm's expression calculator can do a limited subset of calculations, and you need to extend it to be able to calculate with partially relocatable values. That means allowing for bitwise operators as well. Quote: And for things like "ADR r1,foo", which bits would you mask? 0xff0000? 0xff00? 0x3fc000? I guess it depends on how many instructions you use to encode the address. It's up to the programmer and the constraints the programmer expects for the address to satisfy. Quote: the values change depending upon the actual address at link time In many cases upon the actual address at load or even runtime actually. But it doesn't prevent you from calculating with the relocatable values, which is what fasm already does by allowing for addition and subtraction, and with registers even multiplication: Code: dd foo+0x100+ebx*3-(bar-foo+ebx-0x10)*2-ebx This will perfectly compile even though you don't know the value of ebx and the relocatable labels foo and bar at runtime, right? _________________ Faith is a superposition of knowledge and fallacy |
|||
|
24 May 2016, 14:15 |
|
|
revolution 24 May 2016, 14:34
Hmm, the linker has a limited set of things it can do. For example we cannot instruct it to use a fixed set of bits of our choosing for ARM32 ADR/ADD. It uses "smart" algorithms to create the address with value dependant bitmasks. So the assembler has to work within those constraints. So, no, we can't actually pre-compute anything. We only have the option to tell the linker that a particular instruction needs a set of bits that come from a sequence the linker decides based upon the value only it knows. The best the assembler can do is tell the linker a particular instruction is the first, or subsequent, instruction, in a sequence. And the sequence doesn't even have to be in order, the linker just accepts it as given one instruction at a time without any notion of connecting it to another instruction either before or after. That allows us some flexibility so we could use the final stage values multiple times from a pre-loaded register and the linker doesn't care. Also note that the linker can change ADD to SUB and the assembler has no control over that.
Since using fixed bitmasks cannot work, I think there needs to be another solution. So, what is your opinion? Is the AS way the way to go (with its colons and underscores)? Or perhaps what I suggested above? |
|||
|
24 May 2016, 14:34 |
|
| Goto page Previous 1, 2, 3 ... 27, 28, 29 ... 31, 32, 33 Next < Last Thread | Next Thread > |
Forum Rules:
|