[COMMIT] romcc 0.63 and some fixes...
Eric W. Biederman
ebiederman at lnxi.com
Thu Jun 3 18:58:01 CEST 2004
YhLu <YhLu at tyan.com> writes:
> I'm not familiar the gdb, and if you like I can send the auto.E to you.
That would be good thanks.
I guess slightly simpler would be to do:
Which will ensure core file generation is not turned off.
Then you can do.
ulimit -c unlimited
find . -name 'core*' -print
find . -name 'romcc' -print
And send me (off list) the file named core file and the file named
romcc, that the above find commands found. This feels like gcc
miscompiled romcc or something like that.
"ulimit -c unlimited" ensures core generation is enabled.
"make" does the build that fails
"find . -name 'core*' -print" locates core file generated by the sigsegv
"find . -name 'romcc' -print" locates the romcc binary you were running.
If it is a compilation error I really need to see what the binaries
look like. If it a bug in romcc I should be able to feed in your
auto.E and reproduce this.
Some very strange things are going on and I don't know how to call
it. Running dmesg and seeing if the oom killer kicked in would
also be interesting. romcc tends to be a bit of a memory hog. Not
so much that it has been unusable but I am grasping at straws.
It looks like my next step in instrumenting romcc is to start
catching signals like sigsegv so I can exit moderately gracefully
when they occur.
My coworkers have been using the romcc with no ill effects so I am
truly mystified, as to what is going wrong.
Brain storming on naming conventions, I think the sanest thing to do
is to indicate a function is not inline by appending an underscore
to it's name. So we will have print_debug(str) and
pring_debug_(str).... Unless there are any objections.
More information about the coreboot