Just sent out the core.
-----邮件原件----- 发件人: ebiederman@lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年6月3日 17:23 收件人: YhLu 抄送: LinuxBIOS 主题: Re: [COMMIT] romcc 0.63 and some fixes...
YhLu YhLu@tyan.com writes:
Eric,
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
make
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.
Thanks, Eric
P.S.
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.