std::cin in Fiasco/L4Re (with 'make qemu')
How do I use std::cin in Fiasco/L4Re? The software compiles and links fine, only during execution (with 'make qemu'), this crashes it: Global_Scheduler::Global_Scheduler (bool read_from_file) : period_left(0), number_of_schedulers(0) { if (not read_from_file) { std::cout << "Global scheduler period: "; std::cin >> period; // ... There is no error, but there is no halt to execution (to wait for input), and the value "read" (to period) is inconsistent. -- underground experts united: http://user.it.uu.se/~embe8573
Emanuel Berg <emanuel.berg.8573@student.uu.se> writes:
How do I use std::cin in Fiasco/L4Re?
The software compiles and links fine, only during execution (with 'make qemu'), this [ std::cin >> period; ] crashes it ...
Just tried with scanf instead of std::cin (scanf from stdio.h) - same thing, what I can see. What's going on? scanf("%d", &period); // boom -- underground experts united: http://user.it.uu.se/~embe8573
On Tue Apr 01, 2014 at 02:12:51 +0200, Emanuel Berg wrote:
How do I use std::cin in Fiasco/L4Re?
The software compiles and links fine, only during execution (with 'make qemu'), this crashes it:
Global_Scheduler::Global_Scheduler (bool read_from_file) : period_left(0), number_of_schedulers(0) { if (not read_from_file) { std::cout << "Global scheduler period: "; std::cin >> period; // ...
There is no error, but there is no halt to execution (to wait for input), and the value "read" (to period) is inconsistent.
Add REQUIRES_LIBS += libc_be_file_stdin to your Makefile. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Adam Lackorzynski <adam@os.inf.tu-dresden.de> writes:
Add REQUIRES_LIBS += libc_be_file_stdin to your Makefile.
That gets the execution to halt but what I input is apparently interpreted as a "command" because it says unknown command: '2' if for example I press 2 and RET. Same for std::cin and scanf. -- underground experts united: http://user.it.uu.se/~embe8573
On Wed Apr 02, 2014 at 01:14:15 +0200, Emanuel Berg wrote:
Adam Lackorzynski <adam@os.inf.tu-dresden.de> writes:
Add REQUIRES_LIBS += libc_be_file_stdin to your Makefile.
That gets the execution to halt but what I input is apparently interpreted as a "command" because it says
unknown command: '2'
if for example I press 2 and RET.
Same for std::cin and scanf.
I'm not sure where you enter this. For me, the following works quite fine: #include <stdio.h> int main(void) { printf("Press some key: "); char c = getchar(); printf("\nYour input: %c (%d)\n", c, c); printf("Enter a number: "); int number; scanf("%x", &number); printf("Your number: %d\n", number); return 0; } Makefile: PKGDIR ?= ../../.. L4DIR ?= $(PKGDIR)/.. TARGET = stdin SRC_C = stdin.c REQUIRES_LIBS = libc_be_file_stdin include $(L4DIR)/mk/prog.mk Output: Press some key: a Your input: a (97) Enter a number: 0815 Your number: 2069 --------------------------------------------------------------------- CPU 0 [f00121f6]: IRQ ENTRY jdb: ^ Return reboots, "k" enters L4 kernel debugger... Rebooting. Shutting down... Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Adam Lackorzynski <adam@os.inf.tu-dresden.de> writes:
For me, the following works quite fine ...
OK, I will try getchar and the "hex scanf" (instead of the decimal version), though one would think the result would be the same, especially as I got the same result with std::cin as with scanf.
I'm not sure where you enter this.
Good point - I run qemu ('make qemu') in a Linux VT, on top of tmux. I don't recognize the 'unknown command' error message from my daily (nightly) activity so my bet is it has something to do with qemu. But let me try it in xterm as well. Get back to you on both accounts. -- underground experts united: http://user.it.uu.se/~embe8573
Adam Lackorzynski <adam@os.inf.tu-dresden.de> writes:
I'm not sure where you enter this. For me, the following works quite fine:
I tried it in xterm and it was the same thing. But after the assertion failed (the C++ assert, due to the inconsistent read), execution seemingly "falls back" to the qemu prompt (actually it is never anywhere else) - which looks like this: (qemu) - so I thought I'd hit the digit again (the presumed input). And indeed, it produced the same error message ('unknown command') - so the problem is: the software (running on Fiasco/L4Re, running on qemu) isn't getting the stdin, as that is intercepted by *qemu* (and interpreted as a command, as it says). So it doesn't matter how we twist it: getchar, scanf (hex or decimal), std::cin, or whatever else we can think of to try. -- underground experts united: http://user.it.uu.se/~embe8573
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.04.2014 01:02, Emanuel Berg wrote:
Adam Lackorzynski <adam@os.inf.tu-dresden.de> writes:
I'm not sure where you enter this. For me, the following works quite fine:
I tried it in xterm and it was the same thing. But after the assertion failed (the C++ assert, due to the inconsistent read), execution seemingly "falls back" to the qemu prompt (actually it is never anywhere else) - which looks like this: (qemu) - so I thought I'd hit the digit again (the presumed input). And indeed, it produced the same error message ('unknown command') - so the problem is: the software (running on Fiasco/L4Re, running on qemu) isn't getting the stdin, as that is intercepted by *qemu* (and interpreted as a command, as it says). So it doesn't matter how we twist it: getchar, scanf (hex or decimal), std::cin, or whatever else we can think of to try.
Could you tell us how exactly you are starting qemu? Bjoern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlM9A4EACgkQP5ijxgQLUNlVzwCeMknE1l5j+TSxLtvbrG+pp1Gt qUgAniapjgZgUIVtl/j1aTx3JuJgrRde =Up0w -----END PGP SIGNATURE-----
On Thu Apr 03, 2014 at 08:45:21 +0200, Bjoern Doebel wrote:
On 03.04.2014 01:02, Emanuel Berg wrote:
Adam Lackorzynski <adam@os.inf.tu-dresden.de> writes:
I'm not sure where you enter this. For me, the following works quite fine:
I tried it in xterm and it was the same thing. But after the assertion failed (the C++ assert, due to the inconsistent read), execution seemingly "falls back" to the qemu prompt (actually it is never anywhere else) - which looks like this: (qemu) - so I thought I'd hit the digit again (the presumed input). And indeed, it produced the same error message ('unknown command') - so the problem is: the software (running on Fiasco/L4Re, running on qemu) isn't getting the stdin, as that is intercepted by *qemu* (and interpreted as a command, as it says). So it doesn't matter how we twist it: getchar, scanf (hex or decimal), std::cin, or whatever else we can think of to try.
Could you tell us how exactly you are starting qemu?
You're typing into Qemu's monitor, just try typing 'help' or 'quit'. Now we're wondering how your Qemu is getting into this mode of operation. Any -monitor options there? Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
participants (3)
-
Adam Lackorzynski -
Björn Döbel -
Emanuel Berg