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.
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
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 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.
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 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.
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.
-----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
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
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Björn Döbel -
Emanuel Berg