[coreboot] Strange ROMCC failure with Rev 5623

Peter Stuge peter at stuge.se
Thu Jun 17 22:14:19 CEST 2010


ron minnich wrote:
> > What if we just agree that host machines have a lot of RAM, romcc is
> > not a long-running program, and life will be easier if nothing gets
> > freed.
> > How much RAM are we talking about?
> 
> Reasonable. You could at least try it. Use LD_PRELOAD and make free()
> a no-op :-)

Yes, I would be interested in how much RAM is being used.


> (you'd be surprised how often I have to point out to people that
> doing lots of work to free memory before calling exit() has no
> effect on the system free memory -- "You mean the system can
> somehow free the process memory when the process exits?" -- I'm
> not kidding!)

It's lovely. I worked on a project where the application implemented
it's own memory allocator. When starting, the program would allocate
*all* available memory in the system, and then split that up into
small parts as the program progressed. The boss was convinced that
the operating system could not be trusted to do memory management.
They're still in business, I expect still running the same code.


Stefan Reinauer wrote:
> > What if we just agree that host machines have a lot of RAM, romcc is
> > not a long-running program, and life will be easier if nothing gets
> > freed.
> 
> Then we should also switch to Visual C++ in order to stay compliant. ;-)

He-he.. But depending on the resource use I would be okey with making
an exception for romcc.


//Peter




More information about the coreboot mailing list