May 2002 - Wine-Devel - list.winehq.org

Re: Debug information

by Ulrich Weigand

Tijs van Bakel wrote: > "Debuggers can determine whether an executable file or DLL contains > debugging information by searching for the IMAGE_FILE_DEBUG_STRIPPED > characteristic. If this characteristic is present, the debugging > information exists in a symbol file." > > This remark is a bit ambiguous. Does it say that if the > characteristic is _not_ present, then "the debugging information > exists, but not in a symbol file" ? Not quite; if the characteristic is not present, *either* the debugging information exists embedded into the PE file itself, *or* there is no debugging information at all. However, note that 'symbol file' does not refer to PDB files, but to DBG files containing stripped PE debug sections. When PDB files are involved, the PE debug section contains only a reference to the PDB, so it does not make much sense to strip it to a separate DBG file (and it therefore usually isn't done). > Any ideas on where to find documentation? Microsoft does not document the PDB file format publicly as far as I know. I am not aware of any other publicly available documentation that is more comprehensive than the winedbg sources. (There is a short section in Sven Schreiber's "Undocumented Windows 2000 Secrets", but this won't tell you anything that wasn't already in winedbg since before that book came out.) Of course, certain *parts* of the information inside the PDB (like the actual symbol and type information records) do follow the documented CodeView format. > Where does the knowledge for the old PDB parser come from? >From looking at various PDB files ... > I could ask the above question for many more parts of Wine. There is > a lot of code in Wine based on "undocumented" Windows features. Is > there a list of sources for information on Windows internals (both > books and websites)? Not that I'm aware of; there of course the Pietrek books and others, and there are various websites with bits and pieces of undocumented Windows features. I don't think there's a comprehensive list, though. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

May 30, 2002

Re: Debug information

by tijs＠connectux.com

Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> writes: > Tijs van Bakel wrote: > > > In debugger/msc.c I found the following check > > > > if ( mpd_nth->Signature != IMAGE_NT_SIGNATURE || > > mpd_nth->FileHeader.NumberOfSections != nth->FileHeader.NumberOfSections || > > !(mpd_nth->FileHeader.Characteristics & IMAGE_FILE_DEBUG_STRIPPED )) > > goto leave; > > It would appear that this check is simply inverted, i.e. you should > remove the '!'. At this point we require debug info *embedded* > in the PE module, i.e. *not* stripped ... Quoting an MSDN Library page on the topic of "Symbol Files" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/dbgh… "Debuggers can determine whether an executable file or DLL contains debugging information by searching for the IMAGE_FILE_DEBUG_STRIPPED characteristic. If this characteristic is present, the debugging information exists in a symbol file." This remark is a bit ambiguous. Does it say that if the characteristic is _not_ present, then "the debugging information exists, but not in a symbol file" ? > > Trying the same with Visual Studio .NET is somewhat more cumbersome. > > I haven't been able to read in the debugging information generated by > > C++ projects using winedbg. Has anyone else tried this? > > The format of the PDB files has changed; winedbg cannot read the > new format yet. Any ideas on where to find documentation? Where does the knowledge for the old PDB parser come from? I could ask the above question for many more parts of Wine. There is a lot of code in Wine based on "undocumented" Windows features. Is there a list of sources for information on Windows internals (both books and websites)? Regards, -- Tijs van Bakel, ConnecTUX, <tijs(a)connectux.com>

May 30, 2002

Re: Stripping of whitespaces at the end of lines

by Shachar Shemesh

Patrik Stridvall wrote: >I have read through the diff (rather quickly) and it seem to be OK. >In fact I can't think of anything in the C semantics that can make a >difference if trailing whitespace or extra semicolon is removed. > > <petty asshole response> I can. printf("blah blah blah \_ "); Remove the trailing whitespace and the thing actually compiles </petty asshole response>

May 30, 2002

Re: Debug information

by Ulrich Weigand

Tijs van Bakel wrote: > In debugger/msc.c I found the following check > > if ( mpd_nth->Signature != IMAGE_NT_SIGNATURE || > mpd_nth->FileHeader.NumberOfSections != nth->FileHeader.NumberOfSections || > !(mpd_nth->FileHeader.Characteristics & IMAGE_FILE_DEBUG_STRIPPED )) > goto leave; It would appear that this check is simply inverted, i.e. you should remove the '!'. At this point we require debug info *embedded* in the PE module, i.e. *not* stripped ... > Trying the same with Visual Studio .NET is somewhat more cumbersome. > I haven't been able to read in the debugging information generated by > C++ projects using winedbg. Has anyone else tried this? The format of the PDB files has changed; winedbg cannot read the new format yet. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

May 30, 2002

wine can't find regedit.exe.so when it is not on the path

by Andriy Palamarchuk

wineinstall fails because wine can't find regedit.exe.so. Obviously, the wine source directory does not exist in path of just created config file. After the wineistall failure .wine directory with config file are created. I get the same errors when I try to run regedit manually, even with using full path: $ /prj/wine/programs/regedit/regedit Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: Warning: could not find wine config [Drive x] entry for current working directory /mnt/buf/prj/wine; starting in windows directory. Warning: /prj/wine/programs/regedit/regedit.exe.so not accessible from a configured DOS drive Warning: /prj/wine/programs/regedit/regedit.exe.so not accessible from a configured DOS drive /prj/wine/miscemu/wine: cannot find '/prj/wine/programs/regedit/regedit.exe.so' $ file /prj/wine/programs/regedit/regedit.exe.so /prj/wine/programs/regedit/regedit.exe.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped $ ls -l programs/regedit/regedit lrwxrwxrwx 1 apalamar apalamar 23 May 30 06:53 programs/regedit/regedit -> ../../tools/winewrapper Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 30, 2002

