6

I'm using the Insight debugger on my 64-bit Mac-to-Linux computer.

It's telling me that the result of mov ebx, 1739 is 0xcc00cccb in EBX. EAX gets 0x1bf as expected, but the multiply result is also weird (when it should fit into a 32-bit register).

global  _start          

_start:

nop     

    mov eax, 447
    mov ebx, 1739
    mul ebx

nop

Please, somebody tell me what is going on. I couldn't even declare a databyte string without it doing a similar effect of adding several c's at higher-order nibbles to any hexadecimal produced by any mov or mul instruction, to whichever register is declared first. I use the NASM assembler.

EDIT: My two terminal entries to assemble and link are:

nasm -f elf -g -F stabs test.asm -l test.lst
ld -o test test.o -melf_i386
Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
ABC DEF
  • 91
  • 6
  • What's the result after the `mul`? – Eric M. Nov 17 '16 at 04:34
  • eax gets its value changed to 0x35659675, edx goes from 0x0 to 0x164, and eflags also changed but I just assume that that is the carry flag. – ABC DEF Nov 17 '16 at 04:36
  • And are you compiling this as a 64-bit program or 32-bit? – Michael Petch Nov 17 '16 at 04:40
  • My two terminal entries are: nasm -f elf -g -F stabs test.asm -l test.lst ....and.... ld -o test test.o -melf_i386 – ABC DEF Nov 17 '16 at 04:41
  • what do you mean by 64-bit Mac-to-Linux computer? – Michael Petch Nov 17 '16 at 04:51
  • Well my Mac laptop that I'm using originally used the Mac hardware. After converting to Linux, my computer still retained its 64-bit infrastructure, causing my terminal entries to change to compensate for this (the elf_i386 indicates that my computer is 64-bit). – ABC DEF Nov 17 '16 at 04:54
  • So you are just running Linux on a 64-bit Mac? If so what distro/version of Linux? – Michael Petch Nov 17 '16 at 04:56
  • Thank you for wording it the way I should have. Yes, I am running Linux on a 64-bit Mac. – ABC DEF Nov 17 '16 at 04:57
  • You using the debugger correctly? Which debugger? – Michael Petch Nov 17 '16 at 04:58
  • I am using ubuntu 16.04 LTS. – ABC DEF Nov 17 '16 at 04:59
  • I am using Insight, following the instruction of this blog post since Insight was removed from default applications of this version of Linux. http://www.dalfonso.co/blog/2016/04/23/setting-insight-debugger-on-ubuntu-16-04-lts/ – ABC DEF Nov 17 '16 at 05:00
  • Haven't used it, but I asked about the debugger you use because I'm wondering if the problem is with the debugger itself. What do you get if you use GDB or DDD (ddd is a simple GUI ontop of GDB).. Are you debugging the right program? – Michael Petch Nov 17 '16 at 05:09
  • I am not familiar with how to use GDB, so I will do some research to run it and see what happens, before returning the result to you. – ABC DEF Nov 17 '16 at 05:15
  • You might find `ddd` easier than just `gdb` if you aren't use to the command line. `ddd` is available on Ubuntu, install with `sudo apt-get install ddd` – Michael Petch Nov 17 '16 at 05:18
  • `-F stabs`?? Are you sure that isn't confusing gdb? Try `-F dwarf`. – Peter Cordes Nov 17 '16 at 05:20
  • 3
    I got it running. You are absolutely correct. It is the Insight debugger. GDB says the ebx register is 0x6cb which is equal to 1739. Thank you so much! I will get DDD if it is easier than GDB (I prefer to have an interface to facilitate navigation) – ABC DEF Nov 17 '16 at 05:23

1 Answers1

0

It turns out for anyone who might be running Ubuntu 16.04 LTS that if you made the attempt to "get back" Insight which was removed from this Ubuntu's default application set, by way of the method suggested on a blog post: http://www.dalfonso.co/blog/2016/04/23/setting-insight-debugger-on-ubuntu-16-04-lts/, you will not actually be getting the application you were hoping for. It has missing pieces.

On the surface (interface), this may appear to work, but it may be only doing patchwork which doesn't fully regenerate the app.

The real reason has everything to do with an inner malfunction of my computer somewhere which, for unknown reasons, could not allocate values to registers correctly if the folder name in which the assembly files were kept was named "assembly".

