Section ".reloc" bug ?

Index > Compiler Internals > Section ".reloc" bug ?

Author

Thread

hopcode

Joined: 04 Mar 2008
Posts: 563
Location: Germany

hopcode 09 Sep 2009, 06:08

Strange behaviour, when compiling, fasm raises error in the test macro
(and some of my macros).
Could you compile it ?

Code:

 format PE GUI 4.0 DLL
       entry entrydll
      include '%fasminc%\win32a.inc'

; - declaring "section .reloc" breaks semantics on adress symbols/labels
; - follow a test macro to let raising error
; - Analogues errors with fasm 1.69.2 and 1.67.29 /1.67.38
; - with or without using macros/import/export/resdata etc.

macro display_decimal value*,put_zeros {
       local leading_zero,digit,divisor,number
     number=value
        if number=1 shl 63
          display '-9223372036854775808'
            else
                if number<0
              number=-number
              display '-'
               end if
              leading_zero=put_zeros+0
            divisor=1000000000000000000
         while divisor>0
                  digit=number/divisor
                leading_zero=leading_zero+digit
             if leading_zero | (divisor=1)
                       display digit+'0'
                                 number=number-digit*divisor
                         end if
                              divisor=divisor/10
                  end while
           end if
      }
;-------------------------------------------------------
          
section '.data' data readable writeable
       dd 0
section '.code' code readable executable

proc entrydll p1,p2,p3
            
    display_decimal $               ;<--fasm raises error at this point in the macro !!!!!!!!!!
              db 90h          
    display_decimal $
           
            xor             eax,eax
             inc             eax
         ret
endp

dummy_func:
  ret
 section '.reloc'  data discardable fixups ; <-- the involed line

; fasm raises more and different errors

Regards,
hopcode

09 Sep 2009, 06:08

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20621
Location: In your JS exploiting you and your system

revolution 09 Sep 2009, 06:14

Because you have fixups enabled this makes your code section relocatable so then the value of $ is unknown at compile time. The macro needs a fixed value to work so any relocatable value will create the problem you see.

Instead try something like this:

Code:

display_decimal rva $

09 Sep 2009, 06:14

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 09 Sep 2009, 06:20

Well, it is OK that it doesn't compile because you are doing calculations over things that will change in run-time making the calculations wrong.

What I found strange is why it is reported so late, I would expect "digit=number/divisor" to be signaled as error, but instead fasm defers the error up to "if leading_zero...".

[edit]
Alternate solution: replace "number=value" with this:

Code:

        virtual
          dq value
          load number qword from $$
        end virtual

But take in mind that if you pass addresses then the displayed values may or may not match those at run-time. rva shows the run-time relative virtual address but since it is relative you will have to add the run-time $$ to make them real full addresses.
[/edit]

09 Sep 2009, 06:20

hopcode

Joined: 04 Mar 2008
Posts: 563
Location: Germany

hopcode 09 Sep 2009, 07:47

revolution wrote:

Because you have fixups enabled this makes your code section relocatable...

Yes, ok... but as default in the Optional Header ImageBase is at 0x00400000
when first declaring (WYSIWYG)
"format PE GUI 4.0 DLL"

Quote:

The macro needs a fixed value to work...

and it should be so after all,shouldnt it ?

09 Sep 2009, 07:47

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20621
Location: In your JS exploiting you and your system

revolution 09 Sep 2009, 07:54

hopcode wrote:

Quote:
The macro needs a fixed value to work...

and it should be so after all,shouldnt it ?

No, the value is unknown. The PE will suggest to the OS that the base address is 0x400000, but the OS can make it whatever it wants (by relocating) thus making that value of $ unknown at compile time.

If you leave out the .reloc section then the OS has no choice but to load it at 0x400000, thus the value of $ is known with 100% certainty and the macro will work fine.

09 Sep 2009, 07:54

hopcode

Joined: 04 Mar 2008
Posts: 563
Location: Germany

hopcode 09 Sep 2009, 08:01

revolution wrote:

...but the OS can make it whatever it wants (by relocating...

It's ok..ok, i mean only that anyway fasm set Imagebase as default, but doesent give $ a fixed value, relative to the default setting declared (for fasm and OS) in
"format PE GUI 4.0 DLL".

09 Sep 2009, 08:01

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20621
Location: In your JS exploiting you and your system

revolution 09 Sep 2009, 08:07

rva $ will give the offset from image base, that is always known whether fixups are enabled or not.

Image base is only a suggestion to the OS. fasm still makes it 0x400000 by default, just that now all absolute PC values become unknown because of fixups. With fixups you can only use relative PC values.

09 Sep 2009, 08:07

hopcode

Joined: 04 Mar 2008
Posts: 563
Location: Germany

hopcode 09 Sep 2009, 08:22

revolution wrote:

...With fixups you can only use relative PC values.

Ok,

,when it so is, it will go for fixups and relative PC values.
Regards

09 Sep 2009, 08:22

< 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