On Thu, 13 Nov 2008, David Arturo Macias Corona wrote: Hi David,
> Not. > -bt should be present > Which I removed was osn, value used in message: > "creating a (osn) executable" > by default is OS/2 OK. > >> changed -5 to -5r because -5 is for 16bit code. > >I think it does not cause any difference when wpp386 is used but of > >course it's cleaner and we should update these switches. > In 32bt -5 default to -5r Thanks for confirmation. > >If possible I'd like to ask you and David to check if -sg is enough. > >Both switches interacts with calling convention and function > >encapsulation so it will be good to know which one helps to resolve the > >problem. > Perhaps you skipped my previous message > "the problem" is resolved just removing "-s" flag Fine but can you check if it's enough? It looks like OpwnWatcom bug and I would like to know the exact conditions when it can be exploited. > Using "-sg" can be used or not and does not interfere with "the problem" > But -sg cause an interesting behaviour trying to manage stack size, is OS > dependant snd perhaps is unuseful because you are setting stack size for > threads except 1 by mean of _beginthread() > I included -sg info, review it and perhaps you can clarify if we > should/need to use or not If the cost of speed overhead is not big then it's very interesting feature and should be enabled. But please check if it cause noticeable speed difference in speedtst. You can use ST mode. > >The size of stack is less important in this tests though for such > >small stack (<=64KB) it's possible that OW makes some internal > >optimizations and they are source of the problem. > >It will be good to check what will happen when bigger stack is > >allocated. > "The problem" has gone removing -s and nothing depend of stack size. > Previously I was making tests with thread-c/_beginthread() parameters > values and that does not resolved GPFs Fine but changing begin thread parameters does not eliminate link time optimizations which can be done when stack size is smaller then 64KB. In short words it does not fix possibly wrong binaries so I asked about it. > As additional info: > OS/2 is using _beginthread() and removing -s resolv GPFs with MT > Win32 is using _beginthreadx() and is using -s but does not GPF To clarify. These are not OS2 or Win32 functions but C RTL ones. What they really do depends on CRTL code which is part of C compiler. For sure the call low level OS API functions to create threads and set some internal parameters necessary for given CRTL to work in MT safe mode and support some MT functions. In OW OS2 builds _beginthreadex() does not exists. There is only _beginthread() which has different parameters then _beginthread() and _beginthreadex() in Win32 so this functions are not comparable between OS-es. Interesting is 2-nd parameter void *__stack_bottom in OS2 _beginthread() function. It can be related to our problem. What OS2 OpenWatcom documentation says about it. > I requested why Win32 is using _beginthreadx() in place of _beginthread() > supported by OW These are different incomparable functions with different parameters. Only the name and main goal are the same. In Win32 builds _beginthreadex() is used to pass some additional thread attributed and to immediately extract thread ID. But parameters and their meaning are different then in OS2 so you cannot compare them. > -------------------------- > -s flag > ======= > Stack overflow checking is omitted from the generated code. By default, > the compiler will emit code at the beginning of every function that checks > for the "stack overflow" condition. This option can be used to disable > this feature. The macro __SW_S will be predefined if "s" is selected. > -------------------------- Please not that -s only disable some additional protection code. It resolves our problem but indirectly. It's possible that we can find some other methods which will give the same effect. Of course if it's worth to look for them. Please check the cost of -s in ST speedtst.prg and if it's not big then we can document in owatcom.cf of OS2 that -s should not be enabled and forget about the problem. BTW many thanks for all your work for OpenWatcom OS2 port and congratulations for final results. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
