Corrupted file problem Wine20040613,20040505 with Xilinx XST 6.2i

[Oliver]

On Wednesday 16 June 2004 08:56, Rein Klazes wrote:
> The source tree from which you compiled has to be reachable under one of
> wine's configured Drive's. I normally open the source in an editor.

Didn't work !?  Still gives at startup: Unable to open file /winternl.h

I created a sym-link for a drive: /home/oliver/.wine/dosdevices/s:
-> /home/oliver/Software/Wine/wine/

... and in .wine/config: [Drive S] "Path" = "/windows/c" "Type" = "hd" "Label" 
= "real winxp" ;"Filesystem" = "win95"

I call it like this: ~/Software/Wine/wine/wine winedbg  xst.exe -intstyle ise 
-ifn __projnav/stopwatch.xst -ofn stopwatch.syr

When I set breakpoints, I get a lot of messages like this:
[...]
fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: 
module.0<40529348-00000004> module<40529348-00000000>
fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: 
iDateW.4<40509aba-0000000c> iDateW<40509aba-00000000>
[...]

And especially: I can't se~/Software/Wine/wine/wine winedbg  xst.exe -intstyle 
ise -ifn __projnav/stopwatch.xst -ofn stopwatch.syrt debug channels anymore 
in winedbg ?!

Wine-dbg>set +file
fixme:dbghelp:elf_new_wine_thunks Duplicate in imm32<elf>: 
name.0<4219a75c-00000012> name<4219a75c-00000000>
[...]
No symbols found for first_dll
Can't get first_dll symbol
Wine-dbg>

Some clue what the problem could be ?

If I could use winegdb from the source-tree to debug, would be
quite good (see below).

> That is to big. Hmmm, there may be an awful lot of file: traces. Is the
> log with +relay significantly smaller? If not you must try to cut a good
> piece from it.

Yepp - normally the program in this configuration runs about 10sec. With 
+file,+ntdll and additionally +relay it run now +10h and still wasn't 
through! It created a 4MB bzip2'ed log-file. This could be 100gig or more
 uncompressed. +relay apparently creates a lot of output and bzip2 consumes
 90% cpu to compress it.

I have extracted some hopefully good parts. There are things like CreateFile 
and some steps after the same file is deleted again - strange stuff. Also 
some file:warnings. Should I put these already in a bug report ?

It would be could if I could use winedbg, because I think it's more efficient.  
Then I can really sneak near the places where it happens and then trace it
down.

Finally it can't be such a difficult thing with this file, I think, or ? It
just wants to be rewrite several times from the start.

I was wondering why the previous data was put to all to zero? Perhaps it 
something like the lseek man says:  
[...]
The lseek function allows the file offset to be set beyond the end of the  
existing  end-of-file  of  the  file (but this does not change the size of 
the file).  If data is later written at this point, subsequent reads of the 
data in the  gap  return  bytes  of  zeros (until data is actually written 
into the gap).
[...]

Cheerio, Oliver