Summary: | sys-libs/glibc corei7-avr inside a app-emulation/xen domU - illegal opcode in libc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert White <rwhite> |
Component: | [OLD] Core system | Assignee: | Gentoo Xen Devs <xen> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | gentoo, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info as requested |
Description
Robert White
2012-07-03 01:21:29 UTC
Forgot to mention/set this is an AMD64 ARCH (64 bit multilib) problem. 1) Please post your `emerge --info' output in a comment. 2) Please provide the command command line, command output and gdb backtrace of the program causing the SIGILL. seems to be the same as in bug #402753? Created attachment 317165 [details] emerge --info as requested I have attached emerge --info as requested. I suspect the program running at the time is /bin/bash (non statically linked). The kernel is reporting the program as "/init" which is the boot script from the initramfs image. The initramfs image I am using is the one generated by http://underdog.sourceforge.com which is (my soruceforge project, so I know that this is) the bash script in prototype/init from that project. I know this is non-statically linked because that is part of the point of underdog. 8-). I am trying to figure out how to get a core dump from early user context into any rational place where I can gdb it. (Any ideas there?) er... http://underdog.sourceforge.net (doh, typing too fast. 8-) (In reply to comment #3) > seems to be the same as in bug #402753? That Summary seems to say it's about a kernel panic, and this is about a segmentation fault in glibc... Comment on attachment 317165 [details]
emerge --info as requested
this isn't `emerge --info` ...
post /proc/cpuinfo and the output of running: gcc -march=native - -E -dD -P - </dev/null do this inside & outside of the xen system (In reply to comment #6) > (In reply to comment #3) > > seems to be the same as in bug #402753? > > That Summary seems to say it's about a kernel panic, and this is about a > segmentation fault in glibc... Please have a look at the screenshots attached in this bug... there are no screenshots attached to this bug. guess you meant bug 402753. may be the CFLAG -mno-avx help, but this problem is fixed in unstable upstream. *** This bug has been marked as a duplicate of bug 433884 *** |