From: JonY <10...@gm...> - 2008-05-28 16:03:50
Attachments:
openmp2.c
|
Hi, I'm using a native gcc 4.2.1-dw2 (mingw32-2) on a Win XP machine to run the attached code. It works without any problems with static libgcc but not with the shared libgcc. The test case is using shared pthreads. It segfaults with multiple threads, but runs if a single thread is used. I am unsure where the issue lies. Pass the number of threads to use as the first CLI parameter, eg "a.exe 3" for 3 threads. Same code works without an issue under Linux. Below is the GDB backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 3624.0xfd0] pthread_mutex_lock (mutex=0x2c) at pthread_mutex_lock.c:52 52 if (*mutex == NULL) (gdb) bt #0 pthread_mutex_lock (mutex=0x2c) at pthread_mutex_lock.c:52 #1 0x00401b24 in gomp_mutex_lock (mutex=0x16) at ../gcc-4.2.1-2-src2/libgomp/config/posix/mutex.h:47 #2 0x00401c08 in gomp_barrier_wait (barrier=0x2c) at ../gcc-4.2.1-2-src2/libgomp/config/posix/bar.h:59 #3 0x004017bd in gomp_thread_start (xdata=0x22fe40) at ../gcc-4.2.1-2-src2/libgomp/team.c:121 #4 0x624838a4 in ptw32_threadStart@4 (vthreadParms=0x3e2e60) at ptw32_threadStart.c:219 #5 0x77c3a3b0 in msvcrt!_endthreadex () from C:\WINDOWS\system32\msvcrt.dll #6 0x7c80b713 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll #7 0x00000000 in ?? () (gdb) list 47 pthread_mutex_t mx; 48 49 /* 50 * Let the system deal with invalid pointers. 51 */ 52 if (*mutex == NULL) 53 { 54 return EINVAL; 55 } 56 (gdb) print mutex $1 = (pthread_mutex_t *) 0x2c Looks like a bad pointer, I've investigated up to frame 3, but still unsure how "0x2c" comes about. Any ideas why static libgcc version works but not the shared version? |
From: John E. / T. <td...@td...> - 2008-05-28 16:28:11
|
JonY wrote: > Hi, > I'm using a native gcc 4.2.1-dw2 (mingw32-2) on a Win XP machine to > run the attached code. It works without any problems with static > libgcc but not with the shared libgcc. The test case is using shared > pthreads. Just as an FYI, this problem does not occur using the 4.3.0 mingw32 alpha. No idea what the source of the problem might be. -John E. |
From: JonY <10...@gm...> - 2008-05-29 00:59:41
|
John E. / TDM wrote: > JonY wrote: >> Hi, >> I'm using a native gcc 4.2.1-dw2 (mingw32-2) on a Win XP machine to >> run the attached code. It works without any problems with static >> libgcc but not with the shared libgcc. The test case is using shared >> pthreads. > > Just as an FYI, this problem does not occur using the 4.3.0 mingw32 > alpha. No idea what the source of the problem might be. > > -John E. > Hi, Release notes for 4.3.0 alpha states that OpenMP is broken, crash at runtime. How did you get it to work? IIRC the difference between static and shared libgcc in gcc 4.2.1 is how EH frame [de,]register is handled. Someone more qualified care to explain? |
From: John E. / T. <td...@td...> - 2008-05-29 16:12:41
|
JonY wrote: > Hi, > Release notes for 4.3.0 alpha states that OpenMP is broken, crash at > runtime. How did you get it to work? > *Shrug*. > gcc -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.0/configure --enable-languages=c,ada,c++,fortran,jav a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab le-concept-checks --enable-version-specific-runtime-libs --build=mingw32 --with- bugurl=http://www.mingw.org/bugs.shtml --prefix=/mingw --with-gmp=/mingw/src/gcc /gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --with-libiconv-prefix=/ mingw/src/gcc/libiconv-root Thread model: win32 gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC) > gcc -o omp1.exe omp1.c -fopenmp -lgomp -lpthread > omp1 3 Executing thread 1 Executing thread 0 Executing thread 2 There are 3 threads -John E. |
From: JonY <10...@gm...> - 2008-05-29 17:42:32
|
John E. / TDM wrote: > JonY wrote: >> Hi, >> Release notes for 4.3.0 alpha states that OpenMP is broken, crash at >> runtime. How did you get it to work? >> > > *Shrug*. > >> gcc -v > Using built-in specs. > Target: mingw32 > Configured with: ../gcc-4.3.0/configure --enable-languages=c,ada,c++,fortran,jav > a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl > e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab > le-concept-checks --enable-version-specific-runtime-libs --build=mingw32 --with- > bugurl=http://www.mingw.org/bugs.shtml --prefix=/mingw --with-gmp=/mingw/src/gcc > /gmp-mpfr-root --with-mpfr=/mingw/src/gcc/gmp-mpfr-root --with-libiconv-prefix=/ > mingw/src/gcc/libiconv-root > Thread model: win32 > gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC) > >> gcc -o omp1.exe omp1.c -fopenmp -lgomp -lpthread > >> omp1 3 > Executing thread 1 > Executing thread 0 > Executing thread 2 > There are 3 threads > > > -John E. > Hi, The default static libgcc works for me too but, what happens when used with "-shared-libgcc" in gcc 4.3.0? I didn't find much on google. Using gcc 4.2.1 $ gcc -fopenmp openmp2.c -o openmp2 -shared-libgcc $ ./openmp2.exe 4 Executing thread 3 Executing thread 3 Executing thread 3 Executing thread 3 There are 1 threads There are 1 threads There are 1 threads GDB still showing the weird "0x2c". My uneducated guess: Concurency problem in shared libgcc? |
From: John E. / T. <td...@td...> - 2008-05-29 17:53:43
|
JonY wrote: > Hi, > The default static libgcc works for me too but, what happens when used > with "-shared-libgcc" in gcc 4.3.0? > > gcc -o omp1.exe omp1.c -fopenmp -lgomp -lpthread -shared-libgcc > omp1 3 Executing thread 1 Executing thread 2 Executing thread 0 There are 3 threads (Again with the 4.3.0 20080502 alpha, of course.) -John E. |
From: JonY <10...@gm...> - 2008-05-30 02:20:45
|
John E. / TDM wrote: > JonY wrote: >> Hi, >> The default static libgcc works for me too but, what happens when used >> with "-shared-libgcc" in gcc 4.3.0? >> > >> gcc -o omp1.exe omp1.c -fopenmp -lgomp -lpthread -shared-libgcc > >> omp1 3 > Executing thread 1 > Executing thread 2 > Executing thread 0 > There are 3 threads > > > (Again with the 4.3.0 20080502 alpha, of course.) > Hi, I just installed gcc 4.3.0 (MinGW release). I can confirm that it works, I may well switch to it soon. Should I re-link all my programs with the new shared libgcc? I have a bad feeling about mixing libgcc versions. |
From: Aaron W. L. <aar...@aa...> - 2008-06-04 01:37:22
|
JonY wrote: > I just installed gcc 4.3.0 (MinGW release). I can confirm that it works, > I may well switch to it soon. I'm glad that it works for you. It didn't work for me; at least not in any meaningful way. There's quite a few bugs left here, so you should regard OpenMP as suspect for now. > Should I re-link all my programs with the new shared libgcc? I have a > bad feeling about mixing libgcc versions. The libgcc DLL interface should not be regarded as stable until 4.3.1 is released (non-beta). From then on, we'll try to keep it backward-compatible. Danny Smith wrote: > The startup code for shared libgcc in 4.2.1 and in 4.3.0 is very buggy. In 4.3.0 I > suspect that EH registration functionality in your test case is using "weak" static libgcc > symbols, which effectively means that EH code is not linked in. Just as a general FYI to anyone interested, this is a major topic of interest to be fixed within the coming months. See <http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008> to track progress in this regard. |
From: Brian H. <bh...@lu...> - 2008-06-19 22:07:24
|
I hope someone can shed some light on my problem. I am building some drivers (they need to be legacy) for Windows. Everything has been working very very well. I am now down to just these two problems. All the other ntos and hal calls seem to resolve fine (and there are quite a few of them). However, these two it can't seem to resolve. c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64): In function `pal__reg_setup':e:/projects/current/bhawley_Base_Libraries/libraries/base/pal__windows.c:372: undefined reference to `_imp__HalTranslateBusAddress@24' c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64): In function `pal__dma__mem_alloc':e:/projects/current/bhawley_Base_Libraries/libraries/base/pal__windows.c:451: undefined reference to `_imp__MmAllocateContiguousMemory@12' this is the link line: gcc -shared -L/home/engr/tmp/bhawley/generic-i386-winxp/luc/1.0.0.18/lib -L/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib -L/home/engr/support/generic-i386-winxp/luc/1.0.0.18/lib -L/home/engr/support/generic-i386-winxp/Libraries/2.2.0.0/lib -L/home/engr/support/generic-i386-winxp/w32compat/pthread/lib -shared -Wl,--entry,_DriverEntry@8 -nostartfiles -nostdlib -static-libgcc /home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/LUM7900/Driver.o_K64 -o /home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/drv/LUM7900_K64 -lluci_K64 -lbase_K64 -lntoskrnl -lhal -lgcc I'm just really puzzled why these two do not resolve when so many other calls to. In particular, I am calling HalTranslateBusAddress(...) and MmAllocateContiguousMemory(...). Any help is appreciated. Thanks. |
From: Danny S. <dan...@cl...> - 2008-06-20 03:06:19
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of Brian Hawley > Sent: Friday, 20 June 2008 10:07 a.m. > To: MinGW Users List > Subject: [Mingw-users] _imp functions not found when linking > > > > I hope someone can shed some light on my problem. I am building some > drivers (they need to be legacy) for Windows. Everything has > been working > very very well. I am now down to just these two problems. > > All the other ntos and hal calls seem to resolve fine (and > there are quite > a few of them). However, these two it can't seem to resolve. > > c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbas e_K64.a(pal__windows.o_K64): > In function > `pal__reg_setup':e:/projects/current/bhawley_Base_Libraries/li > braries/base/pal__windows.c:372: > undefined reference to `_imp__HalTranslateBusAddress@24' > c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64): > In function > `pal__dma__mem_alloc':e:/projects/current/bhawley_Base_Librari > es/libraries/base/pal__windows.c:451: > undefined reference to `_imp__MmAllocateContiguousMemory@12' > Not your fault, mate. This is a mingw bug. The import stubs in the .def files for these two functions (possibly others involving PHYSICAL_ADDRESS) are wrong. Do you mind waiting for next w32api release for a fix or are you keen enough to roll your own? Danny |
From: Brian H. <bh...@lu...> - 2008-06-20 04:21:16
|
Thanks Danny...I was beginning to go a bit nuts. When will the new release be available? If it will be more than a week or so, then I would need to try to roll my own...although I'm pretty much clueless on how I would do that. -- Brian At 08:06 PM 6/19/2008, Danny Smith wrote: > > -----Original Message----- > > From: min...@li... > > [mailto:min...@li...] On Behalf > > Of Brian Hawley > > Sent: Friday, 20 June 2008 10:07 a.m. > > To: MinGW Users List > > Subject: [Mingw-users] _imp functions not found when linking > > > > > > > > I hope someone can shed some light on my problem. I am building some > > drivers (they need to be legacy) for Windows. Everything has > > been working > > very very well. I am now down to just these two problems. > > > > All the other ntos and hal calls seem to resolve fine (and > > there are quite > > a few of them). However, these two it can't seem to resolve. > > > > c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbas >e_K64.a(pal__windows.o_K64): > > In function > > `pal__reg_setup':e:/projects/current/bhawley_Base_Libraries/li > > braries/base/pal__windows.c:372: > > undefined reference to `_imp__HalTranslateBusAddress@24' > > >c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64): > > > > In function > > `pal__dma__mem_alloc':e:/projects/current/bhawley_Base_Librari > > es/libraries/base/pal__windows.c:451: > > undefined reference to `_imp__MmAllocateContiguousMemory@12' > > > >Not your fault, mate. This is a mingw bug. The import stubs in the .def >files for these >two functions (possibly others involving PHYSICAL_ADDRESS) are wrong. >Do you mind waiting for next w32api release for a fix or are you keen >enough to roll your >own? >Danny > > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Brian H. <bh...@lu...> - 2008-06-20 05:10:07
|
I think I've worked out most things, but I really do not understand the DDK build environment very well. When running 'build', I get the following link errors: libbase_K64.a(HashTable.o_K64) : error LNK2026: module unsafe for SAFESEH image. c:\winddk\6001\src\general\toaster\func\test\libbase_k64.a(HashTable.o_K64) : error LNK2026: module unsafe for SAFESEH image. I can see the /safeseh option in the log output, but have been unsuccessful in changing it, or finding some way to over ride it. Is there a mingw gcc option to eliminate the error, or some way to override the /safeseh flag in the DDK build environment? Thanks, -- Brian |
From: Brian H. <bh...@lu...> - 2008-06-19 22:31:54
|
As a followup, I did find the following in libhal.a. I note that the @value is 20 in the lib.a and @24 is what gcc appears to be looking for. I'm not really familiar with the windows linking mechanics, so I'm not sure the importance of this, or how to affect it. I have not found the MmAllocateContiguous in hal dukes00013.o: file format pe-i386 [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 _HalTranslateBusAddress@20 [ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp__HalTranslateBusAddress@20 And likewise, MmAllocate in libntoskrnl.a. Also with a different @ value. [ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 _MmAllocateContiguousMemory@8 [ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 __imp__MmAllocateContiguousMemory@8 At 03:07 PM 6/19/2008, Brian Hawley wrote: >I hope someone can shed some light on my problem. I am building some >drivers (they need to be legacy) for Windows. Everything has been working >very very well. I am now down to just these two problems. > >All the other ntos and hal calls seem to resolve fine (and there are quite >a few of them). However, these two it can't seem to resolve. > >c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64): > >In function >`pal__reg_setup':e:/projects/current/bhawley_Base_Libraries/libraries/base/pal__windows.c:372: > >undefined reference to `_imp__HalTranslateBusAddress@24' >c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64): > >In function >`pal__dma__mem_alloc':e:/projects/current/bhawley_Base_Libraries/libraries/base/pal__windows.c:451: > >undefined reference to `_imp__MmAllocateContiguousMemory@12' > >this is the link line: > > >gcc >-shared -L/home/engr/tmp/bhawley/generic-i386-winxp/luc/1.0.0.18/lib >-L/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib >-L/home/engr/support/generic-i386-winxp/luc/1.0.0.18/lib >-L/home/engr/support/generic-i386-winxp/Libraries/2.2.0.0/lib >-L/home/engr/support/generic-i386-winxp/w32compat/pthread/lib -shared >-Wl,--entry,_DriverEntry@8 -nostartfiles -nostdlib -static-libgcc >/home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/LUM7900/Driver.o_K64 > >-o >/home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/drv/LUM7900_K64 >-lluci_K64 -lbase_K64 -lntoskrnl -lhal -lgcc > > >I'm just really puzzled why these two do not resolve when so many other >calls to. > >In particular, I am calling HalTranslateBusAddress(...) and >MmAllocateContiguousMemory(...). > >Any help is appreciated. Thanks. > > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Brian H. <bh...@lu...> - 2008-06-19 23:51:05
|
I should point out that while the extension is _K64, I am not building 64 bit binaries. I am using the 32 bit gcc (3.4.2) that comes with mingw. At 03:31 PM 6/19/2008, Brian Hawley wrote: >As a followup, I did find the following in libhal.a. I note that the >@value is 20 in the lib.a and @24 is what gcc appears to be looking >for. I'm not really familiar with the windows linking mechanics, so I'm >not sure the importance of this, or how to affect it. I have not found the >MmAllocateContiguous in hal > >dukes00013.o: file format pe-i386 > > >[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 >_HalTranslateBusAddress@20 >[ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 >__imp__HalTranslateBusAddress@20 > > >And likewise, MmAllocate in libntoskrnl.a. Also with a different @ value. > >[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 >_MmAllocateContiguousMemory@8 >[ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 >__imp__MmAllocateContiguousMemory@8 > >At 03:07 PM 6/19/2008, Brian Hawley wrote: > > >I hope someone can shed some light on my problem. I am building some > >drivers (they need to be legacy) for Windows. Everything has been working > >very very well. I am now down to just these two problems. > > > >All the other ntos and hal calls seem to resolve fine (and there are quite > >a few of them). However, these two it can't seem to resolve. > > > >c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal > __windows.o_K64): > > > >In function > >`pal__reg_setup':e:/projects/current/bhawley_Base_Libraries/libraries/bas > e/pal__windows.c:372: > > > >undefined reference to `_imp__HalTranslateBusAddress@24' > >c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal > __windows.o_K64): > > > >In function > >`pal__dma__mem_alloc':e:/projects/current/bhawley_Base_Libraries/librarie > s/base/pal__windows.c:451: > > > >undefined reference to `_imp__MmAllocateContiguousMemory@12' > > > >this is the link line: > > > > > >gcc > >-shared -L/home/engr/tmp/bhawley/generic-i386-winxp/luc/1.0.0.18/lib > >-L/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib > >-L/home/engr/support/generic-i386-winxp/luc/1.0.0.18/lib > >-L/home/engr/support/generic-i386-winxp/Libraries/2.2.0.0/lib > >-L/home/engr/support/generic-i386-winxp/w32compat/pthread/lib -shared > >-Wl,--entry,_DriverEntry@8 -nostartfiles -nostdlib -static-libgcc > >/home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/LUM7900/Driver. > o_K64 > > > >-o > >/home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/drv/LUM7900_K64 > >-lluci_K64 -lbase_K64 -lntoskrnl -lhal -lgcc > > > > > >I'm just really puzzled why these two do not resolve when so many other > >calls to. > > > >In particular, I am calling HalTranslateBusAddress(...) and > >MmAllocateContiguousMemory(...). > > > >Any help is appreciated. Thanks. > > > > > >------------------------------------------------------------------------- > >Check out the new SourceForge.net Marketplace. > >It's the best place to buy or sell services for > >just about anything Open Source. > >http://sourceforge.net/services/buy/index.php > >_______________________________________________ > >MinGW-users mailing list > >Min...@li... > > > >You may change your MinGW Account Options or unsubscribe at: > >https://lists.sourceforge.net/lists/listinfo/mingw-users > > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Brian H. <bh...@lu...> - 2008-06-20 00:45:32
|
I apologize for the multiple posts. But continue to research and dig deeper into the linker semantics. I believe the problem might be related to the PHYSICAL_ADDRESS argument of these two functions. PHYSICAL_ADDRESS is a 8 byte structure. Which means @24 would be appropriate, assuming the headers (and ddk) are correct and this is not the pointer to a PHYSICAL_ADDRESS. While I can compile if I change the header to be a pointer to a physical address, and I pass a pointer, it remains to be seen if it will actually work. I suspect I will end up with all sorts of problems. This is a wild guess, but perhaps when the original libhal.a and libntoskrnl.a were built, PHYSICAL_ADDRESS was not 8 bytes. The other possibility I can see is that they were built with some option/flag/compiler that indicated that structures got passed by reference, and gcc 3.4.2 that I am using with the current flags is passing by value. I am using the win32api from the MinGW package. Again, sorry for the multiple posts. At 04:50 PM 6/19/2008, Brian Hawley wrote: >I should point out that while the extension is _K64, I am not building 64 >bit binaries. I am using the 32 bit gcc (3.4.2) that comes with mingw. > >At 03:31 PM 6/19/2008, Brian Hawley wrote: > > >As a followup, I did find the following in libhal.a. I note that the > >@value is 20 in the lib.a and @24 is what gcc appears to be looking > >for. I'm not really familiar with the windows linking mechanics, so I'm > >not sure the importance of this, or how to affect it. I have not found the > >MmAllocateContiguous in hal > > > >dukes00013.o: file format pe-i386 > > > > > >[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 > >_HalTranslateBusAddress@20 > >[ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 > >__imp__HalTranslateBusAddress@20 > > > > > >And likewise, MmAllocate in libntoskrnl.a. Also with a different @ value. > > > >[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 > >_MmAllocateContiguousMemory@8 > >[ 8](sec 5)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 > >__imp__MmAllocateContiguousMemory@8 > > > >At 03:07 PM 6/19/2008, Brian Hawley wrote: > > > > >I hope someone can shed some light on my problem. I am building some > > >drivers (they need to be legacy) for Windows. Everything has been working > > >very very well. I am now down to just these two problems. > > > > > >All the other ntos and hal calls seem to resolve fine (and there are quite > > >a few of them). However, these two it can't seem to resolve. > > > > > >c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal > > __windows.o_K64): > > > > > >In function > > >`pal__reg_setup':e:/projects/current/bhawley_Base_Libraries/libraries/bas > > e/pal__windows.c:372: > > > > > >undefined reference to `_imp__HalTranslateBusAddress@24' > > >c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal > > __windows.o_K64): > > > > > >In function > > >`pal__dma__mem_alloc':e:/projects/current/bhawley_Base_Libraries/librarie > > s/base/pal__windows.c:451: > > > > > >undefined reference to `_imp__MmAllocateContiguousMemory@12' > > > > > >this is the link line: > > > > > > > > >gcc > > >-shared -L/home/engr/tmp/bhawley/generic-i386-winxp/luc/1.0.0.18/lib > > >-L/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib > > >-L/home/engr/support/generic-i386-winxp/luc/1.0.0.18/lib > > >-L/home/engr/support/generic-i386-winxp/Libraries/2.2.0.0/lib > > >-L/home/engr/support/generic-i386-winxp/w32compat/pthread/lib -shared > > >-Wl,--entry,_DriverEntry@8 -nostartfiles -nostdlib -static-libgcc > > >/home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/LUM7900/Driver. > > o_K64 > > > > > >-o > > >/home/engr/tmp/bhawley/generic-i386-winxp/LUM7900/1.0.0.0/drv/LUM7900_K64 > > >-lluci_K64 -lbase_K64 -lntoskrnl -lhal -lgcc > > > > > > > > >I'm just really puzzled why these two do not resolve when so many other > > >calls to. > > > > > >In particular, I am calling HalTranslateBusAddress(...) and > > >MmAllocateContiguousMemory(...). > > > > > >Any help is appreciated. Thanks. > > > > > > > > >------------------------------------------------------------------------- > > >Check out the new SourceForge.net Marketplace. > > >It's the best place to buy or sell services for > > >just about anything Open Source. > > >http://sourceforge.net/services/buy/index.php > > >_______________________________________________ > > >MinGW-users mailing list > > >Min...@li... > > > > > >You may change your MinGW Account Options or unsubscribe at: > > >https://lists.sourceforge.net/lists/listinfo/mingw-users > > > > > >------------------------------------------------------------------------- > >Check out the new SourceForge.net Marketplace. > >It's the best place to buy or sell services for > >just about anything Open Source. > >http://sourceforge.net/services/buy/index.php > >_______________________________________________ > >MinGW-users mailing list > >Min...@li... > > > >You may change your MinGW Account Options or unsubscribe at: > >https://lists.sourceforge.net/lists/listinfo/mingw-users > > >------------------------------------------------------------------------- >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >MinGW-users mailing list >Min...@li... > >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Tuomo L. <dj...@ik...> - 2008-06-23 08:47:03
|
Brian Hawley wrote: > Again, sorry for the multiple posts. NP. Except that you hijacked a thread *and* kept top-posting. Both are no-nos. -- Tuomo ... (written by infinite number of monkeys with typewriters) |
From: Danny S. <dan...@cl...> - 2008-05-29 22:23:40
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of John E. / TDM > Sent: Thursday, 29 May 2008 4:28 a.m. > To: MinGW Users List > Subject: Re: [Mingw-users] OpenMP and shared libgcc > > > JonY wrote: > > Hi, > > I'm using a native gcc 4.2.1-dw2 (mingw32-2) on a Win XP machine to > > run the attached code. It works without any problems with static > > libgcc but not with the shared libgcc. The test case is > using shared > > pthreads. > > Just as an FYI, this problem does not occur using the 4.3.0 mingw32 > alpha. No idea what the source of the problem might be. > The startup code for shared libgcc in 4.2.1 and in 4.3.0 is very buggy. In 4.3.0 I suspect that EH registration functionality in your test case is using "weak" static libgcc symbols, which effectively means that EH code is not linked in. Danny. > -John E. > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 269.24.4/1473 - Release > Date: 29/05/2008 7:53 p.m. > |
From: Dave K. <dav...@ar...> - 2008-06-04 12:20:32
Attachments:
cygmin-crtbegin-patch.diff
|
Danny Smith wrote on 29 May 2008 23:24: > The startup code for shared libgcc in 4.2.1 and in 4.3.0 is very buggy. > In 4.3.0 I suspect that EH registration functionality in your test case > is using "weak" static libgcc symbols, which effectively means that EH > code is not linked in. For shared libgcc, I thought those -u options in the specs were supposed to take care of it? And anyway, the startup code does a dynamic lookup, so if anything at all has brought the dll in, it ought to find the register/deregister frame functions, no? Perhaps also related: http://gcc.gnu.org/ml/gcc/2008-05/msg00381.html plus attached patch. I've been experimenting with fully static libgcc, fully shared libgcc, and a hybrid combination of shared-libgcc-with-static-libgcc_eh, and found I had to work round an optimisation bug to get it to work all three ways. cheers, DaveK -- Can't think of a witty .sigline today.... |