Re: Stripping of whitespaces at the end of lines

by Vincent Béron

Patrik Stridvall a écrit : > > > Here it is. It only targets .c and .h files. > > Looks good. > > <shameless-plug-for-perl> > > However the script can be written much shorter in Perl > > find . -name '*.[ch]' | xargs perl -i -pe 's/[ \t]+$//; s/;;+$/;/' > > </shameless-plug-for-perl> Unfortunately for me, Perl is still in my "to learn" pile of stuff. But I will learn it, someday... > > > The diff was ~4MB in size between before and after. The savings in a > > .tar.gz of the whole tree were modest, around 25KB. > > I have read through the diff (rather quickly) and it seem to be OK. > In fact I can't think of anything in the C semantics that can make a > difference if trailing whitespace or extra semicolon is removed. > Thanks for the checking. Vincent

May 30, 2002

RE: Stripping of whitespaces at the end of lines

by Patrik Stridvall

> Alexandre Julliard a écrit : > > > > Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > > > > > If Alexandre wants to do it locally, I support him (our > mailboxes will > > > appreciate). > > > > If you want me to do that please send me a script that I can run > > across the tree to do the change. Please don't send patches for this > > kind of things. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.com > > Here it is. It only targets .c and .h files. Looks good. <shameless-plug-for-perl> However the script can be written much shorter in Perl find . -name '*.[ch]' | xargs perl -i -pe 's/[ \t]+$//; s/;;+$/;/' </shameless-plug-for-perl> > The diff was ~4MB in size between before and after. The savings in a > .tar.gz of the whole tree were modest, around 25KB. I have read through the diff (rather quickly) and it seem to be OK. In fact I can't think of anything in the C semantics that can make a difference if trailing whitespace or extra semicolon is removed. > Now to find a good set of arguments to feed indent(1) so we > all use the > same coding style... > > Not! ;) Good luck finding something that everybody can agree upon. :-)

May 30, 2002

Debug information

by tijs＠connectux.com

Hi, I compiled a simple Hello World test using VC++ 6.0, with default settings. This generates a .PDB file, which is not read by the most recent winedbg. Perhaps this is due to an overly strict sanity check. In debugger/msc.c I found the following check if ( mpd_nth->Signature != IMAGE_NT_SIGNATURE || mpd_nth->FileHeader.NumberOfSections != nth->FileHeader.NumberOfSections || !(mpd_nth->FileHeader.Characteristics & IMAGE_FILE_DEBUG_STRIPPED )) goto leave; Now unfortunately, the characteristics for my file are 0x10e, and hence the IMAGE_FILE_DEBUG_STRIPPED flag is not set. Disabling the check solves this problem, but perhaps I should try to instruct VC++ to enable the bit? Trying the same with Visual Studio .NET is somewhat more cumbersome. I haven't been able to read in the debugging information generated by C++ projects using winedbg. Has anyone else tried this? Greetings, -- Tijs van Bakel, ConnecTUX, <tijs(a)connectux.com>

May 30, 2002

Re: Winehq: Bugzilla responsibilities page

by Andriy Palamarchuk

--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > > > - why add a whole new talkback.inc ? isn't that > a > > > bit overkill ? > > > > Bug tracking activities are very close to AppDB > > maintaining activities. Both present feedback to > Wine > > developers and processing of this feedback. The > idea > > is to have one page to describe both activities. > > Users, wanting to provide feedback or help to > handle > > such feedback will have one page to start from. > > Information I want to have on this page: > > * link to Bugzilla > > * link to AppDB > > * link to guidelines for Wine bugs tracking > process - > > finding, submission, research, fixing, testing. Of > > cause these guidelines will have tons of > references to > > existing documents. > > * link to AppDB maintainer guide > > > > Remove this page if you think this is too much, we > can > > regroup information later. > This sounds *a lot* like what > www.winehq.org/about/index.php?contrib > already lists. Sounds good for me. > I really don't think adding a sort of "duplicate" > page is > going to help with the Wine users that already in > some cases seem to be > going out of their way to make sure that they don't > contribute to Wine > activities. > (because it might even leave those people that do > want to do Wine > activities confused) > My reasoning is: how many external winehq > maintainers do we have ? > how many main AppDB maintainers ? How many > FAQ-O-Matic maintainers ? > How many documentation writers ? How many > translators ? How many regular > application testers ? > (Almost) all are tasks that even a non-programmer > can easily handle given > some dedication... > > So how should this page conflict be resolved ? > I'm open to anything - well, probably except to > having two separate pages > with some sort of "Wine contribution" content. Agree. Lets remove talkback.inc, make a link to the contrib page from development page too. The contrib page may also have a link to the bugzilla repsponsibilities page. In future I'll add information I consider necessary to contrib.inc. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 30, 2002

User (developer ?) friendly execution trace

by max

I find tracing a wine problem with wine --debugmsg for large programs unpractical. Usually you can know about exactly when a program hangs or behaves badly, but there's no way to activate/deactivate tracing after program start (afaik...) Being also a windoze (sigh) programmer, I find very useful some utilities like winspy that presents a window log in which you can start/stop tracing or logging of wine messages, system calls and so on, and activate/deactivate filters on the fly. This would allow spotting the bug when it arises instead of having tenths or hundreds of mbyte of logs. I could implement it as a filter taking input from wine, but I guess it'll slow downn much apps, having to parse wine output on the fly. Much better would be an internal implementation.... Some comments about ? Regards Max

May 30, 2002