flat assembler
Message board for the users of flat assembler.
Index
> Windows > [Bug?] No relocation for `proc local variable dd offset` |
Author |
|
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?
_________________ Привет =3 Admins, please activate my account "RIscRIpt" |
|||||||||||
15 Jun 2019, 14:46 |
|
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. |
|||
15 Jun 2019, 18:03 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.