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

Vincent.Blondeau at lamresearch.com Vincent.Blondeau at lamresearch.com
Fri Apr 20 16:23:40 UTC 2018


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?

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

Vincent

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180420/81cd6031/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pharo.def
Type: application/octet-stream
Size: 5380 bytes
Desc: Pharo.def
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180420/81cd6031/attachment-0001.obj>


More information about the Vm-dev mailing list