Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2007-07

Re: win32 debugging broken in fixes_2_2?

29 messages · 9 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Vinzent Hoefler
to Vinzent Hoefler
Vinzent Hoefler wrote
On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: > Maybe other way to detect SSE support exists... CPUID?

To be more precise, the way recommended by Intel:

"To make this check, execute the CPUID instruction with an argument of 1 in the EAX register, and check that bit 25 (SSE) and/or bit 26 (SSE2) are set to 1."

-- IA32 Software Developer's Manual,
Volume 3: System Programming Guide

Reply by email

Unknown author
to Martin Schreiber: Every program compiled with fixes_2_2 rev. 8006 crashes in gdb: " GNU gdb 6.6 Copyright…

----- Original Message -----

Earlier message 47 lines
From: Martin Schreiber Date: Tuesday, July 10, 2007 2:38 pm Subject: [fpc-devel] win32 debugging broken in fixes_2_2? > Hi, > Every program compiled with fixes_2_2 rev. 8006 crashes > in gdb: > " > GNU gdb 6.6 > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, > and you are > welcome to change it and/or distribute copies of it under certain > conditions.Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details.This GDB was configured as "i686-pc-mingw32"... > (gdb) run > Starting program: G:\testcase\mse\console/console.exe > Loaded symbols for C:\WINNT\system32\KERNEL32.DLL > Loaded symbols for C:\WINNT\system32\OLEAUT32.DLL > Loaded symbols for C:\WINNT\system32\OLE32.DLL > Loaded symbols for C:\WINNT\system32\rpcrt4.dll > Loaded symbols for C:\WINNT\system32\ADVAPI32.DLL > Loaded symbols for C:\WINNT\system32\GDI32.DLL > Loaded symbols for C:\WINNT\system32\USER32.DLL > > Program received signal SIGILL, Illegal instruction. > 0x00402091 in SYSTEM_FPC_CPUCODEINIT () > (gdb) bt > #0 0x00402091 in SYSTEM_FPC_CPUCODEINIT () > #1 0x0040a504 in SYSTEM_init () > #2 0x00406114 in fpc_initializeunits () > #3 0x7ffdf000 in ?? () > #4 0x00000000 in ?? () > (gdb) > " > The programs work without gdb. > System: win2000, PII. > The problem seems not to exist on another PC with win2000 and an > AMD Athlon. > Any hints? It has to to with SSE2 detection. AFAIK the only reliable way to detect it, is execute a SSE2 instruction and capture the exection which it causes if it is not supported. I don't know, how it can be circumvented (except for using a newer processor). Vincent

Reply by email

Jonas Maebe
to Martin Schreiber: Every program compiled with fixes_2_2 rev. 8006 crashes in gdb: " GNU gdb 6.6 Copyright…
Martin Schreiber wrote 17 lines
Every program compiled with fixes_2_2 rev. 8006 crashes in gdb: Program received signal SIGILL, Illegal instruction. 0x00402091 in SYSTEM_FPC_CPUCODEINIT () (gdb) bt #0 0x00402091 in SYSTEM_FPC_CPUCODEINIT () #1 0x0040a504 in SYSTEM_init () #2 0x00406114 in fpc_initializeunits () #3 0x7ffdf000 in ?? () #4 0x00000000 in ?? () (gdb) " The programs work without gdb. System: win2000, PII. The problem seems not to exist on another PC with win2000 and an AMD Athlon. Any hints?

The rtl checks on startup whether or not your cpu supports SSE. It does so by executing an SSE instruction, catching the "illegal instruction" exception if it occurs and if so, setting a boolean to false.

So just type "continue" in gdb to continue the program.

Jonas

Reply by email

Martin Schreiber

