MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Hello,

Switching from MinGW 4.4.1 to MinGW 4.8.1 under Windows 7, I am
experimenting significant slowness when using gdb 7.6 and asking for
information about non-existing symbols with a command such as :
what is <symbol_name>

When with previous gdb version (gdb 6.8) this was taking no perceptibly
more time than for valid symbols, with the new version it takes several
seconds to get the error message. And the failure is not cached because
requesting again the same symbol, takes again the same time to fail
finding the symbol.

Is there a way to avoid this regression? I don't care to miss symbol
information that would need seconds to recover as I have never observed
that response time with the valid symbols of interest.

Remark: I have already tried without success to use the old debugger
with the new binaries (it fails loading the symbols due to Dwarf format
which is unsupported).

Philippe

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

asmwarrior
On 2014-8-5 5:43, Philippe wrote:

> Hello,
>
> Switching from MinGW 4.4.1 to MinGW 4.8.1 under Windows 7, I am
> experimenting significant slowness when using gdb 7.6 and asking for
> information about non-existing symbols with a command such as :
> what is <symbol_name>
>
> When with previous gdb version (gdb 6.8) this was taking no perceptibly
> more time than for valid symbols, with the new version it takes several
> seconds to get the error message. And the failure is not cached because
> requesting again the same symbol, takes again the same time to fail
> finding the symbol.
>
> Is there a way to avoid this regression? I don't care to miss symbol
> information that would need seconds to recover as I have never observed
> that response time with the valid symbols of interest.
>
> Remark: I have already tried without success to use the old debugger
> with the new binaries (it fails loading the symbols due to Dwarf format
> which is unsupported).
>
> Philippe

I don't have such issue, but if you can supply a simple test code, and tell me what is the step to reproduce, and I will try it myself.
I can test the latest GDB binary built from GDB git head.

Yuanhui Zhang

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Thanks for trying Yuanhui,

As I have the issue since months with the application I am developing, I
was sure it was a 'characteristics' of gdb 7.6. But I realize I cannot
reproduce it with simpler programs. Even with one which is only about 4
times smaller than my application.
It will be very difficult to isolate what is the root cause. Is it the
program size (17MB code + 100MB symbols)? the inclusion of a specific
DLL (among the 200+ included DLL)? A combinaison of both? Something else...

It may take a very long time to provide you with any valuable
information because doing dichotomous search in a program structure is
not a simple problem...

Philippe

Le 05/08/2014 02:40, asmwarrior a écrit :

> On 2014-8-5 5:43, Philippe wrote:
>> Hello,
>>
>> Switching from MinGW 4.4.1 to MinGW 4.8.1 under Windows 7, I am
>> experimenting significant slowness when using gdb 7.6 and asking for
>> information about non-existing symbols with a command such as :
>> what is <symbol_name>
>>
>> When with previous gdb version (gdb 6.8) this was taking no perceptibly
>> more time than for valid symbols, with the new version it takes several
>> seconds to get the error message. And the failure is not cached because
>> requesting again the same symbol, takes again the same time to fail
>> finding the symbol.
>>
>> Is there a way to avoid this regression? I don't care to miss symbol
>> information that would need seconds to recover as I have never observed
>> that response time with the valid symbols of interest.
>>
>> Remark: I have already tried without success to use the old debugger
>> with the new binaries (it fails loading the symbols due to Dwarf format
>> which is unsupported).
>>
>> Philippe
> I don't have such issue, but if you can supply a simple test code, and tell me what is the step to reproduce, and I will try it myself.
> I can test the latest GDB binary built from GDB git head.
>
> Yuanhui Zhang
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe
>
>
> -----
> Aucun virus trouve dans ce message.
> Analyse effectuee par AVG - www.avg.fr
> Version: 2014.0.4716 / Base de donnees virale: 3986/7979 - Date: 04/08/2014


