memcpy() for overlapping regions is undefined behavior; use memmove()
instead in readline_hist_add().
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
readline.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/readline.c b/readline.c
index 5fc9643..aeccc7b
select for fds above 32 on x86_64.
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
v2 of this patch removes unnecessary parentheses, as suggested by Richard
Henderson -- thanks!
linux-user/syscall.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user
Use the correct argument passing convention for select on x86_64.
Previously, select worked for i386 but was broken for x86_64 (always
returning EINVAL). With this change, select works on both i386 and
x86_64. (Other targets untested but should be unaffected.)
Signed-off-by: Nickolai Zeldovich
select for fds above 32 on x86_64.
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
linux-user/syscall.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 5a81d9f..17c3dd6 100644
--- a/linux-user/syscall.c
+++ b
On Mon, Nov 12, 2012 at 4:37 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-11-12 01:59, Nickolai Zeldovich wrote:
LWIP can generate packets with a source of 0.0.0.0, which triggers an
assertion failure in arp_table_add(). Instead of crashing, simply return
to avoid adding an invalid
LWIP can generate packets with a source of 0.0.0.0, which triggers an
assertion failure in arp_table_add(). Instead of crashing, simply return
to avoid adding an invalid ARP table entry.
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
slirp/arp_table.c |4 +++-
1 file changed
LWIP can generate packets with a source of 0.0.0.0, which triggers an
assertion failure in arp_table_add(). Instead of crashing, simply return
to avoid adding an invalid ARP table entry.
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
slirp/arp_table.c |3 ++-
1 file changed, 2
In qemu-0.9.0, an exception in cmpxchg8b (e.g. page fault due to a
missing TLB entry) causes the wrong eip value to be pushed onto the
exception stack -- it seems to be the eip of the last exception or the
start of the translation block, whichever happened last. This makes
it impossible to
Thanks. Looks like inline-generated instructions use
cpu_restore_state() to invert the translated PC into the simulated PC.
Nickolai.