Hi,
Every program compiled with fixes_2_2 rev. 8006 crashes in gdb:
"
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: G:\testcase\mse\console/console.exe Loaded symbols for C:\WINNT\system32\KERNEL32.DLL
Loaded symbols for C:\WINNT\system32\OLEAUT32.DLL
Loaded symbols for C:\WINNT\system32\OLE32.DLL
Loaded symbols for C:\WINNT\system32\rpcrt4.dll
Loaded symbols for C:\WINNT\system32\ADVAPI32.DLL
Loaded symbols for C:\WINNT\system32\GDI32.DLL
Loaded symbols for C:\WINNT\system32\USER32.DLL

Program received signal SIGILL, Illegal instruction. 0x00402091 in SYSTEM_FPC_CPUCODEINIT ()
(gdb) bt
#0 0x00402091 in SYSTEM_FPC_CPUCODEINIT ()
#1 0x0040a504 in SYSTEM_init ()
#2 0x00406114 in fpc_initializeunits ()
#3 0x7ffdf000 in ?? ()
#4 0x00000000 in ?? ()
(gdb)
"
The programs work without gdb.
System: win2000, PII.
The problem seems not to exist on another PC with win2000 and an AMD Athlon. Any hints?

Martin

Reply by email

Yury Sidorov
to Martin Schreiber

From: "Martin Schreiber"

Show quoted text 39 lines
Hi, Every program compiled with fixes_2_2 rev. 8006 crashes in gdb: " GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"... (gdb) run Starting program: G:\testcase\mse\console/console.exe Loaded symbols for C:\WINNT\system32\KERNEL32.DLL Loaded symbols for C:\WINNT\system32\OLEAUT32.DLL Loaded symbols for C:\WINNT\system32\OLE32.DLL Loaded symbols for C:\WINNT\system32\rpcrt4.dll Loaded symbols for C:\WINNT\system32\ADVAPI32.DLL Loaded symbols for C:\WINNT\system32\GDI32.DLL Loaded symbols for C:\WINNT\system32\USER32.DLL Program received signal SIGILL, Illegal instruction. 0x00402091 in SYSTEM_FPC_CPUCODEINIT () (gdb) bt #0 0x00402091 in SYSTEM_FPC_CPUCODEINIT () #1 0x0040a504 in SYSTEM_init () #2 0x00406114 in fpc_initializeunits () #3 0x7ffdf000 in ?? () #4 0x00000000 in ?? () (gdb) " The programs work without gdb. System: win2000, PII. The problem seems not to exist on another PC with win2000 and an AMD Athlon. Any hints?

If CPU have no SSE support an exception occurs, but it handled properly by program. If running under gdb, it catches this exception.

Maybe other way to detect SSE support exists...

Yury.

Reply by email

Martin Schreiber
to Jonas Maebe: The rtl checks on startup whether or not your cpu supports SSE. It does so by executing…
Jonas Maebe wrote 7 lines
The rtl checks on startup whether or not your cpu supports SSE. It does so by executing an SSE instruction, catching the "illegal instruction" exception if it occurs and if so, setting a boolean to false. So just type "continue" in gdb to continue the program.

And what should I do in MSEide? Disable SIGILL reporting by gdb? How does Lazarus handle the problem?

Martin

Reply by email

Unknown author
to Martin Schreiber

----- Original Message -----

Earlier message 19 lines
From: Martin Schreiber Date: Tuesday, July 10, 2007 2:44 pm Subject: Re: [fpc-devel] win32 debugging broken in fixes_2_2? > On Tuesday 10 July 2007 14.34, Jonas Maebe wrote: > > The rtl checks on startup whether or not your cpu supports SSE. It > > does so by executing an SSE instruction, catching the "illegal > > instruction" exception if it occurs and if so, setting a boolean to > > false. > > > > So just type "continue" in gdb to continue the program. > > > And what should I do in MSEide? Disable SIGILL reporting by gdb? > How does Lazarus handle the problem? > It does not handle it. If you handle it in MSEIDE, please let us know how you did it. Vincent

Reply by email

Martin Schreiber
to Unknown author
Show quoted text 6 lines
> And what should I do in MSEide? Disable SIGILL reporting by gdb? > How does Lazarus handle the problem? It does not handle it. If you handle it in MSEIDE, please let us know how you did it.