------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
> Date: Wed, 06 Aug 2014 20:29:53 +0200
> From: Philippe <[hidden email]>
>
> As I have the issue since months with the application I am developing, I
> was sure it was a 'characteristics' of gdb 7.6. But I realize I cannot
> reproduce it with simpler programs. Even with one which is only about 4
> times smaller than my application.
> It will be very difficult to isolate what is the root cause. Is it the
> program size (17MB code + 100MB symbols)? the inclusion of a specific
> DLL (among the 200+ included DLL)? A combinaison of both? Something else...

Do you care about having DWARF2 debug info?  If not, try building your
DLLs and the executable with -gstabs, it might make the debug info
much smaller (this is what you had in older GCC versions).

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Hi Eli,

I don't know what DWARF4 brings over DWARF2 and I worked almost 10 years
with DWARF2 without major complain so I have immediately tried your
option. I though I would have to all recompile with the option: I mean
the program and the wxWidgets libraries. But I have been lazy and as
soon my application recompiled I tried to link it with the libraries
still in DWARF4. Good surprise: the problem has disappeared.

I just need to check for some time that I have really lost nothing I
could regret and I will be very happy.
Though as it becomes really easy to compile a variable part of the
application in DWARF4, I may try to isolate at what time the issue
starts to occur so we may have a chance to understand the origin of the
problem. Of course this is only if someone is interested in further
investigating the issue.

Philippe


Le 06/08/2014 20:48, Eli Zaretskii a écrit :
>
> Do you care about having DWARF2 debug info?  If not, try building your
> DLLs and the executable with -gstabs, it might make the debug info
> much smaller (this is what you had in older GCC versions).
>
>


------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Hello,

With -gstabs I have notice serious regressions in gdb behaviour for some
(at least one) methods:
- disas <name of the method>: the debugger never stops disassembling
- output this: the debugger provides a value that is incorrect. I have
not been able to determine from where this value comes from because the
stack (I reviewed 2 or 3 frames) nor the registers contains the
displayed value.
I don't know what is special in this method. It is rather short (3 lines
of codes) but contains a method call that returns an non-POD object
which causes a slightly complex assembly code to delete the temporary.

I tried also the -gdwarf-2 option in replacement of -gstabs option. But
it does not seem to do anything. With this option I don't observe the
-gstabs regression but I still get the slowness on displaying unknown
variables. I also tried to open the generated executable with the gdb 6
and it still complains that symbols are in DWARF 4 format!

Philippe

  Le 06/08/2014 20:48, Eli Zaretskii a écrit :
>> Do you care about having DWARF2 debug info?  If not, try building your
>> DLLs and the executable with -gstabs, it might make the debug info
>> much smaller (this is what you had in older GCC versions).
>>
>>
>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
> Date: Fri, 08 Aug 2014 13:34:11 +0200
> From: Philippe <[hidden email]>
>
> With -gstabs I have notice serious regressions in gdb behaviour for some
> (at least one) methods:

You could simply continue using your previous GDB version, with stabs.

> - disas <name of the method>: the debugger never stops disassembling
> - output this: the debugger provides a value that is incorrect. I have
> not been able to determine from where this value comes from because the
> stack (I reviewed 2 or 3 frames) nor the registers contains the
> displayed value.

If you are using C++, then stabs indeed have known problems.  Since
you said your previous versions of compiler and debugger didn't use
DWARF, I assumed that stabs should be OK for you.  Now I'm confused:
how did you succeed in debugging your C++ code with the previous
setup?

> I tried also the -gdwarf-2 option in replacement of -gstabs option. But
> it does not seem to do anything.

In the latest versions of GCC, -gdwarf-2 is the default.  And you
began by describing a problem that is specific to DWARF (voluminous
debug info), so going back to DWARF will simply give you back that
problem.

> With this option I don't observe the -gstabs regression but I still
> get the slowness on displaying unknown variables.

See above: that's expected.

> I also tried to open the generated executable with the gdb 6 and it
> still complains that symbols are in DWARF 4 format!

