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

[Eliot Miranda]

Hi Vincent,

On Fri, Apr 20, 2018 at 9:23 AM, <Vincent.Blondeau at lamresearch.com> wrote:

>
>
> *From:* Vm-dev [mailto:vm-dev-bounces at lists.squeakfoundation.org] *On
> Behalf Of *Ben Coman
> *Sent:* Thursday, April 19, 2018 19:00
> *To:* Open Smalltalk Virtual Machine Development Discussion <vm-dev at lists.
> squeakfoundation.org>
> *Subject:* Re: [Vm-dev] VM debugging - breakpoint issue on Windows
>
>
>
> On 20 April 2018 at 07:45, <Vincent.Blondeau at lamresearch.com> wrote:
>
>
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > *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 !
>
> >
>
> >
>
> >
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180420/272a39a1/attachment-0001.html>