The IDE must check where the SIGILL is created, prevent error reporting and restart the program if the SIGILL is raised in the FPC SSE checking code...

Question to the FPC developers:
Is there really no other method to check for SSE support?

Martin

Reply by email

Jonas Maebe
to Martin Schreiber: Are there other places where SIGILL for checking purposes could be raised out of…
Martin Schreiber wrote 11 lines
On Tuesday 10 July 2007 15.13, Jonas Maebe wrote: > On 10 Jul 2007, at 15:11, Martin Schreiber wrote: >> Question to the FPC developers: >> Is there really no other method to check for SSE support? > > According to the comments of Florian in the code, there is no other > way which works everywhere. Are there other places where SIGILL for checking purposes could be raised out of "SYSTEM_FPC_CPUCODEINIT"?

Not at this time, afaik.

Are there other possible signals which must be handled by the IDE?

I don't think so.

Jonas

Reply by email

Martin Schreiber
to Jonas Maebe: According to the comments of Florian in the code, there is no other way which works…
Jonas Maebe wrote 7 lines
On 10 Jul 2007, at 15:11, Martin Schreiber wrote: > Question to the FPC developers: > Is there really no other method to check for SSE support? According to the comments of Florian in the code, there is no other way which works everywhere.

Are there other places where SIGILL for checking purposes could be raised out of "SYSTEM_FPC_CPUCODEINIT"?
Are there other possible signals which must be handled by the IDE?

Martin

Reply by email

Martin Schreiber
to Jonas Maebe: The rtl checks on startup whether or not your cpu supports SSE. It does so by executing…
Jonas Maebe wrote 7 lines
The rtl checks on startup whether or not your cpu supports SSE. It does so by executing an SSE instruction, catching the "illegal instruction" exception if it occurs and if so, setting a boolean to false. So just type "continue" in gdb to continue the program.

Continue does not work:
"
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: G:\testcase\mse\console/console.exe Loaded symbols for C:\WINNT\system32\KERNEL32.DLL
Loaded symbols for C:\WINNT\system32\OLEAUT32.DLL
Loaded symbols for C:\WINNT\system32\OLE32.DLL
Loaded symbols for C:\WINNT\system32\rpcrt4.dll
Loaded symbols for C:\WINNT\system32\ADVAPI32.DLL
Loaded symbols for C:\WINNT\system32\GDI32.DLL
Loaded symbols for C:\WINNT\system32\USER32.DLL

Program received signal SIGILL, Illegal instruction. 0x00402091 in SYSTEM_FPC_CPUCODEINIT ()
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction. 0x00402091 in SYSTEM_FPC_CPUCODEINIT ()
(gdb) c
Continuing.

Program exited with code 0200.
(gdb)
"
And now what to do?

Martin

Reply by email

Jonas Maebe
to Martin Schreiber
Martin Schreiber wrote 9 lines
Program received signal SIGILL, Illegal instruction. 0x00402091 in SYSTEM_FPC_CPUCODEINIT () (gdb) c Continuing. Program exited with code 0200. (gdb) " And now what to do?

It seems that either your specific gdb is broken, or that gdb for win32 is broken in this regard. By default, gdb's setting for SIGILL should be:

(gdb) info handle SIGILL
Signal Stop Print Pass to program Description SIGILL Yes Yes Yes Illegal instruction

This means that when a SIGILL occurs, gdb will stop the program and print the fact that a SIGILL occurred, but that if you continue it should be passed on to the program. The program's exception handler will then catch it. E.g., under Linux/i386 on a cpu which does not support SSE instructions:

(gdb) r
Starting program: /home/jmaebe/lnxhome/fpc/test/tt2 Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xb53000

Program received signal SIGILL, Illegal instruction. FPC_CPUCODEINIT () at i386.inc:1244
1244 i386.inc: No such file or directory.
in i386.inc
(gdb) c
Continuing.
0.01
0.01

