0

I am using TURBO Assembler with Dos-Box in a 64-bit system. It is working fine and compiling the programs as usual but whenever I try to use Turbo Debugger, it crashes.

I was thinking if there's any way I can use GDB debugger for debugging purposes. I'm using 64-bit Linux system.

Apart from that is there any way I can use the Turbo assembler directly with the command line? I am fed up of using Dos-Box continuously and whenever I try to use the assembler directly, it shows me this error:

screenshot from my desktop

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
Yatendra Rathore
  • 333
  • 2
  • 13
  • Is there a reason you need the assembler to be `TASM`? vs, say, `gas`? Are you cross-compiling for a PE/COFF platform from linux? – lockcmpxchg8b Nov 25 '17 at 06:27
  • @lockcmpxchg8b Actually I was learning gas previously from the book "Programming from ground up" but then I didn't got the working of stack. Then i came across the book "SAMS Mastering turbo assembler" and the stack explanation in it is beautiful and easy to grasp. Apart from that I am reading "The black book of virus" and every program is created in it using "Turbo Assembler" and whenever we debug using gdb, it basically shows the code in the same assembly used in TASM. – Yatendra Rathore Nov 25 '17 at 06:33
  • 1
    Ah, I see. Yes, there are two dominant ASM notations: "Intel" and "AT&T". gas uses AT&T by default, but according to wikipedia: "since version 2.10, Intel syntax can be used through use of the `.intel_syntax` directive". gas will produce objects that you can compile into C programs and use GDB for debugging. I'd try out the `.intel_syntax` thing with gas just to make life easier. – lockcmpxchg8b Nov 25 '17 at 06:36
  • @lockcmpxchg8b can you give me the link. That means I can run complete examples from this book in GAS ? – Yatendra Rathore Nov 25 '17 at 06:37
  • Oh, it looks like NASM defaults to Intel syntax, so that's another solid option – lockcmpxchg8b Nov 25 '17 at 06:39
  • NASM vs GAS: https://www.ibm.com/developerworks/library/l-gas-nasm/index.html Reference to GAS w/Intel syntax: https://en.wikipedia.org/wiki/GNU_Assembler#Criticism – lockcmpxchg8b Nov 25 '17 at 06:41
  • .intel_syntax noprefix (next line) "The intel assembly code goes here" (next line) .att_syntax (finish) You mean like this ? @lockcmpxchg8b – Yatendra Rathore Nov 25 '17 at 06:49
  • 1
    Loking through YASM (yet another linux assembler) I found it has a TASM parser. So it should accept your book's examples just fine. E.g., ` yasm --parser=tasm` – lockcmpxchg8b Nov 25 '17 at 07:01
  • 1
    @lockcmpxchg8b: NASM is Intel syntax, but it's a different flavour than MASM/TASM syntax. GAS with `.intel_syntax noprefix` is closer to MASM / TASM, except for the directives which are totally different. See https://stackoverflow.com/tags/intel-syntax/info for some of the differences (there's a paragraph about NASM vs. MASM after the AT&T vs. Intel section) – Peter Cordes Nov 25 '17 at 07:35
  • 1
    @lockcmpxchg8b: I assume the book's examples use some DOS `int 21h` system calls, which won't run natively under Linux. It's probably also 16-bit code, which again won't work under Linux even if you build it as 32-bit. (e.g. `mov bp, sp` / `mov ax, [bp+4]` will segfault because truncating the stack pointer to 16 bits does not result in a valid pointer.) – Peter Cordes Nov 25 '17 at 07:37
  • 1
    @YatendraRathore: I'd recommend against learning 16-bit x86 as your first assembly language. Segmentation makes things messy, and the DOS / BIOS system call API is totally obsolete. Programming from the Ground Up is a good book, and it's free. It uses 32-bit x86 on Linux, so you're all set for that. See links in the [x86 tag wiki](https://stackoverflow.com/tags/x86/info) for links to it, and to [an answer I wrote about ways to learn asm](https://stackoverflow.com/questions/34748733/drawing-a-character-in-vga-memory-with-gnu-c-inline-assembly/34918617#34918617) – Peter Cordes Nov 25 '17 at 07:40
  • 1
    @PeterCordes OMG. I had forgotten DOS was 16-bit. You are absolutely correct. I wasn't thinking the examples would be system programming, but YatendraRathore did mention it was from a Virus-writer's perspective. – lockcmpxchg8b Nov 25 '17 at 08:01
  • 2
    @YatendraRathore: sorry, I led you down a rabbit-hole. PeterCordes is absolutely correct that your examples are probably very tightly coupled to DOS, so you're chained to DOSBox for them. – lockcmpxchg8b Nov 25 '17 at 08:03
  • 1
    @PeterCordes Thank you so much and I was unable to tag you in my question before. I am using "Programming from ground up" but I'm not getting the stack explaination. – Yatendra Rathore Nov 25 '17 at 08:08
  • @lockcmpxchg8b Thank you for your guidence too, It's okk we all are learners here :) – Yatendra Rathore Nov 25 '17 at 08:09
  • 1
    Oh, you were the person that asked https://stackoverflow.com/questions/47448283/how-do-function-calls-work-in-x86-32-bit-assembly-on-linux the other day. I knew I'd just answered a question about stacks and the PGU book recently, so I was going to link it to you... >. – Peter Cordes Nov 25 '17 at 08:12
  • 1
    Well, if the other books has good explanation of stack, you already understand it? Then you should be able to return to the first book, and the stack description may be understandable this time? It's the same stack, same CPU, just different modes (16b vs 32b), so things like offsets and data sizes change, but if you understood the principle, it should work for you. Try to re-read it again, if it's still not clear enough, with you new knowledge from 16b DOS book. ... about turbo debugger -> that's DOS executable, so you must run it in dosbox. It shouldn't crash (works for me, TASM v4.1, TD5.0). – Ped7g Nov 25 '17 at 12:38
  • And vice verse, I'm not aware of gdb version for 16b DOS, so you can't run gdb inside dosbox. You also can't execute your TASM executables inside linux (under gdb), they are only for DOS. Gdb would be probably usable in some remote-debugging scheme, having the binary run under some DOS system supporting remote debugging, and gdb being outside (remote) to oversee it, but generally linux gdb would have hard time to cope with 16b mode, so you wouldn't gain much from such complex setup. – Ped7g Nov 25 '17 at 12:41
  • @Ped7g Actually I followed the same technique and I understand the working of stack now :) – Yatendra Rathore Nov 25 '17 at 14:17

0 Answers0