On 9/7/07, Tatsuro MATSUOKA <[EMAIL PROTECTED]> wrote:
>
>
>
> On cygwin
>
> [EMAIL PROTECTED] ~
> $ echo $PATH
> /usr/local/bin:/usr/bin:/usr/bin:/usr/X11R6/bin:/usr/bin:/cygdrive/c/
> WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/WBEM:
> /cygdrive/c/Program
> Files/Microsoft S
Brian Dessent wrote:
> All of the actual processing of all window events happens through
> messages passed to WndProc, but WndProc is never directly called
> by user code. So if you want to communicate information between the
> window procedure and the main function (such as: bad error happened,
>
Hello Brian
This is Tatsuro Matsuoka replying.
>Here I meant to add that of course we have discussed deprecating
>-mno-cygwin and offering a real MinGW cross in its place, which would
>have its own back-end, and thus could have a different exception
>handling model. But by the time you've done a
Dave Korn wrote:
> Right, so IOW, the SEH support does all the required unwinding for us.
> Ultimately I guess that's the only solution that's going to be both complete
> and correct.
Well, that is essentially the solution MinGW is using now with SJLJ
exceptions. MSVCRT's longjmp() is implement
Dave Korn wrote:
> IIRC every MS win32 API dll (user32, kernel32, gdi32 etc.) does
> absolutely masses of FPO, so we're probably no-go there.
Hey! Here's the first documented case of Vista doing something useful:
> FPO was enabled for all Windows binaries in NT 3.51, but was turned
> off
On 07 September 2007 15:19, Brian Dessent wrote:
> Dave Korn wrote:
>
>> Right, so IOW, the SEH support does all the required unwinding for us.
>> Ultimately I guess that's the only solution that's going to be both
>> complete and correct. (The only other thing I could even imagine would be
>>
Dave Korn wrote:
> Right, so IOW, the SEH support does all the required unwinding for us.
> Ultimately I guess that's the only solution that's going to be both complete
> and correct. (The only other thing I could even imagine would be some kind of
> hideous .pdb abuse using the M$ official sym
On 07 September 2007 14:44, Brian Dessent wrote:
> Dave Korn wrote:
>
>> Does anyone know how MSVC handles unwinding through API frames?
>
> MSVC implements C++ exception handling with SEH. And there is/was a
> GSoC project to port SEH to gcc, but I don't know if it went anywhere.
Right, s
Brian Dessent wrote:
> You might argue that most people
> doing Win32 GUI stuff use MinGW, but a lot of them use Cygwin with
> -mno-cygwin which is MinGW with Cygwin build tools, a very convenient
> combination. And we can't offer a DW2 Cygwin gcc that uses SJLJ for
> -mno-cygwin as they are real
On 2007-09-07 13:37Z, Dave Korn wrote:
>
> Does anyone know how MSVC handles unwinding through API frames?
With SEH:
http://www.howzatt.demon.co.uk/articles/oct04.html
http://www.microsoft.com/msj/0197/Exception/Exception.aspx
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Dave Korn wrote:
> Does anyone know how MSVC handles unwinding through API frames?
MSVC implements C++ exception handling with SEH. And there is/was a
GSoC project to port SEH to gcc, but I don't know if it went anywhere.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simp
On 07 September 2007 13:41, Brian Dessent wrote:
> Anthony Heading wrote:
>
>> Even if you catch the exception before it plummets through the
>> Windows API?
>
> Well sure, but that's not realistic. The entire windowing engine is
> based on callbacks so it's unavoidable that there will be forei
Anthony Heading wrote:
> Even if you catch the exception before it plummets through the
> Windows API?
Well sure, but that's not realistic. The entire windowing engine is
based on callbacks so it's unavoidable that there will be foreign
frames.
> It seems clear I am not understanding something
>
>I just want to clarify... Can you give a dump of these two commands:
>echo $PATH
>gcc -v
>
>from a cygwin command line... I suspect the reason all along is that
>the REAL minGW is trying to ignore cygwin all together, but in the
>process, cygwin is seeing a 'gcc' binary earlier in its PATH so i
Brian Dessent wrote:
> I think you're confusing the two separate issues, or maybe I didn't
> transition from one to the other very clearly.
>
> The reason we ship with SJLJ is because the Dwarf unwinder (prior to gcc
> 4.3) can't deal with foreign frames. You can run into this simply by
> writing
On 9/6/07, Tatsuro MATSUOKA <[EMAIL PROTECTED]> wrote:
> Hello
>
> This is Tatsuro writing.
>
> My threwing the problem on octave on cygwin seems to cause extensive
> disscussions.
> It is greatful for me. Thank a lot.
>
> >Anthony Heading wrote:
>
> >> Not to say
> >> that the constraint isn't t
Hello
This is Tatsuro writing.
My threwing the problem on octave on cygwin seems to cause extensive
disscussions.
It is greatful for me. Thank a lot.
>Anthony Heading wrote:
>> Not to say
>> that the constraint isn't technically real, but it it worth killing the
>> Cygwin platform for Octav
Charles Wilson wrote:
> I don't think Danny every claimed that 4.3 solved the foreign frame
> problem that Dwarf2 EH suffers from. I know there was *supposed* to be
> a SoC project to fix that (and another, related one? to add SEH support)
> but I've seen no results from it (either one).
>
> Can
Brian Dessent wrote:
The reason we ship with SJLJ is because the Dwarf unwinder (prior to gcc
4.3) can't deal with foreign frames.
I don't think Danny every claimed that 4.3 solved the foreign frame
problem that Dwarf2 EH suffers from. I know there was *supposed* to be
a SoC project to fix
Anthony Heading wrote:
> So it seems to be a pretty high hurdle to have full windows
> compatibility here, and frustratingly I don't really understand the aim
> or the purpose. For code that is going to link with Windows/msvcrt,
> using mingw is an obvious first choice, and the correctness guaran
Brian Dessent wrote:
The choice to ship gcc configured for SJLJ is because it is the only way
to guarantee correct behavior in all cases. [... elided... ] EH across
shared libraries will always be broken in the case of static libgcc et
al. (The same is true on other platforms like Linux, so it'
Dear Morgan Gangwere
Thnaks for your reply
Perhaps you are confusing. But I think that my writing is obscure.
In the first mail I wrote the results for cygwin.
http://cygwin.com/ml/cygwin/2007-09/msg00073.html
The results for mingw is as a mere refrence.
I show the result for mingw to show tha
Please Excuse My Stupid Spam Filter (ooh... special bonus points)
you want to use the real Cygwin GCC because that links things to
cygwin1.dll... mingGW (real MinGW) links things to mingw32.dll... big
difference unfortunately... check for mingGW in your PATH and see if
theres that path (c:/program
On 9/5/07, Tatsuro MATSUOKA <[EMAIL PROTECTED]> wrote:
> Sorry just error correction again
> >James R. Phillips, who is a maintainer of octave 2.1.73. Pherhaps he
> >is not working as a maintainer because he has not been made any
> >respose when I threw a topic of my testing binary of Octave 2.9.1
Sorry just error correction again
>James R. Phillips, who is a maintainer of octave 2.1.73. Pherhaps he
>is not working as a maintainer because he has not been made any
>respose when I threw a topic of my testing binary of Octave 2.9.12
>on cygwin.
>
>John W. Eaton, who is a main develper, seem
Thank you Brain
>Maybe I'm misremembering, but I thought that the current octave package
>maintainer entertained the idea of building the octave packages with a
>gcc that had been rebuilt with --disable-sjlj-exceptions. I don't
>remember why this never happened. At the very least, we had this sam
Tatsuro MATSUOKA wrote:
> My octave web
> http://www.geocities.jp/tmacchant/
>
> I think it is better that I keep the my binary on my web but post on
> the new binary package on the cygwin. I do not want to build the
> octave by the gcc in the cygwin package because it is too slow to use.
Maybe
Just a correction of the previous mail
>I think it is better that I keep the my binary on my web but post on
>the new binary package on the cygwin. I do not want to build the
>octave by the gcc in the cygwin package because it is too slow to use.
I think it is better that I keep the my binary
Thank you Brian
>The choice to ship gcc configured for SJLJ is because it is the only way
>to guarantee correct behavior in all cases. The Dwarf unwinder can't
>unwind through a foreign frame. This means for example if you try to
>throw an exception from a function that was called from a Win32 c
Dear Morgan
>> For Octave on mingw
>> octave.exe:1> testOregoB
>> ans = 1.5781
>>
>> $ gcc -v
>> Reading specs from c:/Programs/MinGW/bin/../lib/gcc/mingw32/3.4.2/
>ok this sounds odd..
>> specs
>> Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-
>> as --host=mingw32 --t
On 9/5/07, Tatsuro MATSUOKA <[EMAIL PROTECTED]> wrote:
> Dear Carlo
>
> >Could you please expound (or point to a link) on what sjlj or sjlj-
> >exceptions do? AFAIK, it's probably the first time the "octave sjlj
> >exception issue" has appeared in this list. As far as I've seen, this is a
> >gcc
Dear Carlo
>Could you please expound (or point to a link) on what sjlj or sjlj-
>exceptions do? AFAIK, it's probably the first time the "octave sjlj
>exception issue" has appeared in this list. As far as I've seen, this is a
>gcc issue.
Disscussion seem to be started from the foloowing points
Tatsuro MATSUOKA wrote:
> My question is why the cygwin uses the slow
> sjlj exceptions instead of
> dwarf2 which was used in old cygwin at the time gcc-3.2 was used.
The choice to ship gcc configured for SJLJ is because it is the only way
to guarantee correct behavior in all cases. The Dwarf un
Matsuoka-san,
Ohayougozaimasu :)
I'm Tatsuro MATSUOKA.
This is the first time to post cygwin-app ML.
Great!
I'm now using cygwin for octave, gnuplot and shell command etc.
For the Octave society, it is very famous that building octave
current standard gcc slows the octave
because the cygwi
Dear sirs
I'm Tatsuro MATSUOKA.
This is the first time to post cygwin-app ML.
I'm now using cygwin for octave, gnuplot and shell command etc.
For the Octave society, it is very famous that building octave
current standard gcc slows the octave
because the cygwin treats the silj-exceptions very sl
35 matches
Mail list logo
