flat assembler
Message board for the users of flat assembler.
Index
> Macroinstructions > How to get the address in something passed? Goto page Previous 1, 2, 3 Next |
Author |
|
Borsuc 21 Dec 2009, 23:16
Actually you can use a combination of the two versions:
Code: rept 1 { local lst,n define lst + macro whatever num \{ match x,lst \\{ restore lst define lst x num \\} \} macro ending \{ match +list__, lst \\{ n=0 irps l, list__ \\\{ if l < 1000 store dword l at list+n*4 n=n+1 end if \\\} list_length = n \\} \} } whatever 5 list dd list_length dup (0) whatever 6 whatever 1007 ending I suggest you use this because it's the most flexible and you can put the list anywhere, even between macros used... the 'ending' macro does the job of going through the created list and putting the values in the list. Also list_length is defined at the end only once, so it is used in the second pass (this uses FASM's multi-pass capabilities). |
|||
21 Dec 2009, 23:16 |
|
Azu 22 Dec 2009, 04:06
Thank you!
I am using the first way, so that I only need one list (it isn't the value of the operand that I am storing, but rather the address it is at, so I can add the base address to it). With the second one I would need to store both the value and the address it is at, so it would take more memory to compile. Soon I will have macros for every instruction to make them all relocatable automatically. This really beats putting in the addresses manually. |
|||
22 Dec 2009, 04:06 |
|
Borsuc 22 Dec 2009, 22:56
ah yes I'm usually not thinking about memory because I never had problems with it or with speed in FASM.
also I agree about doing it automatically, in fact, I love FASM's powerful macro capabilities... since I learned FASM (long time ago) I've never inputted anything manually (like offsets or other calculations). |
|||
22 Dec 2009, 22:56 |
|
baldr 23 Dec 2009, 13:37
Azu,
Back to the starting problem: FASM can itself help to extract displacement from address (try this with match ): Code: macro get_ea_disp addr, disp { virtual at 0 lea eax, addr load ModRM byte from 1 M = (ModRM shr 6) and 3 if M=1 load disp byte from $-1 else if (M=2) | ((M=0) & ((ModRM and 7)=5)) load disp dword from $-4 end if end virtual } ; Example: ; ecx is scaled index into array of STRUCT, FIELD1 is array of 8-byte SUBSTRUCTs ; and we need most significant byte of FIELD2 get_ea_disp [array+ecx+STRUCT.FIELD1+edx*8+SUBSTRUCT.FIELD2+3], disp |
|||
23 Dec 2009, 13:37 |
|
Borsuc 23 Dec 2009, 16:20
But what you used are assembly-time directives not pre-processor like match... he can't build a list with that.
BTW nice trick _________________ Previously known as The_Grey_Beast |
|||
23 Dec 2009, 16:20 |
|
baldr 23 Dec 2009, 18:54
Borsuc,
My solution is based on topic's starting post (anyone remembers it? with ifs and reference to eqtype). Azu, Not every imm (and disp in r/m) is relocatable item, right? The best you can do (apart from rewriting entire FASM assembly stage in FASM directives' language ) is compile to COFF and parse it for relocations. |
|||
23 Dec 2009, 18:54 |
|
Azu 23 Dec 2009, 21:43
baldr wrote: Azu, Thanks baldr. I don't need to change offsets into arrays though. They should be the same wherever the code is located. Or did I misunderstand your post? baldr wrote: Azu, But if it is COFF then it won't run. Won't I have to manually take additional steps? I want a solution that FASM can do on it's own (which so far Borsuc's way is successful in, although it's more difficult making macros for all instructions than I thought it would be). Or is there a way to keep making my file the way I am now and just have the COFF output into a virtual directive and load the list from there? |
|||
23 Dec 2009, 21:43 |
|
baldr 23 Dec 2009, 22:32
Azu,
That macro extracts 56 from something like dword[56], [ecx+56] or [50+ecx*8+6]. I thought this is what you're trying to accomplish. The example was given to demonstrate it's ability to handle complex address expressions (indeed FASM handles them ). Somewhere in the thread you'd mentioned automatic relocation, thus I deduced that you're going to create list of all relocatable items in code. Not a simple task, I think. Maybe if you provide more details about your problem... |
|||
23 Dec 2009, 22:32 |
|
Azu 23 Dec 2009, 23:18
Thanks.
Yes, that is what I am trying to do. I want to store their addresses in a list that I can loop through and add it to. The method you posted will be helpful for making sure the memory operands are within the right range. Using just Borsuc's way I couldn't check ones with register offsets (or at least not very easily). I still need to find a way to tell what address should be added to the list though. With the different offsets the size of the instruction is different so what I'm doing now is trying to special case all the ones I use. |
|||
23 Dec 2009, 23:18 |
|
Borsuc 23 Dec 2009, 23:36
Just wondering (nothing to do with either method) do you modify the instruction offsets at runtime or...?
|
|||
23 Dec 2009, 23:36 |
|
baldr 24 Dec 2009, 00:47
Azu,
FASM provides data fixups directive which inserts base relocation table into output file. Warning: FASM also fills corresponding entry in PE data directory, so if you tamper that table, PE probably will be garbled or won't load at all. virtual won't help either, relocation table will be absent in PE but directory entry still filled. This is applicable only in case loader needs that table. |
|||
24 Dec 2009, 00:47 |
|
Tomasz Grysztar 24 Dec 2009, 08:53
fasm really lacks a feature that would allow to manually generate relocation with "format binary". I was planning such thing almost since the begining, but I was never able to come out with some nice syntax solution for it.
|
|||
24 Dec 2009, 08:53 |
|
Azu 24 Dec 2009, 08:57
Borsuc wrote: Just wondering (nothing to do with either method) do you modify the instruction offsets at runtime or...? I have a block of code that needs to run anywhere and it was really annoying making a list by hand of the addresses that needed to be modified. baldr wrote: Azu, Tomasz Grysztar wrote: fasm really lacks a feature that would allow to manually generate relocation with "format binary". I was planning such thing almost since the begining, but I was never able to come out with some nice syntax solution for it. I don't use any of the format macros, I have my own macros to make the file. So I can make it smaller. You say there isn't a way to do it with format so that means there is a way to do it without? Please tell me how.. p.s. Will it work for stuff in virtual directives in my block of code? Or I will have to keep handling those myself? Like e.g. Code: code that doesn't need relocated beginPIC: some code that needs relocated virtual at somewhere else some code that references data and/or jmps to code in between beginPIC and endPIC, and thus needs relocated some load directives end virtual endPIC: code that doesn't need relocated Will it work for this scenario? |
|||
24 Dec 2009, 08:57 |
|
LocoDelAssembly 24 Dec 2009, 15:28
Quote:
format macros? Take a second look to the manual. |
|||
24 Dec 2009, 15:28 |
|
baldr 24 Dec 2009, 16:52
Azu,
data fixups/end data generates standard PE base relocation table. It has simple format, refer to PE and COFF specification. Position-independent code is, by definition, position-independent, isn't it? Relocatable items in virtual block? I'd tested that, no way. Base relocations do not apply to your case: they're used to relocate image as a whole (thus the name -- base relocations). It looks more like linking two objects together: you'll need IMAGE_REL_I386_DIR32 (for objects' relocation and linking imm32/disp32) and IMAGE_REL_I386_REL32 (for relative inter-module branch/call instructions) type relocations. Tomasz Grysztar, I'd skimmed FAS specification (quite old, 2008-11-16), fixups didn't appear there, right? |
|||
24 Dec 2009, 16:52 |
|
Azu 24 Dec 2009, 21:37
baldr wrote: Relocatable items in virtual block? I'd tested that, no way. |
|||
24 Dec 2009, 21:37 |
|
baldr 24 Dec 2009, 21:50
Azu,
Why don't you compile both chunks as modules to COFF and parse them for code/fixups? Address expressions are evil, it's almost impossible to parse them appropriately without type information. |
|||
24 Dec 2009, 21:50 |
|
Azu 24 Dec 2009, 22:04
baldr wrote: Azu, Because I'd have to compile 3 separate files and manually dig through two of them to get the list of addresses? I find it so much nicer to just press a key and have it be compiled and working just like that. I really like convenience. I'm also planning to make edit and continue functionality for the same reason. baldr wrote: Address expressions are evil, it's almost impossible to parse them appropriately without type information. |
|||
24 Dec 2009, 22:04 |
|
baldr 24 Dec 2009, 22:10
Azu,
OK, how do you decide whether arbitrary expression is relocatable? |
|||
24 Dec 2009, 22:10 |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.