Screenshot of my code and registers from SPIM
Trying to make a Hello World program that deals with input, but I'm running into a "Memory address out of bounds" error when trying to print out said input.
I've tried changing line 14 to move $s0, $a0 and the program runs and exits successfully, except it's printing prompt in place of where I want user input... So I end up with "Hello... Nice to meet you, What is your name?\n!" instead of my desired outout: "Hello... Nice to meet you, \n!"
Related
I am trying to learn how CUPS is implemented.
I see that the first step in the chain is to submit a PS to the pstops filter, which takes the PPD and shall return another PS for pstoraster.
I have read the source code for pstops but it is not very commented and I am struggling to:
understand if launching pstops from command line specifying a PS file is possible at all.
understand which shall be used for the rest of parameters:
job-id
user
title
copies
options
understand specifically where shall I include the path to the PPD file of the printer that is intended to be used later.
I have compiled a simple binary file (hello.bin) and stored it on a memory card.
I am running a NXP Sabre dev kit with i.mx 6 quad processor. I have started up U-boot and am trying to access the binary file and make it run.
The hello.bin is availiable because the following command works:
=> fatload mmc 1:4 0x20005000 hello.bin
reading hello.bin
The way I understand it the file should be loaded into RAM at the address 0x20005000
So I want to test that the binary is there
=> md 0x20005000
20005000: 464c457f 00010101 00000000 00000000 .ELF............
20005010: 00280002 00000001 00010315 00000034 ..(.........4...
20005020: 000028f4 05000400 00200034 00280009 .(......4. ...(.
20005030: 00240025 70000001 00000454 00010454 %.$....pT...T...
Looks all right, as the starting bits are matching the file I copied to SD-card.
When I try to start the binary, the device reports undefined instruction:
=> go 0x20005000
## Starting application at 0x20005000 ...
undefined instruction
pc : [<20005158>] lr : [<4ff71403>]
reloc pc : [<e7897158>] lr : [<17803403>]
sp : 4f56dd50 ip : 00000000 fp : 00000002
r10: 4f56f938 r9 : 4f56deb0 r8 : 4ffc3c40
r7 : 4ff713d9 r6 : 00000002 r5 : 20005000 r4 : 4f56f93c
r3 : 20005000 r2 : 4f56f93c r1 : 4f56f93c r0 : 00000000
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
Thanks for your help
Please, find an example at https://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.1.
go does not expect the start of an ELF binary but the address of the entry routine. If you want to access U-Boot routines the binary must have been relocated.
I have compiled a simple binary file (hello.bin) and stored it on a memory card.
You have omitted many salient details.
How did you compile this program, e.g. what toolchain, what makefile?
Did you link this program with a library?
The way I understand it the file should be loaded into RAM at the address 0x20005000
How did you get this "understanding"?
Typically the load address of a standalone program depends on a few factors.
First the addresses of available memory (on the target board) has to be considered.
Second, unless the standalone program is relocatable (not likely in your case), then the program must be loaded at its load/starting address as defined when the program was linked.
The load and starting addresses of a program can be obtained from its map file (i.e. the linker output).
When I try to start the binary, the device reports undefined instruction:
That is what happens when the ELF header is "executed".
Since the file clearly contains an ELF header, its filename extension should be .elf rather than .bin.
How did this executable file get the misleading name?
You probably did not build a standalone binary image file.
The examples/standalone/ directory of the U-Boot source code has sample code and a makefile for building standalone binaries, e.g. a hello_world.bin.
Be sure to properly define CONFIG_STANDALONE_LOAD_ADDR for your board!
The default load address is surely to be inappropriate.
the => bdinfo, command told me something about the DRAM bank, starts at 0x10000000 (7 zeros) and ends at 0x4000000.
(First of all, do not put salient information in comments. Add this to your original post by using the edit capability.)
The "information" you provided makes no sense (i.e. the end address is less than the start address). Avoid interpreting the information, and instead simply present (copy'n'paste) the actual output.
I then used fatload mmc 1:4 0x10005000 hello.bin instead, which then seems to work. I guess I was writing to a out of bound address.
The fatload command merely copies the contents of a file into memory. The true success of that copy is confirmed by validating the memory, rather than completion of the command.
Your comment is confusing since you have not mentioned any prior load issues.
go 0x10005000 still does not work.
Trying arbitrary load/start addresses is not an effective debugging technique.
A summation of "seems to work" or "still does not work" is a low-quality description for results.
See How To Ask Questions The Smart Way.
Got some help from another friend, I found it very helpful so I will post it:
You can use the Yocto toolchain but you cannot link against the C library (which is done by default) so you have to put some extra options to GCC to let it know that, also, you cannot use the go instruction from U-Boot to jump to an ELF binary that you just loaded in memory, the ELF binary has to be converted to a 'raw' binary (list of ARM instructions in your case) with the tool objdump. An ELF binary it's a specific format that encapsulate your code/your data and some extra information, and the first part of the ELF is the description of the binary, so right now, when you do a go at the first address, you are trying to tell the CPU to execute something which is not an ARM instruction. You basically want to execute what we call the '.text' section of the ELF binary.
5893.1
Hi all,
I have searched and got answers for my questions many times from this forum. However, I now have a question that I don't think anyone has asked before.
We use Windows DOS batch to compact MS Access 2010 DB files everyday. It seems Access does not pass any return code to DOS. So my question is: Is there a way to tell whether the compacting is successful or not from within the batch?
We use Win XP/7 machines for development, and Windows Server 2008 for production. We are running MS Access 2010.
The DOS batch has a line like "D:\Microsoft Office\Office14\msaccess.exe" %DBLoc%%BkupFile% /compact %DBLoc%%DBFile%
Any help is much appreciated.
Doesn't appear that there is a return code.
However, one time-tested technique is to pipe the output from the command to a text file and then test the contents of the text file. That way, if there's an error message printed at least you'll be able to catch that.
eg. add ' > test.txt' to the end of the command line.
You'd have to check on the available command shell tools to read the text.
You may also have to specifically redirect the error output separately from the command output. see here for redirection info : http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true
Edit: to head off the next question, some links on detecting the failure message in the text file
http://ss64.com/nt/findstr.html
How to set variable with the result of findstr
I'm trying to build a small expect script to reboot my Cisco VCS devices. However once logging into the device it doesn't have any prompting characters so I'm unsure how to initialise a send request
Example Prompt:
So far I tried
expect "OK/r"
send "command"
expect "OK/r/r"
send "command"
experimented with timeout but unsure how it works.
I also tried the autoexpect tool and it showed a weird character [?1034h" at the prompt which I tried including.
Any help would be appreciated
I would think you should be able to expect the OK plus one or both of newline or carriage return. But you need backslashes for that, not forward ones. I would try "OK\r" or "OK\r\n".
Here's what you need to do: include expect_internal 1 somewhere near the top of your script, then run it again. Expect will give you a ton of information on what it is and it is not matching. That should show you what it's receiving, and you will be able to craft your expect statement accordingly.
If you're unsure, edit your question to include the debugging output and I will try to help.
I've googled around but i'm not sure i am asking the right question or not and i couldn't find much regardless, perhaps a link would be helpful.
I made a c++ program that shows a message box, then I opened it up with Ollydbg and went to the part where it calls MessageBoxW.
The call address of MessageBoxW changes each time i run the app as windows is updating my Imports table to have the correct address of MessageBoxW. So my question is how do i find the virtual addres of MessageBoxW to my imports table and also how can i use this in ollydbg?
Basically I'm trying to make a code cave in assembly to call MessageBoxW again.
I got fairly close once by searching the executable with a hex editor and found the position of the call, and I think I found the virtual address. But when i call that virtual address in olly and saved it to the executable, the next time i opened it the call was replaced with a bunch of DB xyz (which looked like the virtual address but why did the call get removed?
Sorry if my terminology is off as i'm new to this so i'm not quite sure what to call things.
(reply to comment on original post)
Ah, no, the address specified in the "call" opcode is relative to the call instruction. However, for imported functions, it's most likely an indirect call (which reads the function's address from a memory location).
There is really no "official"/reliable way to get the address of any function without having no access to the import segment. If you are patching a certain executable, just look at the values Windows places in its import segment. If you are injecting code from another process, you can rely on the fact that the address of a function in a system DLL will remain the same, relative to the DLL's load address. It is also possible to manually locate and parse the program's import segment in memory.
1- find address of message box in your executable module. suppose your exe file is a1.exe
Executable modules > select a1.exe > press ctrl + N and find the address of message box. suppose address is 00402008
2- use ff25 08204000 machine code to call message box but before push parameters and push your EIP for returning address.