OBJ file exposes itself path

[bluedevil]

I am trying to make a static 64bit library.

My parameters are for ML64 and LIB.EXE are

Code Select Expand


REM Assemble
\masm64\bin64\ml64.exe /c Modules\_add.asm
\masm64\bin64\ml64.exe /c Modules\_sub.asm

REM Compile object files into lib
\masm64\bin64\LIB.EXE *.obj /out:%appname%.lib


PROBLEM
When I look obj file with a hex editor, i have realized that my path to obj file is also included.

Code Select Expand


Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000080  00 00 00 00 00 00 00 00 40 00 10 42 48 89 4D 10  ........@..BH‰M.
00000090  48 89 55 18 48 8B 45 10 48 8B 5D 18 48 03 C3 C3  H‰U.H‹E.H‹].H.ÃÃ
000000A0  04 00 00 00 F1 00 00 00 91 00 00 00 56 00 01 11  ....ñ...'...V...
000000B0  00 00 00 00 43 3A 5C 55 73 65 72 73 5C 41 64 6D  ....C:\Users\Adm \
000000C0  69 6E 69 73 74 72 61 74 6F 72 5C 44 6F 77 6E 6C  inistrator\Downl | I don't want
000000D0  6F 61 64 73 5C 4D 41 53 4D 33 32 2D 46 4F 52 55  oads\MASM32-FORU | thıs path info
000000E0  4D 5C 55 73 65 72 73 5C 62 6C 75 65 64 65 76 69  M\Users\bluedevi |
000000F0  6C 5C 41 72 69 74 68 4C 69 62 5C 5F 61 64 64 2E  l\ArithLib\_add. |
00000100  6F 62 6A 00 37 00 3C 11 03 02 00 00 D0 00 00 00  obj.7.<.....Ð... /
00000110  00 00 00 00 00 00 0E 00 21 00 8D 7B 00 00 4D 69  ........!..{..Mi
00000120  63 72 6F 73 6F 66 74 20 28 52 29 20 4D 61 63 72  crosoft (R) Macr
00000130  6F 20 41 73 73 65 6D 62 6C 65 72 00 00 00 00 00  o Assembler.....
00000140  40 63 6F 6D 70 2E 69 64 8D 7B 03 01 FF FF 00 00  @comp.id.{..ÿÿ..


Then when I run LIB.EXE and create a static library files, that library file also includes this path information.

QUESTION
Which command line parameters should I use to make ML64 or LIB.EXE not to include this path info. I have checked ML64 command line reference and LIB.EXE pages, unfortunately I couldn't find a proper solution?

[TimoVJL]

.debugSS is in object-file and lib.exe (link.exe) just store it.

[hutch--]

Hi bluedevil,

The path data does occur in the OBJ module but it does not appear in the final binary. Why is this a problem ?

If you are distributing the OBJ modules, build the OBJ files in a different directory so that the name does not tell anyone anything useful.

[zedd151]

Would zeroing out the path information cause any detrimental effects? If not would be a simple matter to take care of. Either in a hex editor or write a simple program to do the job. I'm not at my computer just now, else I would check for myself. 

[HSE]

Try building from main module file directory.

[zedd151]

Would zeroing out the path information cause any detrimental effects? If not would be a simple matter to take care of. Either in a hex editor or write a simple program to do the job. I'm not at my computer just now, else I would check for myself. 

A bit later, I tested my theory...
After zeroing out the path in both object files, the .lib file still gets created without issue and no path information is written to it. I just tested it. But be sure not to zero out anything after or before the path information.

I modified the batch file in 2nd zip file to not recreate the object files, but to only create the lib file from them. First zip file is only the resulting .lib file

So, we both learned something new today.   To test this for yourself, (from 2nd zip) delete lib file, inspect both .obj files (see that no path there) then run the batch file and inspect the resulting lib file with a hex editor (no path there either).    Attachment removed as it has served its purpose

[zedd151]

I have not tested the lib file after the modification above bluedevil. I will leave the tesing up to you. Let me know that it works okay or not.    Im running 32 bit machine at the moment (but can still use 32 bit versions of ml64,link & lib) 

btw, why

Code Select Expand


    mov a, rcx
    mov b, rdx
    mov rax, a
    mov rbx, b
    add rax, rbx
and not

Code Select Expand



    mov rax, rcx
    mov rbx, rdx
    add rax, rbx???
Less code and a tad faster, especially if run multiple times in a loop

[zedd151]

Okay, curiosity got the better of me so heres a test file. Testing the lib I created above, switched over to 64 bit for this. Success!

Code Select Expand

    include \masm64\include64\masm64rt.inc
    include ArithLib.Inc
    includelib ArithLib.lib
.code
entry_point proc
    invoke _add, 32, 64
    invoke MessageBox, 0, str$(rax), 0, 0
    invoke ExitProcess, 0
    ret
entry_point endp


end attachment removed as it has served its purpose

[TimoVJL]

Using SUBST is an easy way to shorten paths to obj-file.
Many use it for masm32/masm64 too.

[bluedevil]

.debugSS is in object-file and lib.exe (link.exe) just store it.

@TimoVJL so what is the way not to add this debug$S statement in obj file?

The path data does occur in the OBJ module but it does not appear in the final binary. Why is this a problem ?

@hutch-- unfortunately final binary still has those path info inside, you can check that out by using a hex editor:

Form library file.

Code Select Expand


Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  21 3C 61 72 63 68 3E 0A 2F 20 20 20 20 20 20 20  !<arch>./       
00000010  20 20 20 20 20 20 20 20 31 36 36 35 30 38 38 34          16650884
00000020  37 36 20 20 20 20 20 20 20 20 20 20 20 20 20 20  76             
00000030  30 20 20 20 20 20 20 20 32 32 20 20 20 20 20 20  0       22     
00000040  20 20 60 0A 00 00 00 02 00 00 00 B4 00 00 02 D6    `........´...Ö
00000050  5F 73 75 62 00 5F 61 64 64 00 2F 20 20 20 20 20  _sub._add./     
00000060  20 20 20 20 20 20 20 20 20 20 31 36 36 35 30 38            166508
00000070  38 34 37 36 20 20 20 20 20 20 20 20 20 20 20 20  8476           
00000080  20 20 30 20 20 20 20 20 20 20 33 30 20 20 20 20    0       30   
00000090  20 20 20 20 60 0A 02 00 00 00 B4 00 00 00 D6 02      `.....´...Ö.
000000A0  00 00 02 00 00 00 02 00 01 00 5F 61 64 64 00 5F  .........._add._
000000B0  73 75 62 00 5F 73 75 62 2E 6F 62 6A 2F 20 20 20  sub._sub.obj/   
000000C0  20 20 20 20 31 36 36 35 30 38 38 34 37 35 20 20      1665088475 
000000D0  20 20 20 20 20 20 20 20 20 20 20 20 31 30 30 36              1006
000000E0  36 36 20 20 34 38 36 20 20 20 20 20 20 20 60 0A  66  486       `.
000000F0  64 86 03 00 DB 3B 3F 63 40 01 00 00 09 00 00 00  d†..Û;?c@.......
00000100  00 00 00 00 2E 74 65 78 74 24 6D 6E 00 00 00 00  .....text$mn....
00000110  00 00 00 00 14 00 00 00 8C 00 00 00 00 00 00 00  ........Œ.......
00000120  00 00 00 00 00 00 00 00 20 00 50 60 2E 64 61 74  ........ .P`.dat
00000130  61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  a...............
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000150  40 00 50 C0 2E 64 65 62 75 67 24 53 00 00 00 00  @.PÀ.debug$S....
00000160  00 00 00 00 A0 00 00 00 A0 00 00 00 00 00 00 00  .... ... .......
00000170  00 00 00 00 00 00 00 00 40 00 10 42 48 89 4D 10  ........@..BH‰M.
00000180  48 89 55 18 48 8B 45 10 48 8B 5D 18 48 2B C3 C3  H‰U.H‹E.H‹].H+ÃÃ
00000190  04 00 00 00 F1 00 00 00 91 00 00 00 56 00 01 11  ....ñ...'...V...
000001A0  00 00 00 00 43 3A 5C 55 73 65 72 73 5C 41 64 6D  ....C:\Users\Adm
000001B0  69 6E 69 73 74 72 61 74 6F 72 5C 44 6F 77 6E 6C  inistrator\Downl
000001C0  6F 61 64 73 5C 4D 41 53 4D 33 32 2D 46 4F 52 55  oads\MASM32-FORU
000001D0  4D 5C 55 73 65 72 73 5C 62 6C 75 65 64 65 76 69  M\Users\bluedevi
000001E0  6C 5C 41 72 69 74 68 4C 69 62 5C 5F 73 75 62 2E  l\ArithLib\_sub.
000001F0  6F 62 6A 00 37 00 3C 11 03 02 00 00 D0 00 00 00  obj.7.<.....Ð...


Folks, I have checked that nasm-created obj files do not have this path info by default. So I wonder if I can do it with ML64 or at least if I can do it in final binary: the lib file?

@zedd151 thank you, I am already aware of that technique. As a last option I will use that.

[bluedevil]

Try building from main module file directory.

@HSE, can you expand this a little more? I think I couldn't manage that.

[zedd151]

@bluedevil ok. Was not aware that you had tried it already. 
I was also curious if it would work myself, as I did not know until I tried it.

[TimoVJL]

I think, that debug$S is needed by linker for rich header ?

[bluedevil]

I think, that debug$S is needed by linker for rich header ?

I am ok if that path is in OBJ file. Problem is, I don't want that path info in my "release build" of static lib. And I couldn't find a way to do it from the ml64/lib parameters. Only LINK.EXE has parameter of "RELEASE". Can link.exe make static libs?

[zedd151]

Have you tried using poasm rather than ml64 to create the .obj files...?
From here, doesnt add the path to the object files.
scratch that idea, unless poasm needs something that im missing. 
While poasm doesn't add the path strings to the .obj files, after creating the .lib file and linking the .lib file to a test program the test program crashed. No idea why as I don't have 64 bit debugger.