- Wine-Devel - list.winehq.org

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Alexandre Julliard [mailto:julliard(a)winehq.com] wrote: > > There are no more guarantees with the GDI area than with anything > else. Microsoft is free to change that whenever they feel like it. > > Negative offsets could work, but they would waste a full page of > memory for each thread since the TEB has to be page-aligned. I'd > stronly recommend finding a way to use the glibc threading support > instead. As I keep saying, we need a solution that works on platforms that don't support __thread. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

3 3

HTMLHelp Setup
by Gerhard W. Gruber Feb. 22, 2003

Feb. 22, 2003

I tried to run the html help setup programm I downloaded from MS website. When I launch it I get an error msg missing w95inf32.dll. When I copy this over from the original windows installation w95inf16.dll is also missing. I copied this also over then then I get an erro message after unpacking saying: Incorrect INF file syntax in section 'HHWDestinationDir ; Ask user for custom destination' Now I'd like to know: Are there any replacements planned/available for the w95inf dlls? Any idea whats wrong with the INF file? The only fixme that I get is about CreateProcess so I don't think that this is it, or could it? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

1 0

HTMLHelp Setup
by Gerhard W. Gruber Feb. 22, 2003

Feb. 22, 2003

I tried to run the html help setup programm I downloaded from MS website. When I launch it I get an error msg missing w95inf32.dll. When I copy this over from the original windows installation w95inf16.dll is also missing. I copied this also over then then I get an erro message after unpacking saying: Incorrect INF file syntax in section 'HHWDestinationDir ; Ask user for custom destination' Now I'd like to know: Are there any replacements planned/available for the w95inf dlls? Any idea whats wrong with the INF file? The only fixme that I get is about CreateProcess so I don't think that this is it, or could it? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

1 0

Setupapi and Mingw
by Steven Edwards Feb. 22, 2003

Feb. 22, 2003

Hola, Now that ReactOS is having some luck loading device drivers we are going to need a easy way to load inf scripts for the registry information. I have been testing building setupapi under mingw and am getting the following error. Info: resolving _wine_ldt_copy by linking to __imp__wine_ldt_copy (auto-import) fu000001.o(.idata$3+0xc): undefined reference to `libwine_a_iname' nmth000000.o(.idata$4+0x0): undefined reference to `_nm__wine_ldt_copy' E:\users\steven\mingw\bin\dllwrap.exe: E:\users\steven\mingw\bin\gcc exited with status 1 make: *** [setupapi.dll] Error 1 I have been looking at Jeroen Janssen's wine_ldt_copy importing on cygwin patch but havent had any luck. Anyone have any ideas? Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

2 2

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Alexandre Julliard wrote: > > This is not something we can guarantee. The layout of the thread > structure in Wine is defined by Microsoft, and it's very possible that > they will use these fields someday for something that we need to > emulate. What about the area currently used for GDI? One other method could be to have space at a negative offset from %fs reserved for OpenGL, similar to what the IA32 implementation of NTPL does in Variant II of its design. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

Fix to allow running msvc from commandline in linux
by Dan Kegel Feb. 22, 2003

Feb. 22, 2003

Changelog: programs/wcmd/wcmdmain.c: make 'cmd /c cl /MUMBLE foo.c' pass /MUMBLE to cl LGPL. ------- Here's how I use msvc's compiler from the Linux shell. In ~/bin create the following three files: --- cl --- wine wcmd /c F:/bin/cl.bat "$@" --- cl.bat --- call F:/bin/vcvars32.bat cl %1 %2 %3 %4 %5 --- vcvars32.bat --- (same as one installed by msvc elsewhere, but with quotes removed -- wcmd doesn't deal well with quotes. Hopefully wcmd will be fixed soon, or is already fixed, to handle quotes properly.) Then you can just build demo programs under MSVC by saying cl foo.c in bash. This is handy for checking portability of wine conformance tests. Unfortunately, you can't pass options to cl, e.g. cl /DSTANDALONE foo.c without the attached patch. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: programs/wcmd/wcmdmain.c =================================================================== RCS file: /home/wine/wine/programs/wcmd/wcmdmain.c,v retrieving revision 1.22 diff -u -p -r1.22 wcmdmain.c --- programs/wcmd/wcmdmain.c 11 Feb 2003 22:01:11 -0000 1.22 +++ programs/wcmd/wcmdmain.c 22 Feb 2003 19:37:48 -0000 @@ -56,14 +56,14 @@ HANDLE h; args[0] = param[0] = '\0'; if (argc > 1) { - for (i=1; i<argc; i++) { - if (argv[i][0] == '/') { + /* interpreter options must come before the command to execute. + * Any options after the command are command options, not interpreter options. + */ + for (i=1; i<argc && argv[i][0] == '/'; i++) strcat (args, argv[i]); - } - else { + for (; i<argc; i++) { strcat (param, argv[i]); strcat (param, " "); - } } }

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Dan Kegel wrote: > > OK, "all new platforms". Sounds like a good argument for tagging > along with glibc's __thread variable support, if you ask me. We still have to support all older platforms as well. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Dan Kegel wrote: > > Sure, but it doesn't have to be as blazingly fast on old platforms. Actually, yes it does. > And, practically speaking, what you're looking for > might in fact only be possible using the new glibc > stuff; as Alexander said, Wine might be forced > to break any constraint you try to get them to agree to. Negative offsets from %fs would avoid any overlap. Perhaps that would be a better solution. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Jakub Jelinek wrote: > > What actually matters is the size of PT_TLS segment of the shared library > which defines those 2-3 __thread variables (I assume it is libGL.so, > right?). Generally, yes. > It would be good if the rest of __thread variables which aren't > performance critical is provided by some other library (and accessed > always through GD or LD model). I guess it would be possible to have non-critical variables defined in the driver backend, say. > Forgot to say, the offsets are obviously constant (until you dlclose the > library which declares them). > If they weren't, one couldn't keep pointers to __thread variables around > in IE/LE models. The variables could move in the dynamic case, hence the function call to get their address. We're trying to avoid that, obviously :-) -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Jakub Jelinek wrote: > > > I'm pretty sure all implementations of OpenGL are not compiled as PIC at > > this point in time. > > AFAIK on x86 only, but it is wrong everywhere. Can you elaborate? > On x86, ld supports Local Exec model in shared libraries (while for most > other targets it does not). R_386_TLS_LE relocation is simply during > -shared linking changed into R_386_TLS_TPOFF dynamic relocation (the same > as is used for IE model, but there this reloc is against .got section > while for LE it is against text section). To be clear, are you saying that even if you declare a variable as LE, once you link the relevant code into a shared library it is changed to IE? > So, if you don't use -fpic anyway, you can just use LE model on IA-32, > if you finally change it so that -fpic is used for the whole library, > then those functions (or assembly stubs) can be put into > some SHF_ALLOC|SHF_WRITE|SHF_EXECINSTR section. If we don't use PIC, do we always get LE if we declare a variable as LE? > Which means you should use the default -ftls-model and use > __attribute__((tls_model("initial-exec"))) or > __attribute__((tls_model("local-exec"))) > for the variables which are really performance critical. Yes, that would be the plan. > On IA-32, you can use > __asm ("jmp 1f; .section writetext, \"awx\"; 1: movl > $foo(a)ntpoff, %0; jmp 2f; .previous; 2:" : "=r" (foo_offset)); > to query some variable's offset which you can later on use with: > __asm ("movl %gs:0(%1), %0" : "=r" (foo_value) : "r" (foo_offset)); > Please do something like this only for runtime generated code, not for > anything else. Of course, silly me. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0