[Bug c/29595] New: gcc miscompilation of some stuff
I noticed this while developing/debugging the source file, the code is in a very rough and buggy state but the behavior I'm getting seems to be tied to a properly formed printf(). $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) File will be attached. Sample output: WITH THE PRINTF (note the Most common lines): Current: 1 Most common: 1 9 :: 1 Current: 1 Current: 19 Most common: 4 15 :: 19 Current: 1 Current: 1 Current: 1 Current: 1 Current: 20 Most common: c 1c :: 20 Current: 1 Current: 1 Current: 1 Current: 1 Current: 1 Current: 68 Most common: 11 11 :: 68 Current: 1 Current: 1 Current: 77 Most common: 11 19 :: 77 Current: 5 Current: 1 Current: 4 Current: 1 Current: 4 Current: 11 Current: 5 Current: 7 Current: 2 Current: 6 Current: 1 Current: 3 Current: 16 Current: 7 Current: 1 Current: 19 Current: 4 Current: 8 Current: 6 Current: 8 Current: 9 Current: 8 [output trimmed...] Most common: 11 19 :: 77 0 0 :: 516 Key size: 134513244 WITHOUT THE PRINTF (Current: %i\n lines no longer printing): Most common: 0 0 :: 0 0 0 :: 516 Key size: 134513244 -- Summary: gcc miscompilation of some stuff Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nigelenki at comcast dot net GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug c/29595] gcc miscompilation of some stuff
--- Comment #1 from nigelenki at comcast dot net 2006-10-25 20:41 --- Created an attachment (id=12492) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12492action=view) decrypt_1.2.c C source file, there's a big block that says GCC MISCOMPILATION above the printf triggering this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug c/29595] gcc miscompilation of some stuff
--- Comment #4 from nigelenki at comcast dot net 2006-10-25 21:42 --- Issue was passing an unsigned long int to a %i instead of %li format specifier in printf(). I didn't know my C library altered anything if %n wasn't specified... oh well, my bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
[Bug other/28328] Stack smash protection non-verbose
--- Comment #14 from nigelenki at comcast dot net 2006-07-11 06:25 --- (In reply to comment #13) (In reply to comment #12) (In reply to comment #10) (In reply to comment #8) ... You make the assumption that I somehow know the bug is in f(). What if I have a 64 million line program with several hundred thousand functions like this, and the bug is obscure and hard to reproduce? Where do I start? How do I know the bug is in f()? Right, you just admitted this is information is only useful when the problem is obvious which 95% of the time it is not. Uh, ACTUALLY I just pointed out the scenario where the developer has no idea what the end user did; the end user knows he has a problem but that's it; and the developer would have to check the ENTIRE code base blindly if the end user couldn't just tell him Oh it said it blew up a buffer in f(), whatever that means. In other words I just showed that I saved the developer thousands of man-hours of work. in fact the developer still has to debug the program and to see why it is wrong. Yes but now he has a limited number of code paths to go wrong on. It might be a misleading to the developer to get where the problem shows up rather than where the problem really is caused from. Um, there are only so many code paths that lead you to f(). There's a LOT of code you can cut out of your program now... Different developers have different style of debugging so why push one style debuging on them? We're just volunteering more information, not forcing them to use it. Kind of like keeping soda in the fridge. Maybe you don't drink soda, but it's better than keeping nothing so everyone has to drive out to the store when they're thirsty. Again the end user does not care why it crashes, they only care if it is fixed. Right. It crashed, here's the file you asked me to e-mail, fix the damn thing. Think of the issue this way, when you ride on an elevator, and it stops working, you don't care why, you just care it gets fixed. And you pick up the Emergency Phone, and the operator says, open the panel, there's a number displayed, what does it say? and you blindly say 37 and they go to an exact panel in an exact room and work backwards from there instead of combing the entire elevator system. This is how software should be dealt with but really developer's are not held up to that standard for some reason except in the case where it is life and death can occur (well technically it can occur any time with real programs because they could cause someone to have a cesure). So, you are saying that software should be dealt with by an end user saying, I don't know why it broke, fix it; rather than saying, I don't know why it broke, it asked me to e-mail you this file. Here, now fix it? (literal, this is the ENTIRE conversation, you get NO MORE information from the end user on the problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- Comment #16 from nigelenki at comcast dot net 2006-07-11 07:08 ---
(In reply to comment #15)
(In reply to comment #14)
...
Yes but now he has a limited number of code paths to go wrong on.
That is not true. he just knows the last function and nothing more, this is
where a debugger comes in handy to get the full backtrace. You seem to think
getting where the crash is, is a magic bullet at fixing an issue which it is
not. It sometimes (less than 5%) can be a magic bullet but then using a debug
is part of the development cycle.
Actually, here's what I think:
int main() {
__foo();
}
void __foo() {
__bar();
__baz();
}
void __bar() {
__qux();
}
void __baz() {
return;
}
void __qux() {
int a[5];
strcpy(a, hello!!);
}
Of main(), __foo(), __bar(), __baz(), and __qux(), the problem can only be in
main(), __foo(), __bar(), or __qux(). The problem can NOT be in __baz().
Yes, maybe if __baz() was called before __bar() and alters data __qux() uses
(i.e. data to be passed, or global data), then we include __baz() in the
equation. My point is in a large program there will be functions that
effectively don't matter. There is a large chance that the bug occurred
recently relative to a crash.
Um, there are only so many code paths that lead you to f(). There's a LOT
of
code you can cut out of your program now...
What from 100 million down to 90 million, yes you cut the problem down by 1%
but there still can be a huge amount to go.
Each time you use a piece of data that is in an inconsistent state with what
the program expects, you have a chance of causing damage. Each time you cause
damage, you have a chance of creating a fatal condition.
Probaibilisticly, the more you use a piece of damaged data, the more likely the
program is to experience a fatal bug. To make a long story short, it's highly
likely that the bug was recently caused; and highly unlikely that you can go
all the way back to a bug in main() through 90 million lines of called code and
find the problem.
Of course that's just mathematic theory.
And you pick up the Emergency Phone, and the operator says, open the
panel,
there's a number displayed, what does it say? and you blindly say 37 and
they go to an exact panel in an exact room and work backwards from there
instead of combing the entire elevator system.
but that is how you reproduce the bug
Actually that's more like an error code (Experienced error 107 Error 404
Object Not Found etc). Which is debugging information.
No you get almost no more information about the problem if you get a bug
report
with just where it crashes, even GCC gets those because people don't read
instructions.
hey when I've reported gcc bugs, gcc was complaining that it failed to
spill/fill a register or something and gave me the file it was trying to use.
I passed it a switch to keep the preprocessed output, and attached that to the
bug, and you guys figured out what the problem was.
I would have got as far as saying Internal compiler error if it died with
ICE failure to spill/fill. Please report. As it stands it at least was able
to tell me what file it was trying to compile. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug c/28328] New: Stack smash protection non-verbose
In the original ProPolice that the gcc 4.1 stack smash protection was derived
from, a stack smash would illicit a message similar to:
*** Stack smashing detected in function vuln() in source file net.c!!! Aborted
Examining the current source, the following code exists:
void
__stack_chk_fail (void)
{
const char *msg = *** stack smashing detected ***: ;
fail (msg, strlen (msg), stack smashing detected: terminated);
}
This winds out with:
*** stack smashing detected ***: ./usr/lib/foxsrt/test/ssp_smash terminated
Unfortunately it seems this now can't be (cleanly) fixed without breaking
existing stack smash protected code. The only way to allow old behavior is to
add ANOTHER external function to libssp. One possible would be:
void
__stack_chk_fail2 (char *fctn, char *srcfile, void *damage)
{
const char *msg = *** stack smashing detected ***:;
/*Allocate: %s %s:%s (damage: 0x%p) ,msg,srcfile,fctn,damage*/
int msg2len = strlen (msg) + strlen (fctn)
+ strlen (srcfile) + sizeof(void*)*2 + 17;
char *msg2 = alloca (msg2len);
snprintf (msg2, msg2len, %s %s:%s (damage: 0x%p) ,
msg, srcfile, fctn, damage);
/* Not necessary, assuming %p doesn't spit out extra characters...*/
msg2[msg2len - 1] = '\0';
fail (msg2, strlen (msg2), stack smashing detected: terminated);
}
The emitted code would then have to call the following in case of a detected
stack smash:
__stack_chk_fail2(__FUNC__, __FILE__, __guard);
Where __FUNC__ is the function name, __FILE__ is the source file, and __guard
is the canary value in the function (which is now damaged).
The nice thing about doing something like this is that the programmer does not
have to pull out a debugger and try to reproduce stack smashing scenarios and
do a stack trace to figure out where the bug is. This is especially helpful
when an end user produces a bug report, because the bug report can say right
there, Stack smash in bad_code.c:vuln_function() and the programmer can go
right there and look through everything that the buffer is passed to and
everything he does with it to see what he messed up.
The overhead of this is an extra reference to __FILE__ and __FUNC__, which may
be generated inline or point to existing copies of those strings in the object.
The cost at runtime is only seen when a stack smash occurs. Total, the
program should get a few bytes bigger (if alignment doesn't fuzz that out) and
shouldn't run any slower, so nobody should care.
--
Summary: Stack smash protection non-verbose
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28334] New: SSP always log to syslog()
It should be possible to at least configure SSP to always log to syslog(). Of course since it's (apparently) /usr/lib/libssp.so.0 (usr? I should talk to my distro maintainers about that...), I suppose I could replace this with my own version.. The logging of SSP kills to syslog() is useful because it allows users who are not monitoring the program in a console (think Firefox, gnome-session, etc) to retrieve stack smash information after a crash. Currently this would allow a user to immediately know if the program died due to a stack smash; however, in tandem with bug #28328, this could become much more useful. A useful consideration is that a distribution could supply a daemon that may be configured to watch syslog() for stack smashes. This daemon could then report stack smashes back to the distribution maintainers automatically (users rarely do). In tandem with bug #28328, such a tool could report not only the program that overflowed; but also report the source file and function that was overflowed. This is quite enough data to place a developer straight at the root of the problem: the function that the overflowed buffer was allocated in. From there it's relatively easy to trace down the problem-- orders of magnitude easier than having to examine the ENTIRE codebase to figure out WHICH buffer was overflowed AND why. Lacking such a tool, being able to quickly determine if there was a stack smash (and where if we consider #28328) would allow bug-reporters and newbies crying in the IRC channel of any distribution or project to return useful information in a few seconds, without the developers jumping through hoops trying to calm them down. (considering bug #28328, they could be waved away in under a minute, since they could give all useful information in that time). -- Summary: SSP always log to syslog() Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nigelenki at comcast dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug other/28328] Stack smash protection non-verbose
--- Comment #2 from nigelenki at comcast dot net 2006-07-11 02:43 --- The program may be on an end user system that A) has insufficient debugging data compiled in (though I'd imagine you know what function it's in anyway); or B) has an end user that can't/won't debug (typical). It may also be difficult to reproduce the crash the user experiences when a stack smash occurs (hence why I am considering filing a bug about ALWAYS reporting stack smashing to syslog() to go with this*). Imagine an Ubuntu, Fedora Core, Mandriva, XandrOS, or MEPHIS Linux user encountering a mysterious crash that happens to be a stack smash. These distributions are largely aimed at typical users that will A) ignore it; or B) run to IRC and go help help wut happen :( and then bail out before reaching bugzilla. At least in the case of (B) someone can say Type dmesg or hit system-logs and click security and tell me what it says* and instantly have useful data. Another thought I had is that the stack trace may be destroyed; but this is not an issue, since the current function calls __stack_chk_fail() and thus passes us the current address, allowing us to find the function owning the overflowed buffer. This of course is only useful if the program happens to smash the stack while running in a debugger. *See bug #28334 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- Comment #4 from nigelenki at comcast dot net 2006-07-11 03:09 --- (In reply to comment #3) If an end user gets a stack smash failure, they should report the bug to the developer and have the developer fix it. This is what is normally done for anyother bug, why should it be different than a stack smashing one? Because, like any normal report, it will go something like this: END USER: xmms crashed DEVELOPER: I need more info. END USER: it crashed what do u mean DEVELOPER: Why did it crash? END USER: i unno it just did it was playin mp3s n it died DEVELOPER: Did a specific MP3 cause it to crash? END USER: maybe i cant make it do it agan tho i dunno y DEVELOPER: Huh. Meh. I'll figure it out some time next year. I would ultimately rather the report go like this: END USER: xmms crashed DEVELOPER: OK, can you see why? First you should check 'dmesg | grep stack smash | grep xmms' END USER: ** stack smashing detected ***: mpg123_decode.c:decode_spline() (damage: 0xdeadbeef) Terminated DEVELOPER: Thank you, I see the problem, there's a patch attached. Your distribution should have a new version some time in a couple days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28334] SSP always log to syslog()
--- Comment #2 from nigelenki at comcast dot net 2006-07-11 03:27 --- And the developer is going to debug a program nice and slow when those obscure, hard to trigger bugs come along. I was just toying with metasploit the other day. Threw an exploit at Windows to get me a remote VNC session (vncdllbind payload). The exploit I used was active since WinNT4sp3 all the way up to WinXPSP1. Do you know how many years that is for an active buffer overflow to be around? How many times was that obscurely triggered like ONE TIME by someone who didn't know nor care why his OS just rebooted? Twice? Three times? Stuff like this can be patched on the distro end; this bug is mostly a proof of concept that I doubt is going to gain any traction. I'm more interested in #28328 tbh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug other/28334] SSP always log to syslog()
--- Comment #5 from nigelenki at comcast dot net 2006-07-11 04:44 --- (In reply to comment #4) See bug #28328 comment #5 on why this should be closed as WONTFIX/INVALID or the likes. Eh close it WONTFIX because it's not gcc's job. Like I said, the stack smash handler can be altered distro-side as long as the same API is kept. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334
[Bug other/28328] Stack smash protection non-verbose
--- Comment #8 from nigelenki at comcast dot net 2006-07-11 04:56 ---
(In reply to comment #6)
(In reply to comment #4)
Thank you, I see the problem, there's a patch attached. Your distribution
should have a new version some time in a couple days.
Here is how normal GCC bugs go:
...
attach the sound file you were trying to play.
...
But but! I have 18,397 files in XMMS! It was on another virtual desktop when
it crashed! It was in shuffle mode! I don't KNOW what file it was trying to
play and I can't get it to reproduce it!
Compilers are easy. They die and say holy crap I was trying to process this
and my tree did this and I failed to spill a register help! and you go to the
bugzilla and go It told me to give you this file it spit out and go home.
(In reply to comment #5)
John is mostly right in reporting this.
...
I would ignore the part in his comments about syslog() as running the
handler past that would mean that all vio/*intf functionality would
have to have ssp disabled on it in *libc which pretty much means all of
the libc.
Yeah, ignore that, it can be dealt with distro-side and I'll find another way
that's friendlier. open and a named pipe, or a UNIX socket, or something. The
handler's exact function can be altered without an API change.
(In reply to comment #7)
(In reply to comment #5)
This bug should get itself assigned.
You know like many other open source projects, if you really want a feature
you
should implement it.
I'll try with 4.1.1 but I warn you I have no idea how gcc works internally.
Gimme a little help if I get stuck? :)
I'll poke the gcc ML if I get anywhere. I guess I'll start by unit testing my
stack check fail function.
As I mentioned in the other bug, knowing where something
crashed is only part of the story on debugging, you also need to know why,
which can be much harder to see as the problem comes from 1000 lines before.
Actually it won't come from 1000 lines before. It'll go like this:
int vuln(char *s, int len) {
char a[10];
char b[20];
a[0] = 0;
strcpy(a, str: );
strcat(a, s);
return strlen(a);
}
Result:
*** stack smashing detected ***: vuln.c:vuln() (damage: 0xdeadbeef) /bin/vuln
Terminated
We know that we trashed a[] or b[]. Let's imagine there's 3000 other
functions, and figure out where to look... oh, in vuln.c in vuln().
So getting this info is only useful for obvious bugs which someone could spot
by going through the code line by line.
Of course you could write a test case for your code, if you know where your
code is breaking.
Also the user should not know your internals of your program, it just confuses
them and in fact it might cause some of IP to be exposed and you don't want
that.
Confusing the user is a shoddy argument. What's the alternative? Attempt to
reproduce it, even though you can't after 5 hours? Run it through gdb,
because I can't reproduce it on my end? Trust me if you say to the user, It
should spit out something like 'IP: 0x7b, SP: 0x99, stack dump: 00 77 de ad be
ef ca fe ba be', give me that, he'll go uh... okay... don't know how you can
make any sense of any of that junk but...
IP exposure is a shoddy argument, a static function name is not important and
an external function name is readable via readelf -s.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug other/28328] Stack smash protection non-verbose
--- Comment #12 from nigelenki at comcast dot net 2006-07-11 05:49 ---
(In reply to comment #10)
(In reply to comment #8)
That is just a simple (obvious) example, you seem to not understand how real
code looks like. You might instead have:
int f(int a, int b)
{
int f[10];
.
f[a] = 1;
return f[b];
}
Where you know that a should be between 0 and 9 but comming into the function
it is not, so the value of a is wrong and you have to track down why that is
which can be a million lines in execution before calling of f. This is a
stack
smashing bug also, yes a less common one than the obvious ones which you
showed
but it is still going to happen. The obvious ones are easy to find in an
audit
of the code, unlike this one. You can add asserts to the function but that
will produce as much useful info as the info you want from the stack smasher.
It is only useful for starting to debug the program, even then you get the
information just as quick from the debugger.
You make the assumption that I somehow know the bug is in f(). What if I have
a 64 million line program with several hundred thousand functions like this,
and the bug is obscure and hard to reproduce? Where do I start? How do I know
the bug is in f()?
(In reply to comment #11)
(In reply to comment #9)
...
I am not saying ssp is bad, I am saying it is only a small tool in
debuging/development and should be kept that way.
Don't worry, it will be. I am only interested in getting a facility to obtain
information that says to start somewhere around here.
If there are trust problems,
then ssp is used and the end user is not trusting the developer of the program
anyways.
SSP is a safety net. If you can't trust the developer of the program, then you
assume the program is malicious, and don't run it because it's backdoored. SSP
is not a tool to stop untrusted developers, it's a tool to catch minor
mistakes.
.
You forget about
real end users like say a game player. He does not care why your program
crashes, he just wants a fix or he might just ask for a refund since your
program does not work.
I am experiencing a crash on level 10, sometimes when I enter this room
OK we'll look into it *months go by*
How about:
I am experiencing a crash on level 10, sometimes when I enter this room
OK, look in ~/level_10_dump.dbg, send me that file (game supplies an
overriden __stack_chk_fail() that also spits out a debug file) *patch released
4 days later*
I've heard enough stories about being on the phone with Apple for a total of 50
hours or whatnot, it's been fun but I'd rather just e-mail a file or copy-paste
a line of text and be done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328
[Bug libffi/28036] New: libffi executable stack (missing .note.GNU-stack on .o files)
I noticed (on ubuntu) that libgcj had an executable stack; tracing this back, I found that libffi also had an executable stack, and why. pinskia informs me that libffi gets linked into libgcj so that solves that! SCANELF: [EMAIL PROTECTED]:/tmp/x$ scanelf -qeRt /usr/lib RWX --- --- /usr/lib/libgcj.so.7.0.0 I built gcc and ran a scanelf on the source tree to find out what was up and located a few .o files missing .note.GNU-stack SCANELF: [EMAIL PROTECTED]:/tmp/x$ scanelf -qeRt . RWX --- --- ./gcj-4.1-4.1.0/build/i486-linux-gnu/libffi/.libs/libffi.so.4.0.1 !WX --- --- ./gcj-4.1-4.1.0/build/i486-linux-gnu/libffi/src/x86/sysv.o !WX --- --- ./gcj-4.1-4.1.0/build/i486-linux-gnu/libffi/src/x86/unix64.o !WX --- --- ./gcj-4.1-4.1.0/build/i486-linux-gnu/libffi/src/x86/.libs/sysv.o !WX --- --- ./gcj-4.1-4.1.0/build/i486-linux-gnu/libffi/src/x86/.libs/unix64.o sysv.o and unix64.o, find them: FIND: [EMAIL PROTECTED]:/tmp/x$ find . -name sysv.S ./gcj-4.1-4.1.0/src/libffi/src/sh/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/cris/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/s390/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/x86/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/m68k/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/sh64/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/m32r/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/arm/sysv.S ./gcj-4.1-4.1.0/src/libffi/src/powerpc/sysv.S Let's peek in x86: [EMAIL PROTECTED]:/tmp/x$ ls gcj-4.1-4.1.0/src/libffi/src/x86/ ffi64.c ffi.c ffitarget.h sysv.S unix64.S win32.S win32.S can probably be ignored, however... [EMAIL PROTECTED]:/tmp/x$ grep -Hnr .note.GNU-stack gcj-4.1-4.1.0/src/libffi/ [EMAIL PROTECTED]:/tmp/x$ The others probably need this block at the end (yanked from [1]): #ifdef __ELF__ .section .note.GNU-stack,,%progbits #endif No idea if this will clear the executable stack, haven't tested; but it'll supply a proper .note.GNU-stack segment where it really should be at least. [1] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml -- Summary: libffi executable stack (missing .note.GNU-stack on .o files) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nigelenki at comcast dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036
[Bug c/24292] New: Can't build qemu 0.7.2
Trying to build qemu 0.7.2 gives the following error:
/tmp/qemu-0.7.2/target-i386/ops_sse.h: In function 'op_pshufw_mmx':
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: error: unable to find a register to
spill in class 'GENERAL_REGS'
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: error: this is the insn:
(insn:HI 18 17 19 0 /tmp/qemu-0.7.2/target-i386/ops_sse.h:569 (set
(strict_low_part (subreg:HI (reg/v:DI 63 [ r ]) 0))
(mem/s/j:HI (plus:SI (mult:SI (reg:SI 64)
(const_int 2 [0x2]))
(reg/v/f:SI 59 [ s ])) [0 variable._w S2 A16])) 52
{*movstricthi_1} (insn_list:REG_DEP_TRUE 16 (insn_list:REG_DEP_TRUE 12
(insn_list:REG_DEP_TRUE 53 (nil
(expr_list:REG_DEAD (reg:SI 64)
(nil)))
/tmp/qemu-0.7.2/target-i386/ops_sse.h:574: confused by earlier errors, bailing
out
make[1]: *** [op.o] Error 1
The related code appears to be:
void OPPROTO glue(op_pshufw, SUFFIX) (void)
{
Reg r, *d, *s;
int order;
d = (Reg *)((char *)env + PARAM1);
s = (Reg *)((char *)env + PARAM2);
order = PARAM3;
r.W(0) = s-W(order 3);
r.W(1) = s-W((order 2) 3);
r.W(2) = s-W((order 4) 3);
r.W(3) = s-W((order 6) 3);
*d = r;
}
My version information is:
[EMAIL PROTECTED]:/tmp/qemu-0.7.2$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared
--with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
qemu can be found at qemu.org; I had unpacked qemu, cd'd into the directory,
and unpacked kqemu into it, then ran ./configure and make, each with no
options, as the kqemu documentation says.
--
Summary: Can't build qemu 0.7.2
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nigelenki at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24292
[Bug target/24292] Can't build qemu 0.7.2
--- Comment #1 from nigelenki at comcast dot net 2005-10-09 23:49 --- Created an attachment (id=9949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9949action=view) the dot-i file thingy you guys wanted the thingy that appeared in a completely different directory than related .c and .h files o.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24292
