romcc changes for mingw32 environment

[Patrick Georgi]

Hi,

I succeeded in building the entire SerialICE tool set (host and target) 
on mingw32. Most changes are in the repository already, but there are 
two issues in romcc without a clean fix so far, so I thought I'll post 
the patch for discussion to have it out in public.
As they're romcc related, I also added the coreboot list.

1. romcc seems to access memory after free. There's an xfree() call 
removed in that patch, which is a thinly disguised free() call. With 
that one removed, free_basic_block(..) works happily, with it present, I 
get a segfault. Win32 seems to invalidate free'd memory by writing a 
pattern (0xfeeefeee) there, and that trips up the next pointer deref.

There's probably a "sane" fix to that.

2. romcc uses open/read/close to read included files. For some reason, 
read always returns 0 bytes, so that's an endless loop. I kept the 
open/stat/close part, and replaced the read with fread (and fopen/fclose 
to support it).

This might be solved in a cleaner way.

Patrick

[Peter Stuge]

Patrick Georgi wrote:
> romcc uses open/read/close to read included files. For some
>
> reason, read always returns 0 bytes, so that's an endless loop. I
> kept the open/stat/close part, and replaced the read with fread
> (and fopen/fclose to support it).
>
> This might be solved in a cleaner way.

Maybe you can use fdopen() to tur the fd into FILE * once size is
known?

When done, just fclose() is sufficient, close() is not needed (and
will fail, since fclose() on fdopen()ed fds will close()). Confused
yet? :)

//Peter

[SerialICE] romcc changes for mingw32 environment

[Patrick Georgi]

Am 20.11.2009 22:26, schrieb Peter Stuge:
> Maybe you can use fdopen() to tur the fd into FILE * once size is
> known?
>
> When done, just fclose() is sufficient, close() is not needed (and
> will fail, since fclose() on fdopen()ed fds will close()). Confused
> yet? :)

Stefan reminded me on how cbfstool does it: fopen, fseek to the end, 
ftell, fseek to the beginning. I don't want to use a relatively obscure 
call like fdopen() when the aim is portability, but thanks for the idea.

Only leaves the free(..) call removal around.

Patrick