Thank you. I've now committed the patch with some improvements in r1781019.

On Tue, Jan 31, 2017 at 6:55 AM, Patricia Shanahan <[email protected]> wrote:

> I did some more testing, and it seems to be a Visual Studio weirdness. It
> was showing my breakpoint as "no symbols loaded". However, when I ran a
> test case that I know goes through that breakpoint, it turned red and
> worked.
>
>
> On 1/30/2017 8:28 PM, Damjan Jovanovic wrote:
>
>> That's unusual. It should either fix it for all gbuild modules, or none of
>> them. In the build log for main/sw, is "-DEBUG" passed to the linker?
>> Please send it through if unsure.
>>
>> I haven't had a chance to test it myself as debugging is currently broken
>> with precompiled headers, and my Windows VM doesn't have disk space for a
>> debug build anyway...
>>
>> On Tue, Jan 31, 2017 at 6:24 AM, Patricia Shanahan <[email protected]> wrote:
>>
>> Applying the patch fixed the vcl case, but not the one I really care
>>> about, main/sw
>>>
>>>
>>> On 1/29/2017 6:51 PM, Patricia Shanahan wrote:
>>>
>>>
>>>>
>>>> On 1/29/2017 5:59 PM, Damjan Jovanovic wrote:
>>>>
>>>> I am trying a Windows rebuild now. In the meanwhile, what debugger are
>>>>> you using? Can you debug any other modules, eg. vcl which uses gbuild,
>>>>> or sal which uses dmake?
>>>>>
>>>>>
>>>> I'm using Visual Studio Community 2013.
>>>>
>>>> sal: Yes, at least the breakpoint stays red in the breakpoints display.
>>>> vcl: No, "No symbols have been loaded for this document".
>>>>
>>>>
>>>>
>>>> It's possible that Windows also needs gb_LinkTarget_LDFLAGS += -DEBUG to
>>>>> enable debugging, as per the "ifeq ($(gb_DEBUGLEVEL),2)" part of
>>>>> solenv/gbuild/platform/windows.mk <http://windows.mk>. If so, please
>>>>> try
>>>>> the attached patch which should do that.
>>>>>
>>>>>
>>>> I'll try it.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> On Sun, Jan 29, 2017 at 10:34 PM, Patricia Shanahan <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>     On 1/25/2017 9:35 AM, Damjan Jovanovic wrote:
>>>>>
>>>>>         Hi
>>>>>
>>>>>         For a while I've noticed how gbuild modules don't have debug
>>>>>         symbols unless
>>>>>         built with the maximum debug level ("./configure
>>>>> --enable-debug"
>>>>>         globally
>>>>>         or "build debug=true" per module) which also produces oceans
>>>>> of log
>>>>>         messages we usually don't want.
>>>>>
>>>>>         In r1780246, I've finally changed debugging in gbuild to match
>>>>>         how dmake
>>>>>         works: --enable-symbols and --enable-crashdump now also add
>>>>>         debug symbols
>>>>>         to gbuild modules like they do to dmake modules, and the
>>>>>         --enable-symbols=small option is also implemented for GCC and
>>>>>         Clang (sorry
>>>>>         Windows developers, MSVC doesn't seem to have it). The only
>>>>>         extra benefit
>>>>>         of --enable-debug on top of this now, is that it disables
>>>>> compiler
>>>>>         optimizations - should we disable them for --enable-symbols
>>>>> too?
>>>>>
>>>>>         In r1780248 I've also made Java's .class files get full
>>>>>         debugging info
>>>>>         whenever C++ does.
>>>>>
>>>>>         This should vastly improve running AOO under a debugger, as we
>>>>>         get nice
>>>>>         line numbers and variable names for absolutely everything :-).
>>>>>
>>>>>
>>>>>     I compiled with the attached configure parameters, and breakpoints
>>>>>     are not working in main/sw/source/ui/app/docsh.cx
>>>>>     <http://docsh.cx>x, "No symbols have been loaded for this
>>>>> document".
>>>>>     What should I change?
>>>>>
>>>>>
>>>>>     ------------------------------------------------------------
>>>>> ---------
>>>>>     To unsubscribe, e-mail: [email protected]
>>>>>     <mailto:[email protected]>
>>>>>     For additional commands, e-mail: [email protected]
>>>>>     <mailto:[email protected]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to