答复: [COMMIT] romcc 0.63 and some fixes...

[YhLu]

Just sent out the core.

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 
发送时间: 2004年6月3日 17:23
收件人: YhLu
抄送: LinuxBIOS
主题: Re: [COMMIT] romcc 0.63 and some fixes...

YhLu  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.

YhLu  writes:
> Just sent out the core.

Thanks.  I have done the basic tracking.  And it is clearly a code
bug.

tdominates depends on some code analysis that is not currently
present in expand_function_call, and I wind up with a null pointer
dereference.  I need to stare at the code a little more but  should
take just a little bit to fix...

The back trace is:
#0  tdominates (state=0xbfffb78c, dom=0x829fbd0, sub=0x86f7698)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:16019
#1  0x0805c41f in expand_function_call (state=0xbfffb78c, me=0x8204290, fcall=0x829fbd0)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14422
#2  0x0805c747 in inline_function (state=0xbfffb78c, me=0x8204290, arg=0x0)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14599
#3  0x0805c838 in inline_functions (state=0xbfffb78c, func=0x8204290)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14606
#4  0x0805cd20 in join_functions (state=0xbfffb78c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14801
#5  0x08065efd in optimize (state=0xbfffb78c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:21488
#6  0x0806a4c7 in compile (filename=0xbfffecf8 "./auto.E", compiler=0x0, arch=0x0)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:24910
#7  0x0806a638 in main (argc=1, argv=0xbfffd93c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:25029
(gdb)

Eric

[e-mail] (Eric W. Biederman) writes:
> YhLu  writes:
> > Just sent out the core.
>
> Thanks.  I have done the basic tracking.  And it is clearly a code
> bug.

With the bug fix in place I am seeing what looks like another bug.

For the moment you can avoid this by removing the printo_debug
from generate_row.  That still runs out of registers but the
compiler does not crash.

I would dearly love to see a version of this code that works
when you do broad changes, like you did.  At the moment the code does
work well enough that if you change a couple of functions at a time,
you get some benefit.

Eric