Alignment with explicit address/label

Index > Macroinstructions > Alignment with explicit address/label

Author

Thread

LostCoder

Joined: 07 Mar 2012
Posts: 22

LostCoder 07 Mar 2012, 11:13

Before all - sorry for my English. I need help with extending align macro so it can use addresses/labels other than $ for calculation. Someting like this:

Code:

macro align value,addr=$
{
  db ((addr+value-1)/value*value-addr) dup (90h)
}

align 16,someloop

somefunc:
        push    ebp
        mov     ebp,esp

        mov     ecx,100

someloop:
        sub     ecx,1
        jnz     someloop

        mov     esp,ebp
        pop     ebp
        ret

As you can guess, this variant does not work. It display error "Error: code cannot be generated.". I also tried several other approaches, but none of them worked. The idea is to move nop's out from function body before it entry point.

07 Mar 2012, 11:13

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 07 Mar 2012, 11:28

Maybe like this?

Code:

macro align value,addr=$
{
  local base,size
  base = addr-size
  size = ((base+value-1)/value*value-base)
  db size dup 90h
}

07 Mar 2012, 11:28

LostCoder

Joined: 07 Mar 2012
Posts: 22

LostCoder 07 Mar 2012, 11:38

Tomasz, YES! You make me happy! Thanks a lot! Very Happy

07 Mar 2012, 11:38

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 07 Mar 2012, 11:44

It doesn't really work with $ value though, the complete macro should be:

Code:

macro align value,addr=$
{ 
  local base,size 
  if addr>$
    base = addr-size
    size = ((base+value-1)/value*value-base)
    db size dup 90h
  else
    db ((addr+value-1)/value*value-addr) dup 90h
  end if
}

07 Mar 2012, 11:44

16bitPM

Joined: 08 Jul 2011
Posts: 30

16bitPM 03 Oct 2012, 16:42

I don't understand this. Why didn't the first code work? Afterall the manual has an example like this:

Code:

    macro align value { rb (value-1)-($+value-1) mod value }

And why did the second and third work? They contain a circular reference (base is dependent on size and vice versa).

And finally, why didn't you work with the mod operator?

03 Oct 2012, 16:42

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 03 Oct 2012, 17:20

16bitPM wrote:

I don't understand this. Why didn't the first code work?

If you unroll a macro and cut out the unimportant code, you can simplify it to this:

Code:

  db ((someloop+15)/16*16-someloop) dup (90h)
somefunc:
        nop ; some instructions
someloop:

which creates dependency between "somefunc" and "someloop" like this:

Code:

somefunc = (someloop+15)/16*16-someloop
someloop = somefunc + c

where "c" is the size of code between "somefunc" and "someloop". If we substitute "somefunc" value into the second equation we get "someloop = (someloop+15)/16*16-someloop + c", which cancels into "0 = (someloop+15)/16*16 + c". Since neither "(someloop+15)/16*16" nor "c" can be less than zero, the solution exists only when c=0, and thus this code cannot be resolved as long as you have some instructions between "somefunc" and "someloop".

16bitPM wrote:

And why did the second and third work? They contain a circular reference (base is dependent on size and vice versa).

In this case the equation are designed in such a way that correct solutions exists and fasm is able to find it. You can read more about fasm's code resolving in the Understanding flat assembler article.

16bitPM wrote:

And finally, why didn't you work with the mod operator?

LostCoder used this technique and I mimicked it, hoping that it would to make my macro more clear to him.

03 Oct 2012, 17:20

tripledot

Joined: 06 Jan 2009
Posts: 49

tripledot 19 Sep 2013, 14:05

Serious necrophilia here. Sorry. I've been away for a long time; work dragged me into C++ land Sad

Anyway, I'm struggling to get this explicit-address-alignment to work with MS COFF format ("Invalid use of symbol"). Applying the rva operator willy-nilly doesn't seem to fix things. Any ideas?

19 Sep 2013, 14:05

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 19 Sep 2013, 21:28

tripledot

Quote:

Applying the rva operator willy-nilly doesn't seem to fix things.

That's because rva seems to return a value unknown at compile time of the MS COFF and thus requiring a relocation: the value will be known after linking. In other words rva $ relativeto 0 is false. What you could do is to subtract $$ instead of applying the rva operator. And don't forget to set the section alignment at least as large as the largest alignment you apply.

_________________
Faith is a superposition of knowledge and fallacy

19 Sep 2013, 21:28

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum