Hi,
I would like to set up a breakpoint in the VM but I got this error when running: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and invoque the primitive I want to test: pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless ../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337. (gdb) r Starting program: C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY." [New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
Hi Vincent,
On Apr 18, 2018, at 11:33 AM, Vincent.Blondeau@lamresearch.com Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error when running: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and invoque the primitive I want to test: pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe –headless ../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337. (gdb) r Starting program: C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY." [New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
AFAICT you're doing everything right. But if you're on 64-bit Cygwin then it won't work. You can build the 32-bit vm on a 64-bit windows but gdb can only be used to debug 64-bit programs. Even installing the gdb from 32-bit Cygwin doesn't work. So if this is your configuration you'll have the create a 32-but Cygwin and debug the 32-bit app there-on.
HTH
Thanks in advance,
Vincent Blondeau
From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Eliot Miranda Sent: Wednesday, April 18, 2018 14:36 To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
On Apr 18, 2018, at 11:33 AM, Vincent.Blondeau@lamresearch.com Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error when running: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and invoque the primitive I want to test: pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe –headless ../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337. (gdb) r Starting program: C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY." [New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
AFAICT you're doing everything right. But if you're on 64-bit Cygwin then it won't work. You can build the 32-bit vm on a 64-bit windows but gdb can only be used to debug 64-bit programs. Even installing the gdb from 32-bit Cygwin doesn't work. So if this is your configuration you'll have the create a 32-but Cygwin and debug the 32-bit app there-on.
I am debugging the 32 bits Pharo under this Cygwin: $ CYGWIN_NT-10.0-WOW 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin It is 32 bits too. So, it should work? Or if I have well understood your last sentence, I should I get a 32 bits gdb? How?
Vincent
PS: I am receiving most of the replies as email attachment in my outlook browser. Has someone the same issue?
HTH
Thanks in advance,
Vincent Blondeau
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error when running: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and invoque the primitive I want to test: pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless ../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337. (gdb) r Starting program: C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY." [New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
Hi Dave,
The optimization options are already disabled in the debug build and -ggdb2 is used. So, the real code is used.
How do I change the build in a way that the plugin is external?
Any experience is always welcome! Thanks!
Vincent
-----Original Message----- From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Wednesday, April 18, 2018 17:35 To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error when running: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and invoque the primitive I want to test: pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless ../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337. (gdb) r Starting program: C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY." [New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
Hi Vincent,
On Thu, Apr 19, 2018 at 9:30 AM, Vincent.Blondeau@lamresearch.com wrote:
Hi Dave,
The optimization options are already disabled in the debug build and -ggdb2 is used. So, the real code is used.
How do I change the build in a way that the plugin is external?
I see the same issue as you. I'll take a look.
Any experience is always welcome! Thanks!
Vincent
-----Original Message----- From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Wednesday, April 18, 2018 17:35 To: Open Smalltalk Virtual Machine Development Discussion <vm-dev@lists. squeakfoundation.org> Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error when
running:
Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and
invoque the primitive I want to test:
pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless
../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\
GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\ builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run the
app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c,
line 337.
(gdb) r Starting program: C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\
build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
[New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
Hi Vincent,
On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Vincent,
On Thu, Apr 19, 2018 at 9:30 AM, Vincent.Blondeau@lamresearch.com wrote:
Hi Dave,
The optimization options are already disabled in the debug build and -ggdb2 is used. So, the real code is used.
How do I change the build in a way that the plugin is external?
I see the same issue as you. I'll take a look.
Something I find strange is TOOLPREFIX:=i686-w64-mingw32-. I would have expected TOOLPREFIX:=i686-w32-mingw32-. Nicolas, have you looked at this recently?
Vincent, if you try compiling a Hello World and setting breakpoint in main you should be able to reproduce the issue. Then you can try different compilers quickly. I tried debugging the VM and putting a breakpoint in parseVMArgs, which is called to parse the command line. It fails also. So we have a problem :-(
Any experience is always welcome! Thanks!
Vincent
-----Original Message----- From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Wednesday, April 18, 2018 17:35 To: Open Smalltalk Virtual Machine Development Discussion < vm-dev@lists.squeakfoundation.org> Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.c om wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error when
running:
Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and
invoque the primitive I want to test:
pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless
../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from C:\Users\BlondVi\Documents\Git
Repos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\buildd bg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run
the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file ../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c,
line 337.
(gdb) r Starting program: C:\Users\BlondVi\Documents\Git
Repos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
[New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
-- _,,,^..^,,,_ best, Eliot
Hi Eliot, Mingw-w64 is a fork of mingw. It works for both 32 and 64 bits, contrarily to mingw which wad stuck to 32bits at the time of fork. I tjink that -w64- just refers to that.
Le jeu. 19 avr. 2018 à 20:39, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Vincent,
On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Vincent,
On Thu, Apr 19, 2018 at 9:30 AM, Vincent.Blondeau@lamresearch.com wrote:
Hi Dave,
The optimization options are already disabled in the debug build and -ggdb2 is used. So, the real code is used.
How do I change the build in a way that the plugin is external?
I see the same issue as you. I'll take a look.
Something I find strange is TOOLPREFIX:=i686-w64-mingw32-. I would have expected TOOLPREFIX:=i686-w32-mingw32-. Nicolas, have you looked at this recently?
Vincent, if you try compiling a Hello World and setting breakpoint in main you should be able to reproduce the issue. Then you can try different compilers quickly. I tried debugging the VM and putting a breakpoint in parseVMArgs, which is called to parse the command line. It fails also. So we have a problem :-(
Any experience is always welcome! Thanks!
Vincent
-----Original Message----- From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Wednesday, April 18, 2018 17:35 To: Open Smalltalk Virtual Machine Development Discussion < vm-dev@lists.squeakfoundation.org> Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error
when running:
Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and
invoque the primitive I want to test:
pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless
../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run
the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file
../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337.
(gdb) r Starting program:
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
[New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Hi all,
So I tested an hello world project, by trying different compilation options. Knowing that the ones that are in use to generate the .exe are: -mwindows -m32 -mthreads -Wl,--large-address-aware,--dynamicbase,--nxcompat,--export-all-symbols
I identified that having all the options expect export-all-symbols, works perfectly. And having all the options except dynamicbase works too.
I suppose that the options of the linker dynamicbase and export-all-symbols are conflicting and avoid to debug the app.
I will try to remove one and retry with the VM.
BTW, I have no idea of what these options do…
Cheers, Vincent
From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nicolas Cellier Sent: Thursday, April 19, 2018 12:19 To: Squeak Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Eliot, Mingw-w64 is a fork of mingw. It works for both 32 and 64 bits, contrarily to mingw which wad stuck to 32bits at the time of fork. I tjink that -w64- just refers to that.
Le jeu. 19 avr. 2018 à 20:39, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Vincent,
On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Vincent,
On Thu, Apr 19, 2018 at 9:30 AM, Vincent.Blondeau@lamresearch.com wrote:
Hi Dave,
The optimization options are already disabled in the debug build and -ggdb2 is used. So, the real code is used.
How do I change the build in a way that the plugin is external?
I see the same issue as you. I'll take a look.
Something I find strange is TOOLPREFIX:=i686-w64-mingw32-. I would have expected TOOLPREFIX:=i686-w32-mingw32-. Nicolas, have you looked at this recently?
Vincent, if you try compiling a Hello World and setting breakpoint in main you should be able to reproduce the issue. Then you can try different compilers quickly. I tried debugging the VM and putting a breakpoint in parseVMArgs, which is called to parse the command line. It fails also. So we have a problem :-(
Any experience is always welcome! Thanks!
Vincent
-----Original Message----- From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Wednesday, April 18, 2018 17:35 To: Open Smalltalk Virtual Machine Development Discussion < vm-dev@lists.squeakfoundation.org> Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error
when running:
Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and
invoque the primitive I want to test:
pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless
../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run
the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file
../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337.
(gdb) r Starting program:
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
[New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Hi Vincent,
On Apr 19, 2018, at 1:49 PM, Vincent.Blondeau@lamresearch.com Vincent.Blondeau@lamresearch.com wrote:
Hi all,
So I tested an hello world project, by trying different compilation options. Knowing that the ones that are in use to generate the .exe are: -mwindows -m32 -mthreads -Wl,--large-address-aware,--dynamicbase,--nxcompat,--export-all-symbols
I identified that having all the options expect export-all-symbols, works perfectly. And having all the options except dynamicbase works too.
Great, thanks!
I suppose that the options of the linker dynamicbase and export-all-symbols are conflicting and avoid to debug the app.
I will try to remove one and retry with the VM.
BTW, I have no idea of what these options do…
export-all-symbols tells the linker that all non-static symbols should be made available to dlls. In Windows, exporting is by a funky mechanism, an export table, instead of, as in Unix, by run-time/load-time linking. Using export-all-symbols avoids us having to use a .def file to specify the exports we need. So if you find out that things work properly without export-all-symbols then we shall have to maintain a .def file.
Bah...
Cheers, Vincent
From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nicolas Cellier Sent: Thursday, April 19, 2018 12:19 To: Squeak Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Eliot, Mingw-w64 is a fork of mingw. It works for both 32 and 64 bits, contrarily to mingw which wad stuck to 32bits at the time of fork. I tjink that -w64- just refers to that.
Le jeu. 19 avr. 2018 à 20:39, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Vincent,
On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Vincent,
On Thu, Apr 19, 2018 at 9:30 AM, Vincent.Blondeau@lamresearch.com wrote:
Hi Dave,
The optimization options are already disabled in the debug build and -ggdb2 is used. So, the real code is used.
How do I change the build in a way that the plugin is external?
I see the same issue as you. I'll take a look.
Something I find strange is TOOLPREFIX:=i686-w64-mingw32-. I would have expected TOOLPREFIX:=i686-w32-mingw32-. Nicolas, have you looked at this recently?
Vincent, if you try compiling a Hello World and setting breakpoint in main you should be able to reproduce the issue. Then you can try different compilers quickly. I tried debugging the VM and putting a breakpoint in parseVMArgs, which is called to parse the command line. It fails also. So we have a problem :-(
Any experience is always welcome! Thanks!
Vincent
-----Original Message----- From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Wednesday, April 18, 2018 17:35 To: Open Smalltalk Virtual Machine Development Discussion < vm-dev@lists.squeakfoundation.org> Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error
when running:
Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and
invoque the primitive I want to test:
pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless
../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run
the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file
../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337.
(gdb) r Starting program:
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
[New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Eliot Miranda Sent: Thursday, April 19, 2018 14:08 To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
On Apr 19, 2018, at 1:49 PM, Vincent.Blondeau@lamresearch.com Vincent.Blondeau@lamresearch.com wrote:
Hi all,
So I tested an hello world project, by trying different compilation options. Knowing that the ones that are in use to generate the .exe are: -mwindows -m32 -mthreads -Wl,--large-address-aware,--dynamicbase,--nxcompat,--export-all-symbols
I identified that having all the options expect export-all-symbols, works perfectly. And having all the options except dynamicbase works too.
Great, thanks!
I suppose that the options of the linker dynamicbase and export-all-symbols are conflicting and avoid to debug the app.
I will try to remove one and retry with the VM.
BTW, I have no idea of what these options do…
export-all-symbols tells the linker that all non-static symbols should be made available to dlls. In Windows, exporting is by a funky mechanism, an export table, instead of, as in Unix, by run-time/load-time linking. Using export-all-symbols avoids us having to use a .def file to specify the exports we need. So if you find out that things work properly without export-all-symbols then we shall have to maintain a .def file.
Bah...
I removed both options and recompiled, your breakpoint is reached in parseVMArgs !
Vincent
Cheers, Vincent
From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Nicolas Cellier Sent: Thursday, April 19, 2018 12:19 To: Squeak Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Eliot, Mingw-w64 is a fork of mingw. It works for both 32 and 64 bits, contrarily to mingw which wad stuck to 32bits at the time of fork. I tjink that -w64- just refers to that.
Le jeu. 19 avr. 2018 à 20:39, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Vincent,
On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Vincent,
On Thu, Apr 19, 2018 at 9:30 AM, Vincent.Blondeau@lamresearch.com wrote:
Hi Dave,
The optimization options are already disabled in the debug build and -ggdb2 is used. So, the real code is used.
How do I change the build in a way that the plugin is external?
I see the same issue as you. I'll take a look.
Something I find strange is TOOLPREFIX:=i686-w64-mingw32-. I would have expected TOOLPREFIX:=i686-w32-mingw32-. Nicolas, have you looked at this recently?
Vincent, if you try compiling a Hello World and setting breakpoint in main you should be able to reproduce the issue. Then you can try different compilers quickly. I tried debugging the VM and putting a breakpoint in parseVMArgs, which is called to parse the command line. It fails also. So we have a problem :-(
Any experience is always welcome! Thanks!
Vincent
-----Original Message----- From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Wednesday, April 18, 2018 17:35 To: Open Smalltalk Virtual Machine Development Discussion < vm-dev@lists.squeakfoundation.org> Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
I am not a Windows user so this may be completely wrong, but one thing I have found in debugging plugins on Linux is that it is often necessary to compile with optimization turned off so that the debugger is dealing with the "real" code.
I am guessing that perhaps your debugger is trying to use the C source code to locate something that got optimized away by the compiler.
Sometimes it is helpful to compile the plugin as an external plugin (a DLL). You can compile it with zero optimization and compiler flags set (-O0 -g or similar), and the resulting plugun should be visible to the debugger. The plugin that you compile this way should work with any VM (optimized or not) and the debugger should still be able to see it.
I have not done this on Windows, but that is my experience on Linux so maybe it will help.
Dave
On Wed, Apr 18, 2018 at 06:33:12PM +0000, Vincent.Blondeau@lamresearch.com wrote:
Hi,
I would like to set up a breakpoint in the VM but I got this error
when running:
Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
For this, I am using gdb under Cygwin (same issue with powershell) and
invoque the primitive I want to test:
pharo.cog.spur/builddbg/vm $ gdb --args ./Pharo.exe -headless
../..somewhereOnMyDisk.../Pharo.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
I get these results: GNU gdb (GDB) 7.6.1 Reading symbols from
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm\Pharo.exe...done.
Next, I set a breakpoint in the primitive C method I created and run
the app:
(gdb) br sqStdioDescriptorIsATTY Breakpoint 1 at 0x509cb6: file
../../platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c, line 337.
(gdb) r Starting program:
C:\Users\BlondVi\Documents\GitRepos\opensmalltalk-vm\build.win32x86\pharo.cog.spur\builddbg\vm/./Pharo.exe --headless ../../../../../../../../..temp/logoVM/logoVM.image eval "FilePluginPrims new primitiveStdioDescriptorIsATTY."
[New Thread 27416.0x95bc] [New Thread 27416.0xa1d0] [New Thread 27416.0x3aa4] [New Thread 27416.0x88bc] (gdb) Warning: Cannot insert breakpoint 1. Error accessing memory address 0x509cad: Input/output error.
What should I do to set the breakpoint correctly?
Thanks in advance,
Vincent Blondeau
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
On 20 April 2018 at 07:45, Vincent.Blondeau@lamresearch.com wrote:
*From:* Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] *On Behalf Of *Eliot Miranda *Sent:* Thursday, April 19, 2018 14:08 *To:* Open Smalltalk Virtual Machine Development Discussion <vm-dev@lists. squeakfoundation.org> *Subject:* Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
On Apr 19, 2018, at 1:49 PM, Vincent.Blondeau@lamresearch.com <
Vincent.Blondeau@lamresearch.com> wrote:
Hi all,
So I tested an hello world project, by trying different compilation
options. Knowing that the ones that are in use to generate the .exe are:
-mwindows -m32 -mthreads -Wl,--large-address-aware,--
dynamicbase,--nxcompat,--export-all-symbols
I identified that having all the options expect export-all-symbols,
works perfectly.
And having all the options except dynamicbase works too.
Great, thanks!
I suppose that the options of the linker dynamicbase and
export-all-symbols are conflicting and avoid to debug the app.
I will try to remove one and retry with the VM.
BTW, I have no idea of what these options do…
export-all-symbols tells the linker that all non-static symbols should be made available to dlls. In Windows, exporting is by a funky mechanism, an export table, instead of, as in Unix, by run-time/load-time linking. Using export-all-symbols avoids us having to use a .def file to specify the exports we need. So if you find out that things work properly without export-all-symbols then we shall have to maintain a .def file.
Bah...
I removed both options and recompiled, your breakpoint is reached in parseVMArgs !
Did that the produce a DEF file? which gdb would have loaded symbols from?
With the original compile options, did you try... $ gdb <executable>
dll-symbols <dllname.dll>
per libin_v's answer here... https://www.experts-exchange.com/questions/23792765/How-to-debug-a-DLL-using... (disclaimer, I'm not familiar with it. Its just interesting to search around learning more about it.)
-------------
Also, here is a suggestion that dynamicbase Address Space Layout Randomization may cause a problem with gdb (maybe a gdb bug) https://lists.gnu.org/archive/html/qemu-discuss/2016-04/msg00043.html
cheers -ben
From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Ben Coman Sent: Thursday, April 19, 2018 19:00 To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows
On 20 April 2018 at 07:45, Vincent.Blondeau@lamresearch.com wrote:
*From:* Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] *On Behalf Of *Eliot Miranda *Sent:* Thursday, April 19, 2018 14:08 *To:* Open Smalltalk Virtual Machine Development Discussion <vm-dev@lists. squeakfoundation.org> *Subject:* Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
On Apr 19, 2018, at 1:49 PM, Vincent.Blondeau@lamresearch.com <
Vincent.Blondeau@lamresearch.com> wrote:
Hi all,
So I tested an hello world project, by trying different compilation
options. Knowing that the ones that are in use to generate the .exe are:
-mwindows -m32 -mthreads -Wl,--large-address-aware,--
dynamicbase,--nxcompat,--export-all-symbols
I identified that having all the options expect export-all-symbols,
works perfectly.
And having all the options except dynamicbase works too.
Great, thanks!
I suppose that the options of the linker dynamicbase and
export-all-symbols are conflicting and avoid to debug the app.
I will try to remove one and retry with the VM.
BTW, I have no idea of what these options do…
export-all-symbols tells the linker that all non-static symbols should be made available to dlls. In Windows, exporting is by a funky mechanism, an export table, instead of, as in Unix, by run-time/load-time linking. Using export-all-symbols avoids us having to use a .def file to specify the exports we need. So if you find out that things work properly without export-all-symbols then we shall have to maintain a .def file.
Bah...
I removed both options and recompiled, your breakpoint is reached in parseVMArgs !
Did that the produce a DEF file? which gdb would have loaded symbols from?
Yes, it did. See attachment
With the original compile options, did you try... $ gdb <executable>
dll-symbols <dllname.dll>
per libin_v's answer here... https://urldefense.proofpoint.com/v2/url?u=https-3A__www.experts-2Dexchange.... (disclaimer, I'm not familiar with it. Its just interesting to search around learning more about it.)
I did not export the plugin as a DLL, the function I added is in an internal plugin. So it is embedded in the Pharo.exe.
-------------
Also, here is a suggestion that dynamicbase Address Space Layout Randomization may cause a problem with gdb (maybe a gdb bug) https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.gnu.org_archive_h...
Interesting! But, for the debug version, we may not need of these options, may we?
Also, I am successfully debugging the primitive I am writing.
Vincent
cheers -ben
Hi Vincent,
On Fri, Apr 20, 2018 at 9:23 AM, Vincent.Blondeau@lamresearch.com wrote:
*From:* Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] *On Behalf Of *Ben Coman *Sent:* Thursday, April 19, 2018 19:00 *To:* Open Smalltalk Virtual Machine Development Discussion <vm-dev@lists. squeakfoundation.org> *Subject:* Re: [Vm-dev] VM debugging - breakpoint issue on Windows
On 20 April 2018 at 07:45, Vincent.Blondeau@lamresearch.com wrote:
*From:* Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] *On
Behalf Of *Eliot Miranda
*Sent:* Thursday, April 19, 2018 14:08
*To:* Open Smalltalk Virtual Machine Development Discussion
<vm-dev@lists.
squeakfoundation.org>
*Subject:* Re: [Vm-dev] VM debugging - breakpoint issue on Windows
Hi Vincent,
On Apr 19, 2018, at 1:49 PM, Vincent.Blondeau@lamresearch.com <
Vincent.Blondeau@lamresearch.com> wrote:
Hi all,
So I tested an hello world project, by trying different compilation
options. Knowing that the ones that are in use to generate the .exe are:
-mwindows -m32 -mthreads -Wl,--large-address-aware,--
dynamicbase,--nxcompat,--export-all-symbols
I identified that having all the options expect export-all-symbols,
works perfectly.
And having all the options except dynamicbase works too.
Great, thanks!
I suppose that the options of the linker dynamicbase and
export-all-symbols are conflicting and avoid to debug the app.
I will try to remove one and retry with the VM.
BTW, I have no idea of what these options do…
export-all-symbols tells the linker that all non-static symbols should be
made available to dlls. In Windows, exporting is by a funky mechanism,
an
export table, instead of, as in Unix, by run-time/load-time linking.
Using
export-all-symbols avoids us having to use a .def file to specify the
exports we need. So if you find out that things work properly without
export-all-symbols then we shall have to maintain a .def file.
Bah...
I removed both options and recompiled, your breakpoint is reached in
parseVMArgs !
Did that the produce a DEF file? which gdb would have loaded symbols from?
Yes, it did. See attachment
With the original compile options, did you try...
$ gdb <executable>
dll-symbols <dllname.dll>
per libin_v's answer here...
https://urldefense.proofpoint.com/v2/url?u=https-3A__www. experts-2Dexchange.com_questions_23792765_How-2Dto- 2Ddebug-2Da-2DDLL-2Dusing-2DMinGW.html&d=DwIFaQ&c= RWI7EqL8K9lqtga8KxgfzvOYoob76EZWE0yAO85PVMQ&r= kIZIYXBAA3fhM7P5HOuTC5w6mnEApTfXPTq3lR34ZiY&m= VTBZ347Znkcb19dYAJpyGZbBH9kSN94xqgGbyASiY68&s= FMXQC5QfsEaoN2zTiVeKE1jgSwYDqtgbcOX9oiMQZkE&e=
(disclaimer, I'm not familiar with it. Its just interesting to search around learning more about it.)
I did not export the plugin as a DLL, the function I added is in an internal plugin. So it is embedded in the Pharo.exe.
Also, here is a suggestion that dynamicbase Address Space Layout
Randomization may cause a problem with gdb (maybe a gdb bug)
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists. gnu.org_archive_html_qemu-2Ddiscuss_2016-2D04_msg00043.html&d=DwIFaQ&c= RWI7EqL8K9lqtga8KxgfzvOYoob76EZWE0yAO85PVMQ&r= kIZIYXBAA3fhM7P5HOuTC5w6mnEApTfXPTq3lR34ZiY&m= VTBZ347Znkcb19dYAJpyGZbBH9kSN94xqgGbyASiY68&s=-LGIXGLImWQUDpFZvMnBEr- 3YP6qSZG0GCbckgRa0GA&e=
Interesting! But, for the debug version, we may not need of these options, may we?
Indeed; minnow may have chosen to make the effect of export-all-symbols on by default, which would be great. We have to research. The issue is this: - there are functions exported by the VM to plugins through the interpreterProxy/sqVirtualMachine interface; these are fine; they're marked export - there are functions exported implicitly from the graphics subsystem to certain external graphics plugins (IIRC B3DAccelleratorPlugin). These are not fine. It used to be that to get visibility of these functions in the plains one had to use export-all-symbols.
So we have to carefully test the VM compiled without export-all-symbols to know that things are OK. after today I will have a look at the lists of exported and imported symbols in at least the Mac and Linux VMs and try and identify some symbols that are not explicitly exported. We can then see if they're also used on Wndows and then test whether the access works.
Also, I am successfully debugging the primitive I am writing.
That's good news.
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
David T. Lewis -
Eliot Miranda -
Nicolas Cellier -
Vincent.Blondeau＠lamresearch.com