GDB 6 is confused.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Le 08/08/2014 15:39, Eli Zaretskii a écrit :
With -gstabs I have notice serious regressions in gdb behaviour for some 
(at least one) methods:
You could simply continue using your previous GDB version, with stabs.
I believe I have tried that and I still got the error about DRAWF version even with compile/link with -gstabs :
Dwarf Error: wrong version in compilation unit header (is 4, should be 2)
I can't explain why especially if you are right saying that the default -drawf option is 2. I have still a doubt because I read in the manual:
-gdwarf-version
Produce debugging information in DWARF format (if that is supported). The value of version may be either 2, 3 or 4; the default version for most targets is 4


- disas <name of the method>: the debugger never stops disassembling
- output this: the debugger provides a value that is incorrect. I have 
not been able to determine from where this value comes from because the 
stack (I reviewed 2 or 3 frames) nor the registers contains the 
displayed value.
If you are using C++, then stabs indeed have known problems.  Since
you said your previous versions of compiler and debugger didn't use
DWARF, I assumed that stabs should be OK for you.  Now I'm confused:
how did you succeed in debugging your C++ code with the previous
setup?
With GCC 4.4.1 and -g option, using GDB 6.8 I was able to debug C++
With GCC 4.8.1 and -g option, using GDB 7.6 I was able to debug C++ with the limitation of the slowness when trying to display inexisting or out of scope variables
With GCC 4.8.1 and -gstabs options using GDB 7.6, I do not experiment the slowness but see regression in debugging C++ on one method (until entering this one it looked like all was working fine)
With GCC 4.8.1 whatever debug option I use, GDB 6.8 always complain about symbol format. This is unusable.


I tried also the -gdwarf-2 option in replacement of -gstabs option. But 
it does not seem to do anything.
In the latest versions of GCC, -gdwarf-2 is the default.  And you
began by describing a problem that is specific to DWARF (voluminous
debug info), so going back to DWARF will simply give you back that
problem.
With the reference manual that suggests the contrary and the GDB 6.8 error message that complains about version 4, this was not obvious.

Philippe

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
> Date: Fri, 08 Aug 2014 16:53:22 +0200
> From: Philippe <[hidden email]>
>
> >> I tried also the -gdwarf-2 option in replacement of -gstabs option. But
> >> it does not seem to do anything.
> > In the latest versions of GCC, -gdwarf-2 is the default.  And you
> > began by describing a problem that is specific to DWARF (voluminous
> > debug info), so going back to DWARF will simply give you back that
> > problem.
> With the reference manual that suggests the contrary and the GDB 6.8
> error message that complains about version 4, this was not obvious.

Yes, I know.  The manual describes the GNU/Linux defaults, not the
MinGW defaults.

As for the other problems, the only advice I can give you is downgrade
to older versions of GCC.  (Or by a faster machine.)  DWARF is a
voluminous format (it has to be, to describe accurately all the
compiler optimizations and code reordering), so there's no way around
that as long as you use C++.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Le 08/08/2014 17:20, Eli Zaretskii a écrit :
> As for the other problems, the only advice I can give you is downgrade
> to older versions of GCC.  (Or by a faster machine.)  DWARF is a
> voluminous format (it has to be, to describe accurately all the
> compiler optimizations and code reordering), so there's no way around
> that as long as you use C++.
>
Buying a faster machine would not change significantly the result as
during the time gdb hangs it only uses one thread. I could have a
machine with 1 million cores it would not go faster. And I would need a
x1000 ratio in the worst case to return to a normal response time: when
asking to "output this" in a static method, it takes about 30 minutes to
answer that the symbol does not exist (it has probably reviewed all the
existing "this" of the program to see that their are not in scope).

I hope someone will fix that behaviour one day because using C++ is not
so uncommon. Though it is true that under Windows most of C++ developers
are using Visual C++.

