Dwarf2 - support e0 ie DW_OP_lo_user
I still have to find why (probably gcc related) but under debian sid (no problems under lenny, have not tested squeeze yet) winedbg --gdb regedit trigger an infinite loop error: $ winedbg --gdb regedit 0017:0018: create process 'C:\windows\system32\regedit.exe'/0x110640 @0x7eb62c04 (00) fixme:dbghelp_dwarf:compute_location Unhandled attr op: e0 it: dwarf.c :1355 : dwarf2_parse_variable: L'assertion « subpgm-func » a échoué. wine: Assertion failed at address 0xe424 (thread 0009), starting debugger... Unhandled exception: assertion failed in 32-bit code (0xe424). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:e424 ESP:0032df04 EBP:0032df1c EFLAGS:0202( - 00 - - I1) EAX: EBX:3602 ECX:3602 EDX:0006 ESI:b7d9f157 EDI:b7dbbff4 Stack dump: 0x0032df04: 0032df1c 0006 3602 b7c8b640 0x0032df14: b7dbbff4 0032e03c 0032e044 b7c8d008 0x0032df24: 0006 0032dfbc b7dbbff4 0x0032df34: 005d 7c00a0f8 0068 b7ccea0f 0x0032df44: 0032df80 7c00a100 7c00a100 b7c9f7ab 0x0032df54: b7dbbff4 005d b7da16ff b7da3188 Backtrace: =0 0xe424 (0x0032df1c) fixme:dbghelp_dwarf:compute_location Unhandled attr op: e0 dwarf.c :1355 : dwarf2_parse_variable: L'assertion « subpgm-func » a échoué. wine: Assertion failed at address 0xe424 (thread 001a), starting debugger... Unhandled exception: assertion failed in 32-bit code (0xe424). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:e424 ESP:0033e684 EBP:0033e69c EFLAGS:0206( - 00 - -IP1) EAX: EBX:3617 ECX:3617 EDX:0006 ESI:b7f16fa3 EDI:b7f33ff4 Stack dump: 0x0033e684: 0033e69c 0006 3617 b7e03640 0x0033e694: b7f33ff4 0033e7bc 0033e7c4 b7e05008 0x0033e6a4: 0006 0033e73c b7f33ff4 0x0033e6b4: 0059 7c009fd8 0068 b7e46a0f 0x0033e6c4: 0033e700 7c009fe0 7c009fe0 b7e177ab 0x0033e6d4: b7f33ff4 0059 b7f196ff b7f1b188 Backtrace: =0 0xe424 (0x0033e69c) (...) thus never reach the prompt. Adding the attached patch (hack I made by reading binutils readelf.c) I get to the prompt though still have some errors (but it still seems to work): $ winedbg --gdb regedit 0018:0019: create process 'C:\windows\system32\regedit.exe'/0x110640 @0x7ed690f0 (00) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value zero (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value half (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value huge (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value huge (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value invsqrtpi (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value tpi (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value zero (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value huge (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value invsqrtpi (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value tpi (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value zero (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value invsqrtpi (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value two (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value zero (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value two52 (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value half (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value one (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value pi (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value a0 (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value a1 (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value a2 (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value a3 (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value a4 (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value a5 (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value a6 (a)
Re: Dwarf2 - support e0 ie DW_OP_lo_user
Alban Browaeys a écrit : I still have to find why (probably gcc related) but under debian sid (no problems under lenny, have not tested squeeze yet) winedbg --gdb regedit trigger an infinite loop error: $ winedbg --gdb regedit 0017:0018: create process 'C:\windows\system32\regedit.exe'/0x110640 @0x7eb62c04 (00) fixme:dbghelp_dwarf:compute_location Unhandled attr op: e0 it: dwarf.c :1355 : dwarf2_parse_variable: L'assertion « subpgm-func » a échoué. wine: Assertion failed at address 0xe424 (thread 0009), starting debugger... this looks like gcc emits TLS-based variables, and we don't handle this yet in the dwarf parser your fix is wrong as it just hides this fact, and still creates the variables/functions in the internal dbghelp structure, will give at the end wrong results in the debugger (and hard to understand) the correct short term fix is to handle the loc_error case in dwarf2_parse_variable (for the DW_AT_location case) by simply doing nothing the correct long term fix is to implement TLS based variable addressing in the parser A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH 00/10] Support for dumb picture keychain
Guy Albertelli galbe...@neo.rr.com writes:
On Thu, 2009-03-26 at 10:08 +0100, Alexandre Julliard wrote:
Guy Albertelli galbe...@neo.rr.com writes:
1. The initial problem was that the CreateFile above would not
successfully translate the volume id to the associated Unix file. #3/10
fixed that.
That should go in mountmgr, it already creates the volume symlinks and
manages the devices. What is needed is a way to associate a symlink with
a real Unix file so that you can do reads/writes on it, not just ioctls.
I now understand what you mean. Like the dosdevices/c: symlink,
mountmgr should create
dosdevices/volume{----0043} as a symlink
to the same place as the c: one.
No, that's not what I mean. The symlink is a Windows-style symlink, not
a Unix one, and it's created by mountmgr already. It points to something
like \Device\Harddisk1; what you need is to make it possible to do
reads/writes on that device.
--
Alexandre Julliard
julli...@winehq.org
Re: wined3d [try 2]: SetDepthStencilSurface is always called when AutoDepethStencilBuffer is enabled
Am Samstag, 28. März 2009 14:39:15 schrieb David Adam: + hrc = IWineD3DDeviceImpl_CreateSurface(iface, ... + This-parent); It's not that easy unfortunately. You're using the d3d9 (or d3d8) device as parent for the depth stencil, which isn't correct. This would mean that GetDepthStencilSurface returns an IDirect3DDevice9 instead of an IDirect3DSurface9, which will obviously lead to troubles. You'll have to use a callback function similarly to the CreateDevice callback to tell d3d8 / d3d9 to create one of their surface structures and call wined3d to create a wined3d surface.
Re: [1/4]winemaker: winresrc.h is the right name in actual wine
This one is wrapped. Besides that it's ok, so if you resubmit it should
go in.
--
Francois Gouget fgou...@free.fr http://fgouget.free.fr/
$live{free} || die ;
Re: 16bit code generation
On Sun, Mar 22, 2009 at 5:34 PM, King InuYasha ngomp...@gmail.com wrote: On Sun, Mar 22, 2009 at 5:46 AM, Tijl Coosemans t...@ulyssis.org wrote: On Sunday 22 March 2009 04:00:16 Austin English wrote: Wine supports 16 bit apps, just not as well as 32-bit. Dan had an intern work on a 16 bit test suite (http://code.google.com/p/win16test/), which can be used to test 16 bit support, fwiw. Yes, this is what I meant to refer to. AFAIK this test suite isn't part of Wine because it needs Open Watcom. Now it seems gcc could be used (perhaps with some help from winegcc). There's more at http://sourceware.org/binutils/docs/as/i386_002d16bit.html What is wrong with OpenWatcom? It is an open source development toolchain, with experimental linux binaries, yes, but they do work the last time I checked (which was when 1.8 release came out). It's not widely available, it's license is not open enough for many distros (ArchLinux has it available, and there's an initial Gentoo ebuild according to their wiki), but Fedora/Suse/Ubuntu don't have it available. It's also not known how well it works under Linux. There was talk about detecting if a user has it installed, then compiling 16 bit code in that case, but no one's worked to see if OpenWatcom works when ran/installed natively. -- -Austin
Re: [1/4] [wined3d] add pow2Matrix_identity flag to BaseTextureClass struct (resend)
The patchset looks ok to me
Re: wined3d [try 2]: SetDepthStencilSurface is always called when AutoDepethStencilBuffer is enabled
Am Samstag, 28. März 2009 14:58:28 schrieb Stefan Dösinger: Am Samstag, 28. März 2009 14:39:15 schrieb David Adam: + hrc = IWineD3DDeviceImpl_CreateSurface(iface, ... + This-parent); You'll have to use a callback function similarly to the CreateDevice callback to tell d3d8 / d3d9 to create one of their surface structures and call wined3d to create a wined3d surface. Actually, the code changed a little. You'll have to use IWineD3DDeviceParent_CreateSurface I think
How to bottle applications for distribution with wine?
Hello, I was working on setting up a Windows game to work on all the Linux machines I have, but I don't want to install the full blown Wine on each one. Is there a way to bottle Wine with application binaries and make it all work from a single folder and have it totally self sufficient (similar to TransGaming's Cedega for Linux with EVE Online)? Thanks!
GSoC 2009
Hi, I'm currently an IT student in Germany in my 2nd year. I'd like to help out with wine during the summer of code. I have never done any dll development apart from a little messing with the windows research kernel, so I'd rather work on something else. I would love to work on control panel applets or the wine config tool as in the project ideas, however, theming and the test suite would be two other things I'd be interested in. It would be great if you could give me some pointers as to where my help would be appreciated most so I dig a little deeper into that for a couple of days before I write my proposal. Regards, Tim
Re: GSoC 2009
Hi Tim, I'd like to help out with wine during the summer of code. I have never done any dll development apart from a little messing with the windows research kernel, so I'd rather work on something else. If you have had exposure to Microsoft source code, then I believe I'm right in saying that you are not able to work on Wine, I'm afraid. (I seem to recall reading somewhere that it might be OK for you to work on, say, client apps if you've only seen kernel code, but I might be wrong - somebody else will no doubt know better.) I would love to work on control panel applets or the wine config tool as in the project ideas, however, theming and the test suite would be two other things I'd be interested in. It would be great if you could give me some pointers as to where my help would be appreciated most so I dig a little deeper into that for a couple of days before I write my proposal. I worked on the control panel last year, and was in the process of converting some winecfg pages to separate applets - indeed, there's some outstanding work in my git repository that needs finishing/merging (but I have had a lack of time to work on this year, sadly.) Assuming you aren't barred from contributing for the aforementioned legal reasons, then there is lots more work that can be done on improving Wine configuration and so on if you're interested in that. Theming and the test suite are also areas which could do with work though, and you may be able to make a more substantial project out of those areas. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [2/4]winemaker: add project-parse function
This one is wrapped too.
But the main problem is that it does not handle case fixes. This can be
fixed by applying the attached patch on top of it.
With this, if you go test with the Programming Windows 98 samples, the
following scenario works:
cd Chap03/HelloWin
winemaker HelloWin.dsp
--
Francois Gouget fgou...@free.fr http://fgouget.free.fr/
Cahn's Axiom: When all else fails, read the instructions.commit e724fa2b721bb259419a0b62bacbea33a64856da
Author: Francois Gouget fgou...@free.fr
Date: Sat Mar 28 20:06:47 2009 +0100
winemaker: Better deal with case sensitivity issues in source_scan_project_file().
diff --git a/tools/winemaker b/tools/winemaker
index 2a878a6..d8c96d7 100755
--- a/tools/winemaker
+++ b/tools/winemaker
@@ -777,20 +777,8 @@ sub source_scan_project_file($$$)
#$libflag = 1;
next;
} elsif (/^SOURCE=(.*)$/) {
-$sfilet=$1;
-if (($opt_lower == $OPT_LOWER_ALL and $sfilet =~ /[A-Z]/) or ($opt_lower == $OPT_LOWER_UPPERCASE and $sfilet !~ /[a-z]/)) {
-$sfilet=lc $sfilet; #to lowercase if necessary
-}
-$sfilet=~s//\\/g; #remove double backslash
-$sfilet=~s/^\.\\//; #remove starting 'this directory'
-$sfilet=~s/\\/\//g; #make slashes out of backslashes
-#if ($sfilet =~ /^((\.\.\/)+)/){
-#print Fix files and directories in $1 ? y or n: ;
-#
-# if (STDIN=~/^y/i) {
-# fix_file_and_directory_names($1); #referenced files in upper directories? fix them!
-# }
-#}
+my @components=split /[\/\\]+/, $1;
+$sfilet=search_from($path, \...@components);
if ($sfilet =~ /\.(exe|dll)$/i) {
$targets{$sfilet}=1;
} elsif ($sfilet =~ /\.c$/i and $sfilet !~ /\.(dbg|spec)\.c$/) {
Re: [3/4]winemaker: add workspace-parse function
This one is wrapped also (which is only logical). There are two other problems: * there's the same case sensitivity issue as in the project parsing code. Using search_from() in the same way should fix it. * also it assumes that the project file is in the current directory. In other words, the following does not work: winemaker Chap03/HelloWin/HelloWin.dsw -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
Re: GSoC 2009
Owen Rudge wrote: If you have had exposure to Microsoft source code, then I believe I'm right in saying that you are not able to work on Wine, I'm afraid. I have written to the Software Freedom Law Center about this, but the License included with the Windows Research Kernel is actually pretty permissive (even allowing me to copy a small number of lines of code, actually. Which I wasn't going to do anyway though). I worked on the control panel last year, and was in the process of converting some winecfg pages to separate applets - indeed, there's some outstanding work in my git repository that needs finishing/merging (but I have had a lack of time to work on this year, sadly.) Assuming you aren't barred from contributing for the aforementioned legal reasons, then there is lots more work that can be done on improving Wine configuration and so on if you're interested in that. Theming and the test suite are also areas which could do with work though, and you may be able to make a more substantial project out of those areas. Thanks, then I will have a closer look at the test suite and at the themeing stuff and maybe apply for a project in one of these areas. Regards, -Tim
Re: 16bit code generation
On Sat, Mar 28, 2009 at 5:15 PM, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote: --- On Sat, 28/3/09, Austin English austinengl...@gmail.com wrote: It's also not known how well it works under Linux. There was talk about detecting if a user has it installed, then compiling 16 bit code in that case, but no one's worked to see if OpenWatcom works when ran/installed natively. But win32 openwatcom works under wine's cmd. :-). Right, but A) AJ doesn't want that and B) that doesn't allow us to (selectively) build the win16 tests the same time as the rest of the test suite. I don't know how well native linux openwatcom works as a cross-compiler, however, but that probably doesn't matter for this discussion? Quite the opposite, that's exactly what we WANT to use. -- -Austin
Re: GSoC 2009
2009/3/29 Tim Felgentreff timfelgentr...@gmail.com: Owen Rudge wrote: If you have had exposure to Microsoft source code, then I believe I'm right in saying that you are not able to work on Wine, I'm afraid. I have written to the Software Freedom Law Center about this, but the License included with the Windows Research Kernel is actually pretty permissive (even allowing me to copy a small number of lines of code, actually. Which I wasn't going to do anyway though). It's not just about licensing, it's also about keeping Wine Wine. We don't really want people to say this is how it's done in Windows, I've seen the source!, we want *proper* tests backing up patches and new implementations. At least, that's my interpretation of the SoC rules :)
