VM debugging - breakpoint issue on Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

VM debugging - breakpoint issue on Windows

Vincent.Blondeau
 

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

 

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Eliot Miranda-2
 
Hi Vincent,


On Apr 18, 2018, at 11:33 AM, <[hidden email]> <[hidden email]> 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

 

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Vincent.Blondeau
 

 

 

From: Vm-dev [mailto:[hidden email]] On Behalf Of Eliot Miranda
Sent: Wednesday, April 18, 2018 14:36
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows

 

Hi Vincent,

 

 

> On Apr 18, 2018, at 11:33 AM, <[hidden email]> <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

David T. Lewis
In reply to this post by 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, [hidden email] 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
>

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

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:[hidden email]] On Behalf Of David T. Lewis
Sent: Wednesday, April 18, 2018 17:35
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
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, [hidden email] 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
>

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

David T. Lewis
 
I don't have the code in front of me, but look for configuration files
called "plugins.int" and "plugins.ext" that specify plugins to be built
either as internal or external. IIRC, the mvm scripts might clobber your
local edits so you may have to play around with which files to edit where.

Dave

>
> 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:[hidden email]] On Behalf
> Of David T. Lewis
> Sent: Wednesday, April 18, 2018 17:35
> To: Open Smalltalk Virtual Machine Development Discussion
> <[hidden email]>
> 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, [hidden email]
> 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
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Eliot Miranda-2
In reply to this post by Vincent.Blondeau
 
Hi Vincent,

On Thu, Apr 19, 2018 at 9:30 AM, <[hidden email]> 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:[hidden email]] On Behalf Of David T. Lewis
Sent: Wednesday, April 18, 2018 17:35
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
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, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Eliot Miranda-2
 
Hi Vincent,

On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda <[hidden email]> wrote:
Hi Vincent,

On Thu, Apr 19, 2018 at 9:30 AM, <[hidden email]> 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:[hidden email]] On Behalf Of David T. Lewis
Sent: Wednesday, April 18, 2018 17:35
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
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, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Nicolas Cellier
 
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 <[hidden email]> a écrit :
 
Hi Vincent,

On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda <[hidden email]> wrote:
Hi Vincent,

On Thu, Apr 19, 2018 at 9:30 AM, <[hidden email]> 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:[hidden email]] On Behalf Of David T. Lewis
Sent: Wednesday, April 18, 2018 17:35
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
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, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Vincent.Blondeau
 

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:[hidden email]] On Behalf Of Nicolas Cellier
Sent: Thursday, April 19, 2018 12:19
To: Squeak Virtual Machine Development Discussion <[hidden email]>
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 <[hidden email]> a

écrit :

 

> 

> Hi Vincent,

> 

> On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda <[hidden email]>

> wrote:

> 

>> Hi Vincent,

>> 

>> On Thu, Apr 19, 2018 at 9:30 AM, <[hidden email]>

>> 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:[hidden email]] On

>>> Behalf Of David T. Lewis

>>> Sent: Wednesday, April 18, 2018 17:35

>>> To: Open Smalltalk Virtual Machine Development Discussion <

>>> [hidden email]>

>>> 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,

>>> [hidden email] 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

> 

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Eliot Miranda-2
 
Hi Vincent,


On Apr 19, 2018, at 1:49 PM, <[hidden email]> <[hidden email]> 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 [[hidden email]] On Behalf Of Nicolas Cellier
Sent: Thursday, April 19, 2018 12:19
To: Squeak Virtual Machine Development Discussion <[hidden email]>
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 <[hidden email]> a

écrit :

 

> 

> Hi Vincent,

> 

> On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda <[hidden email]>

> wrote:

> 

>> Hi Vincent,

>> 

>> On Thu, Apr 19, 2018 at 9:30 AM, <[hidden email]>

>> 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 [[hidden email]] On

>>> Behalf Of David T. Lewis

>>> Sent: Wednesday, April 18, 2018 17:35

>>> To: Open Smalltalk Virtual Machine Development Discussion <

>>> [hidden email]>

>>> 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,

>>> [hidden email] 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

> 

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Vincent.Blondeau
 

 

 

From: Vm-dev [mailto:[hidden email]] On Behalf Of Eliot Miranda
Sent: Thursday, April 19, 2018 14:08
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows

 

Hi Vincent,

 

 

> On Apr 19, 2018, at 1:49 PM, <[hidden email]> <[hidden email]> 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:[hidden email]] On Behalf Of Nicolas Cellier

> Sent: Thursday, April 19, 2018 12:19

> To: Squeak Virtual Machine Development Discussion <[hidden email]>

> 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 <[hidden email]> a

> écrit :

> >

> > Hi Vincent,

> >

> > On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda <[hidden email]>

> > wrote:

> >

> >> Hi Vincent,

> >>

> >> On Thu, Apr 19, 2018 at 9:30 AM, <[hidden email]>

> >> 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:[hidden email]] On

> >>> Behalf Of David T. Lewis

> >>> Sent: Wednesday, April 18, 2018 17:35

> >>> To: Open Smalltalk Virtual Machine Development Discussion <

> >>> [hidden email]>

> >>> 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,

> >>> [hidden email] 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

> >

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Ben Coman
 


On 20 April 2018 at 07:45, <[hidden email]> wrote:
 

 

 

From: Vm-dev [mailto:[hidden email]] On Behalf Of Eliot Miranda
Sent: Thursday, April 19, 2018 14:08
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows

 

Hi Vincent,

 

 

> On Apr 19, 2018, at 1:49 PM, <[hidden email]> <[hidden email]> 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...
(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)


cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Vincent.Blondeau
 

From: Vm-dev [mailto:[hidden email]] On Behalf Of Ben Coman
Sent: Thursday, April 19, 2018 19:00
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows

 

On 20 April 2018 at 07:45, <[hidden email]> wrote:

 

> 

> 

> 

> 

> 

> 

> *From:* Vm-dev [mailto:[hidden email]] *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, <[hidden email]> <

> [hidden email]> 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?

 

Also, I am successfully debugging the primitive I am writing.

 

Vincent

 

cheers -ben


Pharo.def (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VM debugging - breakpoint issue on Windows

Eliot Miranda-2
 
Hi Vincent,

On Fri, Apr 20, 2018 at 9:23 AM, <[hidden email]> wrote:
 

From: Vm-dev [mailto:[hidden email]] On Behalf Of Ben Coman
Sent: Thursday, April 19, 2018 19:00
To: Open Smalltalk Virtual Machine Development Discussion <[hidden email]>
Subject: Re: [Vm-dev] VM debugging - breakpoint issue on Windows

 

On 20 April 2018 at 07:45, <[hidden email]> wrote:

 

> 

> 

> 

> 

> 

> 

> *From:* Vm-dev [mailto:[hidden email]] *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, <[hidden email]> <

> [hidden email]> 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