ABC DEF
  • 91
  • 6
  • 1
    I have a Ubuntu 16.04 LTS system here. I followed the instructions exactly on that webpage and when I ran `insight` on the executable, and stepped through the program the registers had the proper values, and the _MUL_ had the proper result. – Michael Petch Nov 17 '16 at 06:17
  • So then why on Earth am I getting such a bizarre response from Insight, and not from GDB? Are you assembling and linking the .asm file the way I did? – ABC DEF Nov 17 '16 at 06:31
  • Would it be advisable to do this over screen-share? I'll happily share my screen with you. Apology in advance if such a proposal is against the rules. – ABC DEF Nov 17 '16 at 06:52
  • I'm not in a position to do the remote screen sharing at this time. I used your exact commands to assemble and link and then used the command `isight test` to debug. I used the exact source code you posted as well. – Michael Petch Nov 17 '16 at 06:58
  • OOH! I know why! My executable has to be in the same directory as the home of the cloned repository. Can you lend an explanation as for why this must be? – ABC DEF Nov 17 '16 at 07:03
  • 1
    When I did it I assembled and linked it to an executable outside the directory where I build insight. Did you do a `sudo make install` when you finished building `isight`? . Something else you may wish to do is make sure the program you are debugging is in the current directory. For example it might have been better to do `isight ./test` forcing isight to use the program `test` in the current directory rather than potentially using the system defined one in `/usr/bin/test` – Michael Petch Nov 17 '16 at 07:08
  • Behind the embarrassment is the opportunity to learn. Everything works fine now that I have moved the executable to the home of the cloned repository. – ABC DEF Nov 17 '16 at 07:19
  • 1
    You don't need to run it from the directory where the repository is. On my system I put your code in a completely different folder, assembled it linked it, and the executable was not in the repository folder. So I think you are still doing something wrong. – Michael Petch Nov 17 '16 at 07:19
  • Even stranger: as soon as I move the executable into my "regular" assembly workspace folder which contains the .o file and .asm file, that is when the error occurs. If I move it outside of the folder, say the home directory, it works as it should. – ABC DEF Nov 17 '16 at 07:25
  • Do you have another copy of `isight` in your `$PATH` somewhere? You know that you have to run `./isight` to run the executable in the current directory, right? Try `type -a isight`, and/or `ldd /path/to/isight`. – Peter Cordes Nov 17 '16 at 07:28
  • I'm not sure why you keep calling it "isight". Isn't that a typo for "insight"? – ABC DEF Nov 17 '16 at 07:29
  • Just a typo. isight is the name of another product so is on the tip of my fingers. Anywhere that I said `isight` I meant `insight` – Michael Petch Nov 17 '16 at 07:30
  • Is there any readily explicable reason for why it cannot work properly inside my main assembly directory that houses all my assembly work? We're getting closer! I've found consistency! – ABC DEF Nov 17 '16 at 07:31
  • Does your main assembly directory (the complete path shown by `pwd`) have a space in it by any chance? I ask this because there is software out there that gets confused if the path of a file contains a space character. May not be the case here, but worth a shot. – Michael Petch Nov 17 '16 at 07:32
  • It does not appear to. I'll copy and paste the output "/home/gewurztraminer/assembly" – ABC DEF Nov 17 '16 at 07:34
  • Any special characters (accents etc) in your user name? – Michael Petch Nov 17 '16 at 07:35
  • No. I set Gewurztraminer to be capitalised when starting Ubuntu but that is lower-cased in the path names. – ABC DEF Nov 17 '16 at 07:38
  • The folder name cannot be named "assembly"... That is the reason why it is causing the error. Put the .o, .asm, and executable file into a folder titled assembly and see what happens. – ABC DEF Nov 17 '16 at 07:47
  • I actually created a user called `gewurztraminer` and then created a folder under that user called `assembly` and it worked – Michael Petch Nov 17 '16 at 07:48
  • Possibly there is something else in your `assembly` directory causing issues. – Michael Petch Nov 17 '16 at 07:48
  • Wait, so you created a folder called "assembly" and it still worked? I cannot go any further than this. I've narrowed the cause down to the atom on my end. It will work in any folder but one named "assembly". – ABC DEF Nov 17 '16 at 07:50
  • That cannot be true, since I've deleted the "assembly" directory, created another of the same name, with the same continuing problem. I then made another directory of a different name and it works fine. – ABC DEF Nov 17 '16 at 07:51
  • I used a directory called `assembly` yes. One possibility I wonder is if you have a rogue debugger running in the background that hasn't closed one of your files. You could always try rebooting your system and see if the issue persists in that `assembly` directory. In my case `/home/gewurztraminer/assembly` is where things work. – Michael Petch Nov 17 '16 at 07:51
  • No. I rebooted and the issue still persists in any folder titled "assembly". – ABC DEF Nov 17 '16 at 07:59
  • Remove all the files in that directory (copy them somewhere else) and then put your asm file in there, assemble and link it. There is more to this – Michael Petch Nov 17 '16 at 08:01
  • The issue still persists in the "assembly" folder. – ABC DEF Nov 17 '16 at 08:04
  • What happens if you remove the `assembly` folder complete, create a new `assembly` directory put your asm file in it and then assemble/link. That would be the last test I can think of. But I'll tell you now. I created a user called `gewurztraminer`, created an `assembly` directory under that user (full path `/home/gewurztraminer/assembly` ). Put your asm file in it/compile/link and then ran it with `insight test`. Have you tried the previous recommendation of using `insight ./test` instead. Maybe you are starting `insight` differently than I am? – Michael Petch Nov 17 '16 at 08:08
  • Yes. I've created a new assembly folder and redid the compiling and linking, trying both insight ./test and insight test. I think this might be an internal malfunction in my computer? Every time I restart I get random errors appearing along the way from "___ cannot connect to address 2" to errors that notify me when desktop freshly opens. I am beyond baffled at this. I'm not even embarrassed anymore this is just strange. – ABC DEF Nov 17 '16 at 08:15
  • I don't get any such errors on my desktop. Sounds like something not quite right on your system. Maybe you missed something when building insight. Hard to say. I only know on my 16.04LTS system it does work, and I guess we'll have to leave it at that. – Michael Petch Nov 17 '16 at 08:16
  • I am experiencing a similar problem on my PC's Ubuntu 16.04, but my folder is named "sandbox". If I use another folder, the problem doesn't come up. Although a solution has been accepted, for the sake of knowledge/understanding, I would like to know why this is happening. I wonder if the strikethrough'd part of the accepted solution might have some validity. – Arya Dec 31 '16 at 06:58