[Vm-dev] VM debugging - breakpoint issue on Windows

Thu Apr 19 23:45:42 UTC 2018

From: Vm-dev [mailto:vm-dev-bounces at lists.squeakfoundation.org] On Behalf Of Eliot Miranda
Sent: Thursday, April 19, 2018 14:08
To: Open Smalltalk Virtual Machine Development Discussion <vm-dev at 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 at lamresearch.com> <Vincent.Blondeau at 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 at lists.squeakfoundation.org] On Behalf Of Nicolas Cellier
> Sent: Thursday, April 19, 2018 12:19
> To: Squeak Virtual Machine Development Discussion <vm-dev at 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 at gmail.com> a
> écrit :
>
> >
> > Hi Vincent,
> >
> > On Thu, Apr 19, 2018 at 11:27 AM, Eliot Miranda <eliot.miranda at gmail.com>
> > wrote:
> >
> >> Hi Vincent,
> >>
> >> On Thu, Apr 19, 2018 at 9:30 AM, <Vincent.Blondeau at 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 at 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 at 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 at 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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180419/3e84df9f/attachment-0001.html>