What is the purpose of .rodata.cst16 costants in decompiled NASM?

[AndrewF]

I have disassembled various C object files compiled with gcc x64 in NASM, and in the section .rodata.cst16 there are always declared some global variables that are all the same

Code: [Select]

SECTION .rodata.cst16 

    LC4:                                                    ; dword
            dd 80000000H, 00000000H                         ; 0000 _ -0.0 0.0
            dd 00000000H, 00000000H                         ; 0008 _ 0.0 0.0

    LC5:                                                    ; dword
            dd 80000000H, 00000000H                         ; 0000 _ -0.0 0.0
            dd 00000000H, 00000000H                         ; 0008 _ 0.0 0.0
Here a sample of use of these constants in the code sections

Code: [Select]

vmovss  xmm4, dword [rel LC4]
are all used with rel keyword with AVX mov operation vmovss in the same way

and I don'd understand the reason. why are needed these global constants used in this strange way?

[Frank Kotler]

Why do you think Nasm had anything to do with this? I very much doubt that Nasm created this section "behind your back". You might get better answers asking in a gcc group.

Alternatively, if you can assemble what you've got, try commenting out all references to it and see what breaks. (a rather strange "debugging" technique, but occasionally you can learn something from it - more often not).

Best,
Frank

[AndrewF]

Why do you think Nasm had anything to do with this? I very much doubt that Nasm created this section "behind your back". You might get better answers asking in a gcc group.

Alternatively, if you can assemble what you've got, try commenting out all references to it and see what breaks. (a rather strange "debugging" technique, but occasionally you can learn something from it - more often not).

Best,
Frank

Please forgive me if I'm a little annoying , I'm asking here because my problem is more related on how to read NASM code. 

in the 32 bit version of the code there aren't these global read-only constants but appear always in 64bit version.

And I don't know what is the meaning  of such kind of syntax and how should read the hex values in each constant

Code: [Select]

LC4:                                                   
            dd 80000000H, 00000000H                         
            dd 00000000H, 00000000H   

In others words
Ignoring the resons why the compiler use this, what's meaning LC4? and what's meaning

vmovss  xmm4, dword [rel LC4]

[gammac]

but that's not nasm syntax, that's syntax of your disassembler.

If you like to learn assembly programming, then it's normaly not necessary to disassemble the object files.

Often it will be necessary to debug your executable, but then you won't see such things that go on behind the scene. Such compiler or assembler and linker related things.

[Frank Kotler]

Well this is all way over my head! "LC4", etc. is just a variable name. Could be "rumplestilskin" just as easily. Nasm didn't make it up. If you didn't write it, your compiler made it up, or your disassembler made it up. I suspect the latter.

The "[]" is Nasm syntax. It means we're taking the contents of the variable. Without the "[]", just "LC4" would be the address of the variable. The "rel" means that the address (that we're getting "[contents]" of) is relative to RIP, rather than absolute. This is a 64-bit addressing mode which I'm really not familiar with. "dword" is just a size specifier (these variables actually appear to be 4 dwords each). "xmm4" is a register - I think it's 128 bits in 32-bit code - no idea in 64-bit code. "vmovss" is an instruction - apparently a "vex" instruction (I have no idea what that means except that it isn't going to run on my P4). I understand that Intel and AMD have nice manuals that explain these things. I'm more of a mov/cmp/jmp kinda guy.

Taking a wild-asmed guess, I think we're taking 4 dwords, interpreted as single-precision floats, and putting them in the xmm4 register. I have no idea why.

You getting any help from SO? I saw you asked a question over there, but haven't checked answers recently.

Best,
Frank

[gammac]

... The "rel" means that the address (that we're getting "[contents]" of) is relative to RIP, rather than absolute. This is a 64-bit addressing mode ...

I had never seen '[rel ...]' before, therefore I thought it's not nasm syntax.

[AndrewF]

Well this is all way over my head! "LC4", etc. is just a variable name. Could be "rumplestilskin" just as easily. Nasm didn't make it up. If you didn't write it, your compiler made it up, or your disassembler made it up. I suspect the latter.

The "[]" is Nasm syntax. It means we're taking the contents of the variable. Without the "[]", just "LC4" would be the address of the variable. The "rel" means that the address (that we're getting "[contents]" of) is relative to RIP, rather than absolute. This is a 64-bit addressing mode which I'm really not familiar with. "dword" is just a size specifier (these variables actually appear to be 4 dwords each). "xmm4" is a register - I think it's 128 bits in 32-bit code - no idea in 64-bit code. "vmovss" is an instruction - apparently a "vex" instruction (I have no idea what that means except that it isn't going to run on my P4). I understand that Intel and AMD have nice manuals that explain these things. I'm more of a mov/cmp/jmp kinda guy.

Taking a wild-asmed guess, I think we're taking 4 dwords, interpreted as single-precision floats, and putting them in the xmm4 register. I have no idea why.

You getting any help from SO? I saw you asked a question over there, but haven't checked answers recently.

Best,
Frank

I have get an answer but my doubts remains the same.

If i have understood rip relative use the address of memory declared as costant to made the istruction in the code, position independent. but I haven't understood why there are 4 hex values labeled as a single constant. e.g. 80000000H in decimal is 2147483648 the others 3 blocks 00000000H are all 0...

why I need 4 different hex values? these LC constants represent a memory address randomly generated, or there is something special at this address?(note that as I have said in various x64 program there is this costant with the same values)

[gammac]

Sorry, but what you are doing is asking for reading tea leaves.

[AndrewF]

Sorry, but what you are doing is asking for reading tea leaves.

I was hoping that someone with a deep knowledge of assembly programming could grasp the meaning of a similar operation.

The crackers usually read much difficult code since don't know the original c code that have generated the assembly(and the program is in most case also compiled with obfuscation techniques)... Here I have written the c code myself, where I haven't written any constants, but the compiler create always this entry for 64 bit XD

[Frank Kotler]

how 1065353216  could represent a 1?

If it's a float.

A bit is a bit is a bit. What a bit pattern "means" depends on how it's interpreted. That's why Gammac says it's like reading tea leaves. I would have said chicken guts. To see how a bit pattern would be interpreted as a single-precision float, check out IEEE 754 (it's more than you want to know!).

FWIW, in Nasm syntax...

Code: [Select]

myint dd 1
myfloat dd 1.0

If you've got something that Nasm will assemble, you're making good progress. If it works correctly, even better.

Best,
Frank

[gammac]

I was hoping that someone with a deep knowledge of assembly programming could grasp the meaning of a similar operation.

Do you know that every high level language compiler generates their own startup code? Maybe you should ask at your favourite compiler builder forum.

[gammac]

I've stumbled across:

"__vectorcall Specifics

A __vectorcall function’s integer arguments are passed by value, using up to two (on x86) or four (on x64) integer registers, and up to six XMM registers for floating-point and vector values, and the rest are passed on the stack from right to left. The called function cleans off the stack before it returns. Vector and floating-point return values are returned in XMM0." _{http://msdn.microsoft.com/en-us/library/46t77ak2.aspx}