I'm sorry about the weird snippets. I won't be able to paste the exact code.
The following list from an ELF file shows addresses and commands at them.
0x4000XXXX: [someInstr] [someReg], [someReg2], [someReg3]
0x4000XXXY: [someInstr] [someRegValue], [somereg3]
0x4000XXXZ: [jumpInstruction] [someReg3] + 0xXXX, [someReg4]
0x4000XXXA: [someInstr]
0x4000XXXB: [someInstr]
0x4000XXXC: [someInstr]
0x4000XXXD:
The third instruction adds 0xXXX [which is some address value] to value in someReg3 register. Going there,
0x4000YYYY: [someInstruction]
0x4000YYYZ: [someInstruction]
0x4000YYYX: [someInstruction]
0x4000YYYA:
we see that the execution will stop once 0x4000YYYA address comes up as it is blank. [The instructions above it are all linear ones like OR, AND etc.]
My question is, why are the blanks even there?
In the example I gave above, I have no idea where the exact "ending" instruction resides, but using nm -S [filename] and readelf -l [filename] I was able to estimate 2 end points. Unfortunately, those addresses have unimplemented instructions and it causes interruptions in the program. The file has quite a lot of blank spaces but I've only included 2 for an example. These blanks are interrupting the program I'm running. Even if I skip the execution at these addresses, I have no idea where to stop.
Related
I am utilizing Pick Basic on the uniVerse operating system. Many times, I will need to watch a variable change during a debugging session. I will locate the variable throughout the program and note every time it can possibly be modified. I will then go into the program and during its execution, I have the program display the value of the variable on the screen along with the line number of the source code. For argument's sake, let us say that the variable name is begdate and in this case, on line 146, I set it to today's date. I will add the proceeding line:
146: begdate = DATE()
147: DISPLAY "Line 147: ":OCONV(begdate,"D4-")
This works just fine. But, if the program can possibly change this variable on many different lines, once I start adding or subtracting lines to the source code, the display is usually not displaying the correct line number anymore because the line number is hardcoded.
Does Pick Basic have any system variable that captures the line number of the source code so that:
I do not have to keep going back and changing the hardcoded line number and better yet,
I do not have to hardcode the line number at all.
Welcome to StackOverflow! The answer to this is in the UniVerse BASIC User Guide V11.3.4:
https://docs.rocketsoftware.com/bundle/UniVerse_BASICUserGuide_V1134/resource/UniVerse_BASICUserGuide_V1134.pdf
Ref page 63 on Debugging Tools (RAID) and the M command to set watchpoints on variables.
A watchpoint condition occurs when RAID monitors a variable until the variable’s value changes. The
program then suspends operation and displays the variable’s old value, its new value, and the source
instruction that caused the change to occur
The command is entered at the :: prompt, within the debugger. You can enter the debugger with a DEBUG statement in your code or by breaking into it at runtime. You can also use the command RAID BP ProgName.
Another way to go about this is to compile with -X option so that you can get see where variables are referenced. See page 35 from above.
When I debug like this in BASIC, I tend to use names, not line numbers, to indicate what the code is doing, not where it is. So the code would look more like this:
147: DISPLAY "Initializing Beginning Date: ":OCONV(begdate,"D4-")
Now the line can move and you'll still be able to find it easily with the unique text. You can also use simpler unique text like this:
147: DISPLAY "BEGDATE_INIT: ":OCONV(begdate,"D4-")
Use whatever pattern seems comfortable.
Be sure begdate isn't EQUated to a dynamic element or some other variable. If, for example, EVENT<3> is equated to begdate the debugger tracing the specific variable name might not pick up on EVENT<3> or EVENT<Beginning_Date> being modified.
I am not aware of a specific #VAR or other runtime mechanism in UniVerse that will return the currently executing line number back to the BASIC code so that you can DISPLAY "Current line is ":#LINE.
In D3 I peeked into the local workspace and the current stack trace.
Someone with more current UniVerse expertise might be able to cite a specific function, #VAR, user exit, or other mechanism for this. It's possible that the feature you're looking for is only available in a later platform.
Rocket Support will help with this question : Support Agreement should not be necessary to ask a simple question like this. If that's not an option, check the forum on the Rocket site, or one of the community forums. I can provide links if required.
I'm talking about this things:
warning: ds segment base generated, but will be ignored in 64-bit mode
I know that -w option can be used to suppress warnings in NASM, but from the list of warnings showed by the help menu nothing fits this type of warning. And -w-all gets rid of everything, except this.
Any way of doing this?
Since that particular error doesn't seem to be one of the suppressible ones (as you've stated, I'd just use sed as a post-processing step, piping the output through something like:
sed '/^warning: .. segment base generated, but will be ignored in 64-bit mode$/d'
Even if you're using nasm on Windows, you can still get the GNUWin32 port of sed to do the job.
And before you complain about this being a kludge, you should know that some of my greatest achievements were kludges, and many of them have out-lived my more well-designed code.
:-)
I have been stuck for a while on a statement that causes a segmentation fault when commented out, from some of the information about this that I gathered people were saying that my stack was getting corrupted somewhere or somehow.
http://pastebin.com/NT8PGPi0
the code that cause the segmentation fault line number 511 (sorry for all the newlines linux didn't like when I copied it out of the editor)
basically with this project it should be able to print a .txt to the screen with different options chosen by the user for instance
./a.out --delete=c // deletes all the c's in the file and spots it to the console
./a.out --line-numbers // posts all the line numbers in the console
so on and so forth with the long options, same with the short options.
As was mentioned, the best option in such situation is always debug code by gdb or another debuger. But as a small hint. Look at this in Opt_Args function:
*c = getc(fp);
And then look at manual for getc:
int getc(FILE *stream);
I have opened an executable in IDA Pro, and found the location I want to break at, 0x3390 from the beginning of the file.
How do I set a breakpoint in lldb at the memory address, start of program + 0x3390.
I tried b s -a 0x3390 but it doesn't work, I presume because I need the actual address, not the offset.
The image list command will show the load address of the __TEXT.__text section of all the executables loaded in the program. If you need more information, image dump sections will dump the addresses of all the sections. From this you should be able to figure out what to offset your address with. Note that the program may not load at its pre-run address, so you may have to figure out the base address after you've started up.
Then you should be able to say:
(lldb) br set -a <FileAddress>+<Address>
Note, b is an alias for some fancy regular-expression based command that tries to emulate the gdb breakpoint expression parser, so you either need to disable that alias or use br to get the full breakpoint command.
I have a problem here...
I'm using debug (in cmd/ms-dos) to learn some things and to peforme some commands... I set AX to 1234 and DX to ABCD.
So, I did '-a 100' to register a instruction, I did: mov ah,dl
And them "-g" (because I set an interruption) or "-g 102" to peforme the instruction and stop before 102 offset (if I not set the interruption).
When I peform -r to show me the registers values, they remain unchanged, this should be AX:CD34, but AX is 1234 yet, looks like the MOV command doesn't works... what am I doing wrong?
http://img203.imageshack.us/img203/4866/movdxdldoesntworks.png
(sorry for the link, I need reputation to post image)
I also would like to know if exists something like Windows Debug to Linux, I mean, I have nasm and yasm in my Linux installation (Debian-based), but it's just a compiler, I need to write the code into a file, and compile it to run, we have some "emulator" or "debug" tool for ASM in Linux? Like the Debug windows software in the picture above?
The last thing, sorry to make the message so long with 3 questions, but I don't want to "flood" with a lot of topics, so, my last question is where can I find some kind of list of interruptions? I would like to find some list or manual with machine code functions. In Peter Norton's book, for example, when I have "02h" in the "AH" register, I tell to DOS to print one character in the screen, and he said "if you want to find a list of functions, you can look your DOS manual", well, I can't find this dos manual (in linux we can type "man" and we have manuals for everything), the windows "help" function is only a list for simple commands, not a real manual like the unix "man".
I try to find it in google, but every "DOS manual" did I found only show me simple functions like "cd, dir, format, time, blablabla", nothing real technical about the system or something... Can you help-me in find some complete list of "AH" commands and functions?
I know INT 18h is for run Basic and INT 19h restarts the computer (a guy said to me, 18h for him doesn't run basic but restarts the computer instead of INT 19h). I also find 2 or 3 more occurrences in Google, but not a "complete" list, someone have it?
Thanks for the help, patience and attention, I love you! ;)
Please try it again with:
.g=cs:0100 0102
http://www.armory.com/~rstevew/Public/Tutor/Debug/debug-manual.html
.........
RBIL: Ralf Browns x86/MSDOS Interrupt List
http://www.pobox.com/~ralf
http://www.pobox.com/~ralf/files.html
ftp://ftp.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/
Dirk
It is hard to say why it does not work in your debugger.
Did you try to just type this in your program and put breakpoint at the end of it to see the result?
Here is an answer to the question about linux debugger (they recommend GDB):
Linux Assembly Debugger
For the third question here you have a good source of info about interrupts: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html
In case link gets outdated search for "Ralf Brown's Interrupt List"