gdb-7.1 - last call before release (Wed, Mar 17th)

gdb-7.1 - last call before release (Wed, Mar 17th)

[Joel Brobecker]

Hello,

As far as I know, we don't have any known blocking issue on the gdb-7.1
branch, so I'm planning on creating the release tomorrow morning,
Pacific time.

Please let me know if there is anything that you think should be included
before we release.

-- 
Joel

Re: gdb-7.1 - last call before release (Wed, Mar 17th)

[Asm_gmail]

On 2010-3-17 0:11, Joel Brobecker wrote:
> Hello,
>
> As far as I know, we don't have any known blocking issue on the gdb-7.1
> branch, so I'm planning on creating the release tomorrow morning,
> Pacific time.
>
> Please let me know if there is anything that you think should be included
> before we release.
>
>    
Thanks, and I have built the GNU gdb (GDB) 7.0.90.20100316 version of 
gdb in Windows XP, MinGW.
It works quite well under Codeblocks IDE.
But it seems the command interpreter is still a little slower than the 
7.0.1 version. As I have reported this issue in this maillist before.
Sorry I can't compile it with -pg option. see here:
http://sourceware.org/ml/gdb/2010-03/msg00029.html

regards
asmwarrior

Re: gdb-7.1 - last call before release (Wed, Mar 17th)

[Joel Brobecker]

> But it seems the command interpreter is still a little slower than
> the 7.0.1 version. As I have reported this issue in this maillist
> before.
> Sorry I can't compile it with -pg option. see here:
> http://sourceware.org/ml/gdb/2010-03/msg00029.html

I don't think that this is a blocking issue, but I would possibly
consider delaying the release while someone investigates.  However,
someone has to step up... Otherwise, I am afraid that we're just going
to delay the release without a clear idea of how long the delay might be.

I'm not going to start the process until later this afternoon (Pacific
time). If someone steps up, then great, we can delay for a day or two
to see what he finds.  Otherwise, there's always going to be 7.1.1 or
7.2...

-- 
Joel

Re: gdb-7.1 - last call before release (Wed, Mar 17th)

[Asm_gmail]

On 2010-3-17 22:12, Joel Brobecker wrote:
>> But it seems the command interpreter is still a little slower than
>> the 7.0.1 version. As I have reported this issue in this maillist
>> before.
>> Sorry I can't compile it with -pg option. see here:
>> http://sourceware.org/ml/gdb/2010-03/msg00029.html
>>      
> I don't think that this is a blocking issue, but I would possibly
> consider delaying the release while someone investigates.  However,
> someone has to step up... Otherwise, I am afraid that we're just going
> to delay the release without a clear idea of how long the delay might be.
>
> I'm not going to start the process until later this afternoon (Pacific
> time). If someone steps up, then great, we can delay for a day or two
> to see what he finds.  Otherwise, there's always going to be 7.1.1 or
> 7.2...
>
>    
Hi, Joel
Today, I found that you have released the official 7.1 version. So I 
download it and build it again( MinGW32). I used it in Codeblocks, and 
it works fine.

But the only issue is:

It seems When I'm debugging a dll (it is a Codeblocks' plugin), then I 
put some watch variables in the watch window. Then I step in the source 
code, it seems that when the variables were in the current frame, it 
return the value very fast, like:

F:\cb_svn\src\plugins\codecompletion\parser\tokenizer.cpp:644:18273:beg:0x65ed34a3
 >>>>>>cb_gdb:
 > whatis m_LineNumber
type = unsigned int
 >>>>>>cb_gdb:
 > output m_LineNumber
1>>>>>>cb_gdb:
 > whatis m_TokenIndex
type = unsigned int
 >>>>>>cb_gdb:
 > output m_TokenIndex
0>>>>>>cb_gdb:

But when the variables was out of the current frame, see the debug log:
F:\cb_svn\src\plugins\codecompletion\parser\parserthread.cpp:448:14091:beg:0x65ec27c6
 >>>>>>cb_gdb:
 > whatis m_LineNumber
No symbol "m_LineNumber" in current context.
 >>>>>>cb_gdb:
 > output m_LineNumber
No symbol "m_LineNumber" in current context.
 >>>>>>cb_gdb:
 > whatis m_TokenIndex
No symbol "m_TokenIndex" in current context.
 >>>>>>cb_gdb:
 > output m_TokenIndex
No symbol "m_TokenIndex" in current context.
 >>>>>>cb_gdb:

At this time, the command interpreter runs really slow.

As I have said that output a wxString value is quite slow, today, I 
think this is another lag problem, not only the wxString ,but also a 
build-in type variable.

Thanks.

asmwarrior (ollydbg from codeblocks forum).

Re: gdb-7.1 - last call before release (Wed, Mar 17th)

[Joel Brobecker]

I'm not familiar with C++ debugging, so there is not much I can do
in this case to help. The fact that it returns very quickly when
the variable is in scope seems logical - I would imagine that symbol
lookups by name search the current scope first, before expanding
the search to the global scope. As for the search in the global scope,
it's hard to say...  Perhaps if you create a PR and provide a reproducer,
someone will be able to find out more.

-- 
Joel

Re: gdb-7.1 - last call before release (Wed, Mar 17th)

[Asm_gmail]

On 2010-3-19 23:06, Joel Brobecker wrote:
> I'm not familiar with C++ debugging, so there is not much I can do
> in this case to help. The fact that it returns very quickly when
> the variable is in scope seems logical - I would imagine that symbol
> lookups by name search the current scope first, before expanding
> the search to the global scope. As for the search in the global scope,
> it's hard to say...  Perhaps if you create a PR and provide a reproducer,
> someone will be able to find out more.
>
>    

Hi, all. As Chris supplied a profile enabled version of gdb in :
http://emergedesktop.org/gdb/gdb-7.1-profiling.tar.lzma

So, I have upload a profile result file to my bug report in :
http://sourceware.org/bugzilla/show_bug.cgi?id=11316

I hope it can help the gdb developers to find the real cause of this 
time lab.

Thanks
Asmwarrior

Re: gdb-7.1 - last call before release (Wed, Mar 17th)

[Ulrich Weigand]

Joel Brobecker wrote:

> As far as I know, we don't have any known blocking issue on the gdb-7.1
> branch, so I'm planning on creating the release tomorrow morning,
> Pacific time.

I've tested the current branch on S/390 (31-bit and 64-bit), PowerPC
(32-bit and 64-bit), and Cell/B.E. (SPU stand-alone, and combined
debugging), in all cases both native and via gdbserver.

Everything looks good to me.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com