where is .data? segment?

[markallyn]

Hello everyone,

This is a beginner question.  Please be assured that I have spent 3 days trying to get an understanding of the situation.

Where is the .data? segment.  Put differently, why does it seem to be subsumed under the .data segment instead of being listed separately in the PE?  Indeed, when I examine the .data section with PEViewer, the output tells me that there are no uninitialized data in the section when in fact there are.  X64dbg yields the same result.

Related to this:  If I wanted to change the attributes of the .data (_BSS) segment, how could I do it--or can I do it at all (as seems to have been the case with 32 bit .MODEL directive where the documentation I've seen indicates that the segments were "frozen" once the .MODEL directive was employed)?

Thanks.  In need of a tutorial ...
Mark Allyn

[aw27]

Where is the .data? segment.

The linker uses to merge it into the .data section.

Related to this:  If I wanted to change the attributes of the .data (_BSS) segment, how could I do it--or can I do it at all (as seems to have been the case with 32 bit .MODEL directive where the documentation I've seen indicates that the segments were "frozen" once the .MODEL directive was employed)?

Of course, you can change attributes.
https://docs.microsoft.com/en-us/cpp/assembler/masm/segment



[/quote]

[markallyn]

hi aw27,

Q1:  yes, I knew from several test programs that the .data? segment was located in the PE .data section.  So, my query was badly phrased and misleading.  I should have asked:  why does the linker do this?  What is the point of reserving a .data? directive if the linker is going to put it into the .data section anyway?  Perhaps it is just to make code a bit more readable?

Q2;  yes, I knew from reading the MSFT documentation that a segment could be defined in precisely the manner described by the link you sent (I had read this several times over the last couple of days).  In fact, I played around with segment definitions and wrote a few of my own.  What I was seeking an answer to was how to change the "short form" segment attributes (i.e. change the attributes of .code, .data, .stack, etc.). 

Thanks,
Mark

[felipe]

  What I was seeking an answer to was how to change the "short form" segment attributes (i.e. change the attributes of .code, .data, .stack, etc.). 

I knew that if you want more control over this you need to use the segment directive and not the simplified segment definitions.  :idea:

[hutch--]

Mark,

There are all sorts of gadgets for looking at the guts of a binary but when you are through playing games, get a HEX editor, the latest I have found is called HXD and it is an excellent tool. If you have not use a compressor or similar, you can directly read the start of the PE header and have a look at the available sections. With initialised data (.DATA) if you scroll down near the end of the binary you will find all of the string data, with a little practice you can find the resource section if its a Windows UI app.

[aw27]

What is the point of reserving a .data?

This is not the right question as well because we all know there is a point with the .data?.

Q2;  yes, I knew from reading the MSFT documentation that a segment could be defined in precisely the manner described by the link you sent (I had read this several times over the last couple of days).  In fact, I played around with segment definitions and wrote a few of my own.  What I was seeking an answer to was how to change the "short form" segment attributes (i.e. change the attributes of .code, .data, .stack, etc.). 

Probably you don't pay attention to answers people give to your own questions.
I gave you all the information here:
http://masm32.com/board/index.php?topic=6655.msg71270#msg71270
What else do you want? More examples?

[markallyn]

Hello everyone,

OK, I've spent a rainy day working on the problem of changing segment attributes, with quite mixed results.  Here's the most recent version of my test code:

include \masm32\include64\masm64rt.inc

printf PROTO :QWORD, :VARARG

_DATA   SEGMENT ALIGN(16) 'DATA'  ; can't align(32), can't alias('.data')
frmt1   BYTE "%d",13,10,0
_DATA   ENDS

CONST   SEGMENT   ALIGN(32)'DATA' ALIAS('.const') ; can't use PUBLIC, can't use FLAT, can do align(32)
nextinst   textequ <lea rdx,num1>
CONST   ENDS

_BSS   SEGMENT ALIGN(32)'DATA' ALIAS('.data?'); can't use PUBLIC, can't use FLAT.  But, can do align(32)
num1   real8   ?
str1   BYTE   8 dup(?)
_BSS   ENDS

.code
main   PROC

lea      rax, str1
nextinst
mov   num1, 32
mov   rdx, num1
invoke   printf, ADDR frmt1, rdx

ret
main ENDP
END

As indicated by the notations, some attributes can be changed.  In particular, the _BSS segment can be aliased with .data? and this section will show up as a separate item in the PE.  But, not the other two.  CONST in particular cannot be listed separately as .const.  And the _DATA segment is very particular about alignment and other attritubes.

I'm using ML64 and LINK for the build.

I can't see why PUBLIC and FLAT are problematic, but they seem to be.  In none of the documentation i've looked at over the last several days can I find any reason why they shouldn't be accepted by a full segment definition.  Maybe something happened when .MODEL was removed from the x64 MASM directives?

Mark

[aw27]

Maybe something happened when .MODEL was removed from the x64 MASM directives?

I would expect that, .MODEL is not a MASM 64 directive.  :icon_eek:

[hutch--]

PUBLIC works fine.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    PUBLIC bintable

    .data
      align 16
      bintable \
        db "0000000000000001000000100000001100000100000001010000011000000111"
        db "0000100000001001000010100000101100001100000011010000111000001111"
        db "0001000000010001000100100001001100010100000101010001011000010111"
        db "0001100000011001000110100001101100011100000111010001111000011111"
        db "0010000000100001001000100010001100100100001001010010011000100111"
        db "0010100000101001001010100010101100101100001011010010111000101111"
        db "0011000000110001001100100011001100110100001101010011011000110111"
        db "0011100000111001001110100011101100111100001111010011111000111111"
        db "0100000001000001010000100100001101000100010001010100011001000111"
        db "0100100001001001010010100100101101001100010011010100111001001111"
        db "0101000001010001010100100101001101010100010101010101011001010111"
        db "0101100001011001010110100101101101011100010111010101111001011111"
        db "0110000001100001011000100110001101100100011001010110011001100111"
        db "0110100001101001011010100110101101101100011011010110111001101111"
        db "0111000001110001011100100111001101110100011101010111011001110111"
        db "0111100001111001011110100111101101111100011111010111111001111111"
        db "1000000010000001100000101000001110000100100001011000011010000111"
        db "1000100010001001100010101000101110001100100011011000111010001111"
        db "1001000010010001100100101001001110010100100101011001011010010111"
        db "1001100010011001100110101001101110011100100111011001111010011111"
        db "1010000010100001101000101010001110100100101001011010011010100111"
        db "1010100010101001101010101010101110101100101011011010111010101111"
        db "1011000010110001101100101011001110110100101101011011011010110111"
        db "1011100010111001101110101011101110111100101111011011111010111111"
        db "1100000011000001110000101100001111000100110001011100011011000111"
        db "1100100011001001110010101100101111001100110011011100111011001111"
        db "1101000011010001110100101101001111010100110101011101011011010111"
        db "1101100011011001110110101101101111011100110111011101111011011111"
        db "1110000011100001111000101110001111100100111001011110011011100111"
        db "1110100011101001111010101110101111101100111011011110111011101111"
        db "1111000011110001111100101111001111110100111101011111011011110111"
        db "1111100011111001111110101111101111111100111111011111111011111111"

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

In 64 bit MASM you only have FLAT memory model so it does not need to be specified.

[markallyn]

Good morning/evening, Hutch.

Do you have any theory as to why my use of PUBLIC offends the assemble/link steps?  I notice in your code that you use the PUBLIC attribute "outside" the .data segment.  I need to try this approach (and perhaps for FLAT as well).

I can see why FLAT doesn't matter in 64-bit land, but the assembler is quite gruff about including it as opposed to simply saying that it is ignoring it.

The documentation from MSFT on this segment stuff is pretty thin. Among the weaknesses seems to be the lack of information about default segment attributes, and also what eliminating the .MODEL directive did to the existing simplified segment directives.

Again, thanks.

Mark

[markallyn]

Hutch,

Yup.  If you declare data item as PUBLIC "outside" the segment definition, all is well.  My idle speculation regarding FLAT "outside" the segment declaration was silly. 

Mark

[qWord]

markallyn,

the ".data?"-segment does not contain any data until runtime. The linker creates the BSS-section in the PE-Header to give the ".data?"-segment an unique range in address space that is referenced by your code. The PE-loader allocates and initialize the section with zero.

Text macros (TEXTEQU) and equates (EQU,'=') exist only while assembling. Data in the ".const"-segment must be defined as in any other segment.

Regarding ML64 and full segmentation: not sure why they removed the segment combine types (PUBLIC^**,PRIVATE,COMMON,...) for x64, but removing the attributes to set the segment word size (USE16/32,FLAT) makes sense, because ml64 is an plain 64 bit assembler as hutch noted.


^** _{This keyword has no relation with the PUBLIC-directive.}

[markallyn]

Good afternoon, qWord,

Your description of .data? exactly corresponds to what I observe with my debugger.

I checked MSFT's documentation on the PUBLIC directive for ml64.  You're right--there's no relationship mentioned regarding the use of PUBLIC as a segment attribute--only variables get mentioned. 

Thank you.
Mark Allyn

[aw27]

Regarding ML64 and full segmentation: not sure why they removed the segment combine types (PUBLIC^**,PRIVATE,COMMON,...) for x64, but removing the attributes to set the segment word size (USE16/32,FLAT) makes sense, because ml64 is an plain 64 bit assembler as hutch noted.

They have not removed the segment combine types and they have not removed the segment word size.
It is all there, in daylight.

oneseg SEGMENT PRIVATE ALIGN(16) FLAT alias (".data") 'DATA'  ; This works.
somedata   BYTE "hello there",0
oneseg   ENDS

[qWord]

Regarding ML64 and full segmentation: not sure why they removed the segment combine types (PUBLIC^**,PRIVATE,COMMON,...) for x64, but removing the attributes to set the segment word size (USE16/32,FLAT) makes sense, because ml64 is an plain 64 bit assembler as hutch noted.

They have not removed the segment combine types and they have not removed the segment word size.
It is all there, in daylight.

oneseg SEGMENT PRIVATE ALIGN(16) FLAT alias (".data") 'DATA'  ; This works.
somedata   BYTE "hello there",0
oneseg   ENDS

Code: [Select]

option casemap:none

oneseg SEGMENT PRIVATE ALIGN(16) FLAT alias (".data") 'DATA'
somedata   BYTE "hello there",0
oneseg   ENDS

end

...>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\ml64.exe" /c foo.asm
Microsoft (R) Macro Assembler (x64) Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: foo.asm
foo.asm(3) : error A2008:syntax error : PRIVATE
foo.asm(4) : error A2034:must be in segment block
foo.asm(5) : fatal error A1010:unmatched block nesting : oneseg

what I'm missing?