Philippe

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
> Date: Fri, 08 Aug 2014 18:05:14 +0200
> From: Philippe <[hidden email]>
>
> I hope someone will fix that behaviour one day because using C++ is not
> so uncommon. Though it is true that under Windows most of C++ developers
> are using Visual C++.

Another thing you could try is the latest version 7.8 of GDB.  If your
applications are 32-bit, you can find a precompiled binary of GDB 7.8
here:

  http://sourceforge.net/projects/ezwinports/files/gdb-7.8-w32-bin.zip/download

Maybe this version fixes your problem; if not, at least you will have
the latest and greatest version of GDB.

HTH

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Hello,

GDB 7.8 fails to start with an error about the DLL python26.dll missing.
And by the way this DLL is nowhere in the downloaded archive nor in the
MinGW 4.8.1 installation.

Philippe

Le 09/08/2014 17:34, Eli Zaretskii a écrit :

> Another thing you could try is the latest version 7.8 of GDB.  If your
> applications are 32-bit, you can find a precompiled binary of GDB 7.8
> here:
>
>    http://sourceforge.net/projects/ezwinports/files/gdb-7.8-w32-bin.zip/download
>
> Maybe this version fixes your problem; if not, at least you will have
> the latest and greatest version of GDB.
>
> HTH
>


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

asmwarrior
On 2014-8-10 15:14, Philippe wrote:
> Hello,
>
> GDB 7.8 fails to start with an error about the DLL python26.dll missing.
> And by the way this DLL is nowhere in the downloaded archive nor in the
> MinGW 4.8.1 installation.
>
> Philippe
I think you need to download  and install the official python 2.6.x distribution from
https://www.python.org/downloads/windows/
The latest 2.6.x version.
Because Eli build GDB with python enabled.

Yuanhui Zhang


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Le 10/08/2014 10:01, asmwarrior a écrit :

> On 2014-8-10 15:14, Philippe wrote:
>> Hello,
>>
>> GDB 7.8 fails to start with an error about the DLL python26.dll missing.
>> And by the way this DLL is nowhere in the downloaded archive nor in the
>> MinGW 4.8.1 installation.
>>
>> Philippe
> I think you need to download  and install the official python 2.6.x distribution from
> https://www.python.org/downloads/windows/
> The latest 2.6.x version.
> Because Eli build GDB with python enabled.
>
> Yuanhui Zhang
>
Thanks.

Now it fails starting with an error which is quite unclear:

