flat assembler
Message board for the users of flat assembler.

Index > Windows > [Bug?] No relocation for `proc local variable dd offset`

Author
Thread Post new topic Reply to topic
RIxRIpt



Joined: 18 Apr 2013
Posts: 50
RIxRIpt 15 Jun 2019, 14:46
Hello, I'm developing remote run-time linker for MS COFF, and I encountered a weird problem, namely a lack of relocation.

For the following code FASM produces relocations in only functions { test_relocation1 and test_relocation2 }.
Code:
format MS COFF

include 'win32ax.inc'

public test_no_relocation
public test_relocation1
public test_relocation2

section 'data' readable writeable
buffer db 4 dup 0

section 'code' readable executable
    proc test_no_relocation
        local buf dd buffer
        mov eax, [buf]
        mov dword[eax], 0
        ret
    endp

    test_relocation1:
        push ebp
        mov ebp, esp
        sub esp, 4
        mov dword[ebp - 4], buffer
        mov eax, dword[ebp - 4]
        mov dword[eax], 0
        leave
        retn

    proc test_relocation2
        local buf dd ?
        mov [buf], buffer
        mov eax, [buf]
        mov dword[eax], 0
        ret
    endp
    


Here is the dump of the produced ASM, when linked with rrlinker:
Code:
005C0000 | 55                       | push ebp                                 |
005C0001 | 89E5                     | mov ebp,esp                              |
005C0003 | 83EC 04                  | sub esp,4                                |
005C0006 | C745 FC 00000000         | mov dword ptr ss:[ebp-4],0               | ; <- no relocation
005C000D | 8B45 FC                  | mov eax,dword ptr ss:[ebp-4]             |
005C0010 | C700 00000000            | mov dword ptr ds:[eax],0                 |
005C0016 | C9                       | leave                                    |
005C0017 | C3                       | ret                                      |
005C0018 | 55                       | push ebp                                 |
005C0019 | 89E5                     | mov ebp,esp                              |
005C001B | 83EC 04                  | sub esp,4                                |
005C001E | C745 FC 00005B00         | mov dword ptr ss:[ebp-4],5B0000          |
005C0025 | 8B45 FC                  | mov eax,dword ptr ss:[ebp-4]             |
005C0028 | C700 00000000            | mov dword ptr ds:[eax],0                 |
005C002E | C9                       | leave                                    |
005C002F | C3                       | ret                                      |
005C0030 | 55                       | push ebp                                 |
005C0031 | 89E5                     | mov ebp,esp                              |
005C0033 | 83EC 04                  | sub esp,4                                |
005C0036 | C745 FC 00005B00         | mov dword ptr ss:[ebp-4],5B0000          |
005C003D | 8B45 FC                  | mov eax,dword ptr ss:[ebp-4]             |
005C0040 | C700 00000000            | mov dword ptr ds:[eax],0                 |
005C0046 | C9                       | leave                                    |
005C0047 | C3                       | ret                                      |
    


In the following dump of test.obj (produced with mscoffdump) it is possible to see that there are only 2 relocations defined in the .obj file.
Code:
IMAGE_FILE_HEADER
 Machine              014c : I386
 NumberOfSections     2
 TimeDateStamp        1560609725
 PointerToSymbolTable 000000c4
 NumberOfSymbols      5
 SizeOfOptionalHeader 0
 Characteristics      0184
  - LINE_NUMS_STRIPPED
  - BYTES_REVERSED_LO
  - 32BIT_MACHINE

IMAGE_SECTION_HEADER
 Name                 data
 PhysicalAddress      00000000
 VirtualAddress       00000000
 SizeOfRawData        4
 PointerToRawData     00000064
 PointerToRelocations 00000000
 PointerToLinenumbers 00000000
 NumberOfRelocations  0
 NumberOfLinenumbers  0
 Characteristics      c0300000
  - MEM_READ
  - MEM_WRITE
  - ALIGN_4BYTES

IMAGE_SECTION_HEADER
 Name                 code
 PhysicalAddress      00000000
 VirtualAddress       00000000
 SizeOfRawData        72
 PointerToRawData     00000068
 PointerToRelocations 000000b0
 PointerToLinenumbers 00000000
 NumberOfRelocations  2
 NumberOfLinenumbers  0
 Characteristics      60300000
  - MEM_EXECUTE
  - MEM_READ
  - ALIGN_4BYTES

 IMAGE_RELOCATION
  VirtualAddress   00000021
  SymbolTableIndex 3
  Type             0006 (DIR32)
 IMAGE_RELOCATION
  VirtualAddress   00000039
  SymbolTableIndex 3
  Type             0006 (DIR32)

IMAGE_SYMBOL (0)
 Name               00000004 : test_no_relocation
 Value              00000000
 SectionNumber      2
 Type               00000000 : NULL NULL
 StorageClass       00000002 : EXTERNAL
 NumberOfAuxSymbols 0

IMAGE_SYMBOL (1)
 Name               00000017 : test_relocation1
 Value              00000018
 SectionNumber      2
 Type               00000000 : NULL NULL
 StorageClass       00000002 : EXTERNAL
 NumberOfAuxSymbols 0

IMAGE_SYMBOL (2)
 Name               00000028 : test_relocation2
 Value              00000030
 SectionNumber      2
 Type               00000000 : NULL NULL
 StorageClass       00000002 : EXTERNAL
 NumberOfAuxSymbols 0

IMAGE_SYMBOL (3)
 Name               data
 Value              00000000
 SectionNumber      1
 Type               00000000 : NULL NULL
 StorageClass       00000003 : STATIC
 NumberOfAuxSymbols 0

IMAGE_SYMBOL (4)
 Name               code
 Value              00000000
 SectionNumber      2
 Type               00000000 : NULL NULL
 StorageClass       00000003 : STATIC
 NumberOfAuxSymbols 0
    


I am using flat assembler version 1.73.12 for Windows.
Source code and produced .obj file are in the attachment (test.zip).

Question: is it a bug in FASM, or is it expected behaviour?


Description:
Download
Filename: test.zip
Filesize: 608 Bytes
Downloaded: 458 Time(s)


_________________
Привет =3
Admins, please activate my account "RIscRIpt"
Post 15 Jun 2019, 14:46
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 15 Jun 2019, 17:40
This is a limitation of the "local" macro implementation in PROC.INC package and how it initializes local variables. It should be possible to correct for it by tweaking the macro.
Post 15 Jun 2019, 17:40
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 15 Jun 2019, 18:03
I managed to make a relatively simple compensation for this problem in the fasmg's implementation of these macros. Your sample seems to assemble correctly with fasmg now, as far as my quick tests went.

As for the equivalent macro for fasm 1, I'm afraid it might not be as simple to extend it appropriately. I need to take a better look at it.
Post 15 Jun 2019, 18:03
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.