You can also disable gdb catching SIGILL from the start of the program using "handle SIGILL nostop noprint" (in case gdb for win32 is broken in this respect), but then you should re-enable it later on (unless you don't want the debugger to break when an illegal instruction is executed).

Jonas

Reply by email

Martin Schreiber
to Jonas Maebe
Jonas Maebe wrote 8 lines
It seems that either your specific gdb is broken, or that gdb for win32 is broken in this regard. By default, gdb's setting for SIGILL should be: (gdb) info handle SIGILL Signal Stop Print Pass to program Description SIGILL Yes Yes Yes Illegal instruction

Same with the FPC supplied gdb:
"
G:\testcase\mse\console>E:\FPC\2.0.4\bin\i386-win32\gdb.exe console.exe GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /cygdrive/g/testcase/mse/console/console.exe

Program received signal SIGILL, Illegal instruction. $00402091 in SYSTEM_FPC_CPUCODEINIT ()
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction. $00402091 in SYSTEM_FPC_CPUCODEINIT ()
(gdb) c
Continuing.

Program exited with code 0200.
(gdb) info signal SIGILL
Signal Stop Print Pass to program Description SIGILL Yes Yes Yes Illegal instruction (gdb)
"
Is someone able to reproduce on a PII Windows box? The test program is attached.

Martin

Reply by email

Jonas Maebe
to Martin Schreiber
Martin Schreiber wrote 10 lines
On Tuesday 10 July 2007 17.04, Jonas Maebe wrote: > It seems that either your specific gdb is broken, or that gdb for > win32 is broken in this regard. By default, gdb's setting for SIGILL > should be: > > (gdb) info handle SIGILL > Signal Stop Print Pass to program Description > SIGILL Yes Yes Yes Illegal instruction > Same with the FPC supplied gdb:

It's quite possible this simply doesn't work properly with gdb for Windows. It doesn't either with gdb for Mac OS X, due to gdb interfering in the translation of mach signals to unix signals. There may be a similar problem with gdb for Windows.

Jonas

Reply by email

Florian Klaempfl
to Martin Schreiber: The IDE must check where the SIGILL is created, prevent error reporting and restart the…
Show quoted text 11 lines
On Tuesday 10 July 2007 14.53, wrote: >> And what should I do in MSEide? Disable SIGILL reporting by gdb? >> How does Lazarus handle the problem? > It does not handle it. If you handle it in MSEIDE, please let us know how > you did it. > The IDE must check where the SIGILL is created, prevent error reporting and restart the program if the SIGILL is raised in the FPC SSE checking code... Question to the FPC developers: Is there really no other method to check for SSE support?

No, silly enough. Checking some cpuid result is enough to check if the CPU supports it. But CPU support doesn't mean OS support. And to check if the OS supports SSE you've to execute an sse instruction and handle the exception.

Reply by email

Florian Klaempfl
to Vinzent Hoefler: To be more precise, the way recommended by Intel: "To make this check, execute the CPUID…
Show quoted text 13 lines
On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote: > On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: >> Maybe other way to detect SSE support exists... > CPUID? To be more precise, the way recommended by Intel: "To make this check, execute the CPUID instruction with an argument of 1 in the EAX register, and check that bit 25 (SSE) and/or bit 26 (SSE2) are set to 1." -- IA32 Software Developer's Manual, Volume 3: System Programming Guide

This gives you only the information that the CPU supports it but not if the OS supports it.

Reply by email

Yury Sidorov
to Florian Klaempfl: No, silly enough. Checking some cpuid result is enough to check if the CPU supports it.…

From: "Florian Klaempfl"

Show quoted text 23 lines
Martin Schreiber schrieb: > On Tuesday 10 July 2007 14.53, wrote: >>> And what should I do in MSEide? Disable SIGILL reporting by gdb? >>> How does Lazarus handle the problem? >> It does not handle it. If you handle it in MSEIDE, please let us >> know how >> you did it. >> > The IDE must check where the SIGILL is created, prevent error > reporting and > restart the program if the SIGILL is raised in the FPC SSE checking > code... > > Question to the FPC developers: > Is there really no other method to check for SSE support? No, silly enough. Checking some cpuid result is enough to check if the CPU supports it. But CPU support doesn't mean OS support. And to check if the OS supports SSE you've to execute an sse instruction and handle the exception.

Florian, to prevent SIGILL on non SSE CPUs we can first check CPUID and execute sse instruction only if CPUID reports SSE support.

Yury.

Reply by email

Sergei Gorelkin
to Florian Klaempfl: This gives you only the information that the CPU supports it but not if the OS supports…

Wednesday, July 11, 2007, 12:06:51 AM, Florian wrote:

Show quoted text 16 lines
> On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote: >> On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: >>> Maybe other way to detect SSE support exists... >> CPUID? > > To be more precise, the way recommended by Intel: > > "To make this check, execute the CPUID instruction with an argument of 1 > in the EAX register, and check that bit 25 (SSE) and/or bit 26 (SSE2) > are set to 1." > > -- IA32 Software Developer's Manual, > Volume 3: System Programming Guide This gives you only the information that the CPU supports it but not if the OS supports it.

But, if CPU has no SSE2 support, then OS is unable to support it, too? And if CPU has SSE2 support, modern OSes probably tend to support it. Thus, by checking CPUID before attempting to execute an SSE2 instruction you'll be able to exclude exceptions in vast majority of cases.

Best regards, Sergei

Reply by email

Martin Schreiber
to Jonas Maebe: It seems that either your specific gdb is broken, or that gdb for win32 is broken in this…
Jonas Maebe wrote 6 lines
You can also disable gdb catching SIGILL from the start of the program using "handle SIGILL nostop noprint" (in case gdb for win32 is broken in this respect), but then you should re-enable it later on (unless you don't want the debugger to break when an illegal instruction is executed).

Does not work:
"
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"...
(gdb) handle SIGILL nostop noprint
Signal Stop Print Pass to program Description SIGILL No No Yes Illegal instruction (gdb) r
Starting program: G:\msegui\testcase\mse\console/console.exe Loaded symbols for C:\WINNT\system32\KERNEL32.DLL
Loaded symbols for C:\WINNT\system32\OLEAUT32.DLL
Loaded symbols for C:\WINNT\system32\OLE32.DLL
Loaded symbols for C:\WINNT\system32\rpcrt4.dll
Loaded symbols for C:\WINNT\system32\ADVAPI32.DLL
Loaded symbols for C:\WINNT\system32\GDI32.DLL
Loaded symbols for C:\WINNT\system32\USER32.DLL

Program exited with code 0200.
(gdb)
"
It seems to be a blocking issue for developing with FPC 2.2 on win32 with PII processor.

Martin

Reply by email

Micha Nelissen
to Yury Sidorov: From: "Florian Klaempfl" Florian, to prevent SIGILL on non SSE CPUs we can first check…
Yury Sidorov wrote 6 lines
> CPU supports it. But CPU support doesn't mean OS support. And to check > if the OS supports SSE you've to execute an sse instruction and handle > the exception. Florian, to prevent SIGILL on non SSE CPUs we can first check CPUID and execute sse instruction only if CPUID reports SSE support.

What happens then if OS doesn't support it ?

Micha

Reply by email

Florian Klaempfl
to Sergei Gorelkin: But, if CPU has no SSE2 support, then OS is unable to support it, too? And if CPU has…
Show quoted text 25 lines
Wednesday, July 11, 2007, 12:06:51 AM, Florian wrote: FK> Vinzent Hoefler schrieb: >> On Tuesday 10 July 2007 09:58, Vinzent Hoefler wrote: >>> On Tuesday 10 July 2007 12:40, Yury Sidorov wrote: >>>> Maybe other way to detect SSE support exists... >>> CPUID? >> To be more precise, the way recommended by Intel: >> >> "To make this check, execute the CPUID instruction with an argument of 1 >> in the EAX register, and check that bit 25 (SSE) and/or bit 26 (SSE2) >> are set to 1." >> >> -- IA32 Software Developer's Manual, >> Volume 3: System Programming Guide > This gives you only the information that the CPU supports it but not if > the OS supports it. But, if CPU has no SSE2 support, then OS is unable to support it, too? And if CPU has SSE2 support, modern OSes probably tend to support it. Thus, by checking CPUID before attempting to execute an SSE2 instruction you'll be able to exclude exceptions in vast majority of cases.

That's a point though I thought we could safe this extra check because I didn't expect that a lot of people are still using PII :)

Reply by email

Florian Klaempfl
to Micha Nelissen: What happens then if OS doesn't support it ? Micha
Show quoted text 9 lines
Yury Sidorov wrote: >> CPU supports it. But CPU support doesn't mean OS support. And to check >> if the OS supports SSE you've to execute an sse instruction and handle >> the exception. > > Florian, to prevent SIGILL on non SSE CPUs we can first check CPUID > and execute sse instruction only if CPUID reports SSE support. What happens then if OS doesn't support it ?

SIGILL on the first sse instruction.

Reply by email

Vinzent Hoefler
to Florian Klaempfl: That's a point though I thought we could safe this extra check because I didn't expect…
Florian Klaempfl wrote
That's a point though I thought we could safe this extra check because I didn't expect that a lot of people are still using PII :)