Throw without catch before boot:
Throw to key misc-error with args ("primitive-load-path" "Unable to find
file ~S in load path" ("ice-9/boot-9") #f)Aborting.


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
In reply to this post by Philippe
> Date: Sun, 10 Aug 2014 09:14:37 +0200
> From: Philippe <[hidden email]>
>
> GDB 7.8 fails to start with an error about the DLL python26.dll missing.
> And by the way this DLL is nowhere in the downloaded archive nor in the
> MinGW 4.8.1 installation.

>From the file README.txt at the ezwinports site:

  gdb-7.8-w32

    A Windows build of the latest version 7.8 of GDB.  The MinGW site
    offers only an outdated version 7.6.1, which was on top of that
    built without Python support.  Here you have the latest release that
    supports Python.  It also includes the lately added Guile support.
    One caveat: you will have to download and install Python 2.6.6 from
    https://www.python.org/download/releases/2.6.6/; gdb.exe in this
    archive depends on the Python library and DLL, and will not run
    without it being available on your system.  (I don't want to
    distribute Python binaries, because then I would also need to
    provide the Python sources from this site, which is way too much.)
    To take full advantage of the Guile support, you will also have to
    install the guile-X.Y.Z-w32-bin.zip distribution available here;
    without that, GDB will still work, but will warn on startup that
    Guile is only partially supported.

Sorry I didn't mention the README.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
In reply to this post by Philippe
> Date: Sun, 10 Aug 2014 10:42:39 +0200
> From: Philippe <[hidden email]>
>
> Throw without catch before boot:
> Throw to key misc-error with args ("primitive-load-path" "Unable to find
> file ~S in load path" ("ice-9/boot-9") #f)Aborting.

You need to install Guile, as the README says.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Philippe
Le 10/08/2014 16:03, Eli Zaretskii a écrit :
Date: Sun, 10 Aug 2014 10:42:39 +0200
From: Philippe [hidden email]

Throw without catch before boot:
Throw to key misc-error with args ("primitive-load-path" "Unable to find 
file ~S in load path" ("ice-9/boot-9") #f)Aborting.
You need to install Guile, as the README says.

This does not solve the error.
But when installing guile 2.0.11, I had some conflicts between Guile DLLs and GDB DLLs (same name, different dates). I kept the GDB 7.8 DLLs that were more recent. Is the Guile 2.0.11 compatible with GDB 7.8?

------------------------------------------------------------------------------

_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
> Date: Sun, 10 Aug 2014 16:52:21 +0200
> From: Philippe <[hidden email]>
>
> >> Throw without catch before boot:
> >> Throw to key misc-error with args ("primitive-load-path" "Unable to find
> >> file ~S in load path" ("ice-9/boot-9") #f)Aborting.
> > You need to install Guile, as the README says.
> >
> This does *not* solve the error.

Strange.

Did you unzip both GDB and Guile from the same directory?

If so, you should have ice-9/boot-9.scm and ice-9/boot-9.go in the
tree where you unzipped Guile.

If nothing else helps, please try installing both GDB and Guile in
d:\usr.  That's how I configured them, so perhaps some code there
wants to be in the same directory as it was configured for (probably
due to a bug, but that's not your problem to solve).

> But when installing guile 2.0.11, I had some conflicts between Guile
> DLLs and GDB DLLs (same name, different dates). I kept the GDB 7.8 DLLs
> that were more recent. Is the Guile 2.0.11 compatible with GDB 7.8?

All the DLLs in both zip files are identical.  I just looked, and
unless I'm blind, they are indeed identical.  If you see something
else, please tell which DLLs are different.

Sorry for your trouble (it goes without saying that the same binaries
work for me on 3 different systems).

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
> Date: Sun, 10 Aug 2014 18:10:01 +0300
> From: Eli Zaretskii <[hidden email]>
>
> If nothing else helps, please try installing both GDB and Guile in
> d:\usr.  That's how I configured them, so perhaps some code there
> wants to be in the same directory as it was configured for (probably
> due to a bug, but that's not your problem to solve).

OK, confirmed: they both _must_ be installed in d:\usr (i.e., you
should have d:\usr\bin, d:\usr\lib, d:\usr\share, etc. after the
installation).  Of course, add d:\usr\bin to your Path.

This is certainly a bug, and I will look into fixing it, but in the
meantime you should be able to work around it.

Sorry about this.  This is the first time I've built and uploaded a
Guile-capable GDB, so there are some rough edges.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: MinGW 4.8.1 Gdb 7.6 too slow searching for symbols

Eli Zaretskii
> Date: Sun, 10 Aug 2014 18:32:47 +0300
> From: Eli Zaretskii <[hidden email]>
>
> > Date: Sun, 10 Aug 2014 18:10:01 +0300
> > From: Eli Zaretskii <[hidden email]>
> >
> > If nothing else helps, please try installing both GDB and Guile in
> > d:\usr.  That's how I configured them, so perhaps some code there
> > wants to be in the same directory as it was configured for (probably
> > due to a bug, but that's not your problem to solve).
>
> OK, confirmed: they both _must_ be installed in d:\usr (i.e., you
> should have d:\usr\bin, d:\usr\lib, d:\usr\share, etc. after the
> installation).  Of course, add d:\usr\bin to your Path.

Alternatively, define environment variables GUILE_LOAD_PATH and
GUILE_LOAD_COMPILED_PATH to mention the top-level directory where you
have the *s.cm and *.go files, respectively.  Then it should work in
other directories as well.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
12