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

[Ben Coman]

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?

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-MinGW.html
(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180420/d1301556/attachment.html>