Example code:
int main () {
printf("Hello world begin\n");
// New instruction
__asm__ __volatile__ (".byte 0x0f\n\t"
".byte 0xd0\n\t"
:);
printf("Hello world end\n");
return 0;
}
My problem [TLDR] :
Make QEMU treat my new instruction similar to return 0; [sys_exit]
My purpose:
I am trying to customize the QEMU emulation of x86 ISA to log some data (like number of ring transitions etc) during CPU emulation between two points. Assume for simplicity, the start will be after the first printf (or some syscall) and end will be marked by a new instruction that I have written (say opcode '0f d0' which is unused in Intel ISA) whose purpose is to simply print those log information and terminate the process there (in line 2) and without executing the rest of the lines. In other words, the behavior should be identical to a scenario where 'return 0;' was placed right after my new instruction.
In my QEMU helper logic, I tried to add cpu_loop_exit() and all other combinations, they seem to loop infinitely. Can anyone point me how to achieve the behavior I want (with only modifying QEMU and not my example code) ?
Related
My program is supposed to emulate external device that is usually connected via COM port (/dev/ttyUSB0). The program opens a pty and waits for commands. Here is the code:
HostPty::HostPty(const string & HostPty_name)
{
char name[100] = {0};
int res = openpty(&_master, &_slave, name, NULL, NULL);
printf("Name: %s\n", name);
}
string HostPty::nextString()
{
static const int BUF_SIZE = 4096;
char buf[BUF_SIZE];
size_t idx = 0;
while(true)
{
// Read symbols one by one until new line is found
size_t received_size = read(_master, buf + idx, 1);
printf("Received a symbol: %02x\n", buf[idx]);
// Stopping at new line
if(buf[idx] == '\n')
break;
idx++;
}
return string(buf, idx);
}
To test this code I am using miniterm.py terminal emulator connecting to /dev/pty/6 (or whatever is created with openpty) and send text commands over there.
When I type commands manually everything works fine - I receive chars one by one as expected. But when I paste a piece of multiline text this code receives only first byte until I put a new line symbol (even though there are multiple newline symbols in the text I paste).
Any ideas how to fix that?
Any ideas how to fix that?
I don't know which kind of Unix you have. I just tried to reproduce your problem under Linux; but pasting lines work fine on my computer so I cannot reproduce the problem.
If your Unix variant has a system call tracer (Linux: strace, SunOS/Solars: truss, FreeBSD: strace, MacOS: dtruss (?)), I'd trace the system calls:
strace -f -o file_myprog.out ./my_program
miniterm /dev/pty/6
(Note the -f which means that the system calls of sub-processes created by fork() are also debugged. This is necessary because Python will create such sub-processes.)
Now reproduce the situation when the program does not behave correctly and kill my_program using pkill -KILL my_program. (Send the -KILL signal to ensure that my_program is killed immediately.)
Do that again - this time debugging miniterm and killing miniterm in the "wrong situation":
./my_program
strace -f -o file_miniterm.out miniterm /dev/pty/6
At the end of the two output files (file_myprog.out and file_miniterm.out) you can see the last "actions" the two programs were doing before you killed them. There are various scenarios possible:
miniterm was sending the data to /dev/pty/6 but your program did not receive any data. In this case there is a problem with the virtual console itself.
miniterm did not send the data to /dev/pty/6 for some reason. In this case you have a problem with miniterm.
miniterm did not even receive the data pasted using read()...
I am attempting to design a front end GUI for a CLI program by the name of eac3to.exe. The problem as I see it is that this program sends all of it's output to a cmd window. This is giving me no end of trouble because I need to get a lot of this output into a GUI window. This sounds easy enough, but I am begining to wonder whether I have found one of AutoIt's limitations?
I can use the Run() function with a windows internal command such as Dir and then get the output into a variable with the AutoIt StdoutRead() function, but I just can't get the output from an external program such as eac3to.exe - it just doesn't seem to work whatever I do! Just for testing purposesI I don't even need to get the output to a a GUI window: just printing it with ConsoleWrite() is good enough as this proves that I was able to read it into a variable. So at this stage that's all I need to do - get the text (usually about 10 lines) that has been output to a cmd window by my external CLI program into a variable. Once I can do this the rest will be a lot easier. This is what I have been trying, but it never works:
Global $iPID = Run("C:\VIDEO_EDITING\eac3to\eac3to.exe","", #SW_SHOW)
Global $ScreenOutput = StdoutRead($iPID)
ConsoleWrite($ScreenOutput & #CRLF)
After running this script all I get from the consolWrite() is a blank line - not the text data that was output as a result of running eac3to.exe (running eac3to without any arguments just lists a screen of help text relating to all the commandline options), and that's what I am trying to get into a variable so that I can put it to use later in the program.
Before I suggest a solution let me just tell you that Autoit has one
of the best help files out there. Use it.
You are missing $STDOUT_CHILD = Provide a handle to the child's STDOUT stream.
Also, you can't just do RUN and immediately call stdoutRead. At what point did you give the app some time to do anything and actually print something back to the console?
You need to either use ProcessWaitClose and read the stream then or, you should read the stream in a loop. Simplest check would be to set a sleep between RUN and READ and see what happens.
#include <AutoItConstants.au3>
Global $iPID = Run("C:\VIDEO_EDITING\eac3to\eac3to.exe","", #SW_SHOW, $STDOUT_CHILD)
; Wait until the process has closed using the PID returned by Run.
ProcessWaitClose($iPID)
; Read the Stdout stream of the PID returned by Run. This can also be done in a while loop. Look at the example for StderrRead.
; If the proccess doesnt end when finished you need to put this inside of a loop.
Local $ScreenOutput = StdoutRead($iPID)
ConsoleWrite($ScreenOutput & #CRLF)
I wrote a barebone progran template in XC8 (1.37) that I use to develop and test new GLCD functions for the 18F family. Programming is done via a PICkit3. Since I need to quicky reprogram several times the code it is really important that programming is faster as much as possible.
Tipically, the code size is around 2K and it takes less than 10 sec to program,
Everiything is fine until I must use a font table, defined as:
const char font8[] = {....
Now, with just $400 bytes added, the compiler place the table at the ROM's end and the programming of 64K memory takes more than 1 minute.
Is there any way to avoid this?
I tried to manually limit the memory range in the MPLABX options, but this is annoying and a little unsafe (sometimes part of code is truncated).
A while back I had to write some code for emissions testing, where I needed to copy data between extreme ends of RAM. To do that I needed to specify the exact memory addresses. You can also use the C extension __at() construct. http://ww1.microchip.com/downloads/en/DeviceDoc/50002053F.pdf#page=27
int scanMode __at(0x200);
const char keys[] __at(123) = { ’r’, ’s’, ’u’, ’d’};
int modify(int x) __at(0x1000) {
return x * 2 + 3;
}
I have a bizarre one here with the serial output when trying to write some code for my Arduino Uno.
I have this proto-code:
MyClass myclass;
void setup()
{
Serial.Begin(9600);
Serial.println("Starting...");
}
void loop()
{
int status = myclass.DoWork();
Serial.println("Status: " + status);
}
class MyClass
{
int DoWork()
{
Serial.println("Doing some work...");
return 1;
}
}
Now when this runs I get the following output:
Starting...
Doing some work...
atus: 1
So the strange part is the "Status: 1" missing the first few characters. Is this because I am using serial in an object improperly or something?
I have noticed when I reference another library that also uses serial like MyClass does that I get other strange output behavior... so I assume that I am doing something wrong.
EDIT: In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
You cannot add strings and integers in C++. It would have been better for you if this failed to compile:
Serial.println("Status: " + status);
Instead the compiler guessed at something. It guessed wrong. Use this:
Serial.print("Status :");
Serial.println(status);
or for complete control of outputting numbers and strings learn to use C string formatting, sprintf()
In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
One more possible explanation.
I was running minicom to monitor, and I usually like that it auto-reconnects after resetting my device.
Well I minimized a terminal running minicom last night, and today I started a new instance that somehow also got connected to the same serial port (if that is even possible).
I think the two instances of minicom were each reading ~50% of the serial characters roughly at random, leaving me with quite a mess of text.
I am trying to create a scripting widget for R using the tcltk package. But I don't know how to to create a STOP button to interrupt a script coming from the widget. Basically, I would like to have a button, a menu option, and/or a key binding that will interrupt the current script execution, but I can't figure out how to make it work.
One (non-ideal) strategy is to just use the RGui STOP button (or <ESC> or <Ctrl-c> on the console), but this seems cause the tk widget to hang permanently.
Here's a minimal example of the widget based on the tcl/tk examples (http://bioinf.wehi.edu.au/~wettenhall/RTclTkExamples/evalRcode.html):
require(tcltk)
tkscript <- function() {
tt <- tktoplevel()
txt <- tktext(tt, height=10)
tkpack(txt)
run <- function() {
code <- tclvalue(tkget(txt,"0.0","end"))
e <- try(parse(text=code))
if (inherits(e, "try-error")) {
tkmessageBox(message="Syntax error", icon="error")
return()
}
print(eval(e))
}
tkbind(txt,"<Control-r>",run)
}
tkscript()
In the scripting widget if you try executing Sys.sleep(20) and then interrupt from the console, the widget hangs. The same thing happens if one were to run, for example, an infinite loop, like while(TRUE) 2+2.
I think what I'm experiencing may be similar to the bug reported here: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14730
Also, I should mention that I'm running this on R 3.0.0 on Windows (x64), so maybe the problem is platform-specific.
Any thoughts on how to interrupt the running script without causing the widget to hang?
It depends on what the script is doing; a script that is sitting waiting for the user to do something is easy to interrupt (since you can make it listen for your interruption message) but a script that is doing an intensive loop is rather more tricky. The possible solutions depend on the version of Tcl inside.
Interpreter Cancellation — Requires 8.6
If you are using Tcl 8.6, you can use interpreter cancellation to stop the script. All you have to do is arrange for:
interp cancel -unwind
to be run, and the script will return control back to you. A reasonable way of doing this would be to use the extra Tcl package TclX (or Expect) to install a signal handler that will run the command when a signal is received:
package require Tcl 8.6
package require TclX
# Our signal handler
proc doInterrupt {} {
# Print a message so you can see what's happening
puts "It goes boom!"
# Unwind the stack back to the R code
interp cancel -unwind
}
# Install it...
signal trap sigint doInterrupt
# Now evaluate the code which might try to run forever
Adding signal handling in earlier versions is possible, but not quite as easy as you can't guarantee that things will return control to you so easily; the stack unwinding isn't there.
Execution Time Limiting — Requires 8.5 (or 8.6)
The other thing you could try is setting an execution time limit on a slave interpreter and running the user script in that slave. The time limit machinery will then guarantee a trap back to you every so often, giving you a chance to check for interruption and a way to do the stack unwinding. This is a considerably more complex method.
proc nextSecond {} {
clock add [clock seconds] 1 second
}
interp create child
proc checkInterrupt {} {
if {["decide if the R code wanted an interrupt"]} {
# Do nothing
return
}
# Reset the time limit to another second ahead
interp limit child time -seconds [nextSecond]
}
interp limit child time -seconds [nextSecond] -command checkInterrupt
interp eval child "the user script"
Think of this mechanism being a lot like how an operating system works, and yes, it can stop a tight loop.
Use a Subprocess — Any version of Tcl
The most portable mechanism is to run the script in a subprocess (with the tclsh program; the exact name varies by version, platform and distribution, but it's all variations on that) and just kill off that subprocess when it is no longer wanted with pskill. The downside of this is that you cannot (easily) carry any state over from one execution to another; subprocesses are pretty isolated from each other. The other methods described above can leave the state able to be accessed from another run: they do a real interrupt, whereas this destroys.
Also, I don't know exactly how to start the subprocess in such a way that you can communicate with it from R while it is still running; system and system2 don't seem to quite give enough control, and hacking something with forking is non-portable. Needs an R expert here. Alternatively, use a Tcl script (running inside the R process) to do it with:
set executable "tclsh"; # Adjust this line
set scriptfile "file/where/you/put/the_user/script.tcl"
# Open a bi-directional pipe to talk to the subprocess
set pipeline [open |[list $executable $scriptfile] "r+"]
# Get the subprocess's PID
set thePID [pid $pipeline]
That is actually reasonably portable to Windows (if not perfectly so) but intermediate states with forking are not.
I seem to have found a solution to prevent the tk widget from hanging by embedding the eval in a tryCatch that handles interrupt conditions. Unfortunately, it requires interruption from the console rather than the widget, but it does work. tryCatch is pretty poorly documented, so I'm putting this out here in case anyone else has similar needs in the future.
require(tcltk)
tkscript <- function() {
tt <- tktoplevel()
txt <- tktext(tt, height=10)
tkpack(txt)
run <- function() {
code <- tclvalue(tkget(txt,"0.0","end"))
e <- try(parse(text=code))
if (inherits(e, "try-error")) {
tkmessageBox(message="Parse error", icon="error")
tkfocus(txt)
return()
}
e <- tryCatch(eval(e),
error = function(errmsg)
tkmessageBox(message=as.character(errmsg), icon="error"),
interrupt = function(errmsg)
tkmessageBox(message=as.character(errmsg), icon="error")
)
print(eval(e))
}
tkbind(txt,"<Control-r>",run)
}
tkscript()
Another strategy I stumbled across is using tools::pskill (in the form pskill(Sys.getpid(), SIGINT) as a tk menu option) to interrupt the process, but - at least on Windows - this terminates the entire R process (including the tk widget). So, that's not a great solution but at least seems to exit everything as an absolute fallback.