I have a obj file with a seriously large amount of relocations in it.
Nasm compiles it fine, however dumpbin /relocations shows that not all
relocations were added. Nasm did not warm or break the compile process
I'm fairly certain I'm also experiencing this issue. I can provide a source file that causes this issue to happen, but only if somebody can sign an NDA.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, sending NDA paper, sign it and send it back to you might consume quite a time. Though I'm not sure, perhaps it'll be faster for Peter.
But note that in real we would like to not obtain any large chunk of code anyway. Is it possible to modify your source that way so no proprietary things left there but only exposure of the problem?
Talking on my behalf -- I can guarantee that any code example I receive will be deleted from my computer as only problem fixed. But this is not "real" NDA, rather action of trust.
I talked with my business partner about it last night and we can scramble the symbols and strip the comments and make the file pretty useless, so we'll do that and send a copy over. It might take me a day or two to get it out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It may be a problem that maximum amount of relocations in a sections must be less than 65536.
In microsoft's COFF format for win32/64, the size of number of relocations for each section is two bytes. NASM output srelocation truncated object without warning or error.
Here is a simple example code.
As a workaround, split code to may temporal sections to prevent merge section, and rename them to '.text' by EDITBIN.
--------------
%define RNUM 65537 ; max of relocations in a section is 65535
section .data
r dd RNUM
%macro x 1
mov eax, [r + %1]
%endmacro
section .text
%assign i 0
%rep RNUM
x i
%assign i i+1
%endrep
-------------------
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SECTION HEADER #1
pass name
4FFFB size of raw data
8C file pointer to raw data (0000008C to 00050086)
50087 file pointer to relocation table
FFFF number of relocations
SECTION HEADER #2
fail name
50000 size of raw data
F007D file pointer to raw data (000F007D to 0014007C)
14007D file pointer to relocation table
0 number of relocations
SECTION HEADER #3
fail2 name
50005 size of raw data
1E007D file pointer to raw data (001E007D to 00230081)
230082 file pointer to relocation table
1 number of relocations
The COFF spec documents that a relocation count
which exceeds the 16-bit field must be represented
by setting IMAGE_SCN_LNK_NRELOC_OVFL, and
setting the field to 0xFFFF, and using the VA of the
first relocation to represent the (32-bit) count.
While NASM's pecoff.h defines that constant, code
in outcoff.c doesn't implement the behavior.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This item has been resolved; the fix has been checked into git (http://repo.or.cz/w/nasm.git) and will be in the next release.
You can usually also obtain a nightly snapshot at http://www.nasm.us/; the snapshot robot usually runs some time between 07:00 and 09:00 UTC, but sometimes runs immediately if there was no previous snapshot for today.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any way you could give us a test case and tell us what to look for?
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I'm fairly certain I'm also experiencing this issue. I can provide a source file that causes this issue to happen, but only if somebody can sign an NDA.
Well, sending NDA paper, sign it and send it back to you might consume quite a time. Though I'm not sure, perhaps it'll be faster for Peter.
But note that in real we would like to not obtain any large chunk of code anyway. Is it possible to modify your source that way so no proprietary things left there but only exposure of the problem?
Talking on my behalf -- I can guarantee that any code example I receive will be deleted from my computer as only problem fixed. But this is not "real" NDA, rather action of trust.
Also, please take a look on http://nasm.us/doc/nasmdo12.html#section-12.2
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I talked with my business partner about it last night and we can scramble the symbols and strip the comments and make the file pretty useless, so we'll do that and send a copy over. It might take me a day or two to get it out.
ok. no hurry. btw, what kind of OBJ it was for? Is the target platform DOS or Win32/64?
It may be a problem that maximum amount of relocations in a sections must be less than 65536.
In microsoft's COFF format for win32/64, the size of number of relocations for each section is two bytes. NASM output srelocation truncated object without warning or error.
Here is a simple example code.
As a workaround, split code to may temporal sections to prevent merge section, and rename them to '.text' by EDITBIN.
--------------
%define RNUM 65537 ; max of relocations in a section is 65535
section .data
r dd RNUM
%macro x 1
mov eax, [r + %1]
%endmacro
section .text
%assign i 0
%rep RNUM
x i
%assign i i+1
%endrep
-------------------
sounds correct. my example is win32 and the 4mb package is too large to upload here and is also containing sensetive information.
My main concern is that there was no warning/error for this case.
Thanks for report! I'll take a look in a couple of days.
extern foo
segment pass
%rep 0xFFFF
mov al,[foo]
%endrep
segment fail
%rep 0x10000
mov al,[foo]
%endrep
segment fail2
%rep 0x10001
mov al,[foo]
%endrep
----------
SECTION HEADER #1
pass name
4FFFB size of raw data
8C file pointer to raw data (0000008C to 00050086)
50087 file pointer to relocation table
FFFF number of relocations
SECTION HEADER #2
fail name
50000 size of raw data
F007D file pointer to raw data (000F007D to 0014007C)
14007D file pointer to relocation table
0 number of relocations
SECTION HEADER #3
fail2 name
50005 size of raw data
1E007D file pointer to raw data (001E007D to 00230081)
230082 file pointer to relocation table
1 number of relocations
The COFF spec documents that a relocation count
which exceeds the 16-bit field must be represented
by setting IMAGE_SCN_LNK_NRELOC_OVFL, and
setting the field to 0xFFFF, and using the VA of the
first relocation to represent the (32-bit) count.
While NASM's pecoff.h defines that constant, code
in outcoff.c doesn't implement the behavior.
Just pushed the fix out, please pick up the nasm snapshot (which will be made soon by our compile farm) and give it a shot.
This item has been resolved; the fix has been checked into git (http://repo.or.cz/w/nasm.git) and will be in the next release.
You can usually also obtain a nightly snapshot at http://www.nasm.us/; the snapshot robot usually runs some time between 07:00 and 09:00 UTC, but sometimes runs immediately if there was no previous snapshot for today.