2

I have an application that was originally developed using NASM under a Linux operating system. I ported that (still Using NASM) to a Windows operating system. Because the system was difficult to debug, I am 9/10 thru converting the code to MASM syntax and using VisualStudio for debugging. All has gone well up until now.

I have come across a problem where memory address's appear to be overlapping and am not able to explain why. I have the following coded:-

COMMON.obj
.DATA?  
savedRegisters  dq 384 dup(?)

Common.obj is held in a statically linked library NAME.LIB

V2.10.obj  + NAME.LIB to create executable
.DATA?
 ALIGN 8
 RandomNos  dq 1000000

Addrdess during debugging

RandomNos       0x000000013FE106A0
savedRegisters  0x000000013FE106C0

RandomNos is only 32 bytes from savedRegisters, hence savedRegisters is overwritten when populating RandomNos

Can anyone suggest a reason for this and hence a solution ?

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
roger tunnicliffe
  • 69
  • 6
  • 1
    You've defines `RandomNos` as a `dq` wth value 1000000. That takes 8 bytes. There is enough space between both memory addresses to write an 8 byte DQ. `savedRegisters` is 384 bytes at address 0x13FE106C0 and above. – Michael Petch Jul 19 '21 at 03:56
  • dq defines quad (8 bytes) * 1000000 = 8000000 bytes – roger tunnicliffe Jul 19 '21 at 04:28
  • 1
    No `dq 1000000` creates a single quadword with the value 1000000. Maybe you meant to use DUP? Maybe `RandomNos dq 1000000 dup(?)` – Michael Petch Jul 19 '21 at 04:30
  • 1
    My apologies, you are correct. Randoms dq 1000000 dup(?) is correct. Or should it be RandomsNos 1000000 dq ? – roger tunnicliffe Jul 19 '21 at 04:33
  • 1
    It has to be `RandomNos dq 1000000 dup(?) ` – Michael Petch Jul 19 '21 at 04:43
  • 1
    Thank you Michael. I must say I struggle a little bit with the MASM syntax after quite some time with NASM. Thanks again. – roger tunnicliffe Jul 19 '21 at 04:51
  • Can you use VS's debugger (in pure disassembly no-source mode if it has one) with binaries build from NASM? If you have working NASM source, it seems like a lot of inconvenient work to port it to MASM, and makes it harder to maintain both versions (i.e. new features, optimizations or bugfixes) if they no longer share any source files. I agree that having a good debugger is essential for asm, but porting a bunch of code to MASM syntax would not be my first choice in an effort to make that happen. – Peter Cordes Jul 19 '21 at 05:05
  • The situation is a little more complicated. I have developed my own language and it is the new language source that requires a working debugger. NASM does not produce the information needed to enable my own language to be debugged but MASM/LINK will. This gives me a source level debugger for my language. Yes, I agree it is painful to have 2 versions of the code (although the Linux calls and the Windows calls mean that some sort of duplication is necessary). – roger tunnicliffe Jul 19 '21 at 05:53
  • PREVIOUS POST WAS TOO LONG - continuing I could perhaps work backwards and assemble the MASM code using JWASM on Linux but to be honest, as evidenced by the mistake you pointed out, I find the MASM syntax confusing. – roger tunnicliffe Jul 19 '21 at 05:53
  • I have never experienced difficulties to debug PE with [OllyDbg](http://www.ollydbg.de/). It can load symbol tables from COFF object modules, so in CPU panel of debugger we can see disassembled code with the correct symbol names. – vitsoft Jul 19 '21 at 06:00
  • Sadly, I had previously used x64dbg (a relation of OllyDbg) and it could not show my source nor act as a source level debugger for my own language. It's failure is what actually prompted the decision to port across to MASM – roger tunnicliffe Jul 19 '21 at 06:23

0 Answers0