Well, if the OS supports SSE and thus no SIGILL is generated, what would be the point in using CPUID to check for SSE *after* that at all? ;)

Honestly, I don't think that "extra check" would hurt anyone.

Vinzent.

Reply by email

Florian Klaempfl
to Vinzent Hoefler
Show quoted text 7 lines
On Wednesday 11 July 2007 06:39, Florian Klaempfl wrote: > That's a point though I thought we could safe this extra check > because I didn't expect that a lot of people are still using PII :) Well, if the OS supports SSE and thus no SIGILL is generated, what would be the point in using CPUID to check for SSE *after* that at all? ;)

To get the level of sse support but this is not used by the system iirc so we can swap these checks indeed.

Show quoted text 9 lines
Honestly, I don't think that "extra check" would hurt anyone. Vinzent. _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Alexander
That's a point though I thought we could safe this extra check because I didn't expect that a lot of people are still using PII :)

My current computer is PII. 350MHz 128 RAM 40G HDD It work !
Free soft inteneded for save old computers.
Linux kernel can run on 386 CPU and support MFM HDD. FPC and MSE must work on PII !
MSE MUST BE IN TOP PRIORITY AT FPC DEVELOPERS !
FPC have only one working RAD IDE - MSE.

Reply by email

Martin Schreiber
to Unknown author: ----- Original Message ----- From: Martin Schreiber Date: Tuesday, July 10, 2007 2:44 pm…
Show quoted text 19 lines
----- Original Message ----- From: Martin Schreiber Date: Tuesday, July 10, 2007 2:44 pm Subject: Re: [fpc-devel] win32 debugging broken in fixes_2_2? > On Tuesday 10 July 2007 14.34, Jonas Maebe wrote: > > The rtl checks on startup whether or not your cpu supports SSE. It > > does so by executing an SSE instruction, catching the "illegal > > instruction" exception if it occurs and if so, setting a boolean to > > false. > > > > So just type "continue" in gdb to continue the program. > > And what should I do in MSEide? Disable SIGILL reporting by gdb? > How does Lazarus handle the problem? It does not handle it. If you handle it in MSEIDE, please let us know how you did it.

I uploaded a patch to Mantis which prevents for thowing an exception with an PII on Linux and win32.

http://www.freepascal.org/mantis/view.php?id=9242

The exception address evaluating by the IDE method does not work on win32 because of gdb problems. It would be a nightmare to implement anyway.

Martin

Reply by email