headers
Joel Brobecker | 1 May 2006 19:05
Favicon

MinGW gdb run in non-DOS terminal

Hello,

Starting to experiment a bit with MinGW-hosted debuggers, I noticed that
when it is run outside of the DOS window, the terminal handling is a bit
strange. The most obvious issue is when the debugger prints an error:
the actual printing on screen of the error message is delayed and only
finally printed after the next GDB prompt.

This happens when in a DOS window running cygwin bash, when ssh'ing
from an xterm to the machine and then running GDB, or when running
GDB from GPS, which opens a pseudo-tty (I think!) to GDB. On the other
hand, it works great when run in a DOS window.

Has anybody else seen this? Maybe there is a missing-flush issue
somewhere... Or maybe there is a workaround I don't know about?
Otherwise, I'll have a look at this next.

Thanks,
--

-- 
Joel
Permalink | Reply | 4 comments |
headers
Daniel Jacobowitz | 1 May 2006 19:11

Re: MinGW gdb run in non-DOS terminal

On Mon, May 01, 2006 at 10:05:12AM -0700, Joel Brobecker wrote:
> Hello,
> 
> Starting to experiment a bit with MinGW-hosted debuggers, I noticed that
> when it is run outside of the DOS window, the terminal handling is a bit
> strange. The most obvious issue is when the debugger prints an error:
> the actual printing on screen of the error message is delayed and only
> finally printed after the next GDB prompt.
> 
> This happens when in a DOS window running cygwin bash, when ssh'ing
> from an xterm to the machine and then running GDB, or when running
> GDB from GPS, which opens a pseudo-tty (I think!) to GDB. On the other
> hand, it works great when run in a DOS window.
> 
> Has anybody else seen this? Maybe there is a missing-flush issue
> somewhere... Or maybe there is a workaround I don't know about?
> Otherwise, I'll have a look at this next.

It is roughly unsolvable.  A cygwin "terminal" is in fact a Windows
pipe; isatty() returns false, therefore the C library selects
line-buffered mode, which is a pretty standard thing for C runtimes
to do.

I suppose that if the CLI is in use, you could automatically turn off
buffering.  But there may be plenty of other problems... I talked with
Chris about somehow using Windows consoles for this instead of pipes
(i.e. changing Cygwin), and I believe the outcome of that discussion
was that it might be possible, or might not, but would definitely not
be easy.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joel Brobecker | 1 May 2006 19:22
Favicon

Re: MinGW gdb run in non-DOS terminal

> It is roughly unsolvable.  A cygwin "terminal" is in fact a Windows
> pipe; isatty() returns false, therefore the C library selects
> line-buffered mode, which is a pretty standard thing for C runtimes
> to do.

:-(. In fact, I see the same in GPS where cygwin is nowhere in sight.

> I suppose that if the CLI is in use, you could automatically turn off
> buffering.  But there may be plenty of other problems...

Maybe we should start with that. Would you mind pointing me in the
area where this should be done? I can experiment with that and see
if we have any other obvious problems.

--

-- 
Joel
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 May 2006 19:30

Re: MinGW gdb run in non-DOS terminal

On Mon, May 01, 2006 at 10:22:16AM -0700, Joel Brobecker wrote:
> > It is roughly unsolvable.  A cygwin "terminal" is in fact a Windows
> > pipe; isatty() returns false, therefore the C library selects
> > line-buffered mode, which is a pretty standard thing for C runtimes
> > to do.
> 
> :-(. In fact, I see the same in GPS where cygwin is nowhere in sight.

What's it connected to then?  A pipe or a console?

> > I suppose that if the CLI is in use, you could automatically turn off
> > buffering.  But there may be plenty of other problems...
> 
> Maybe we should start with that. Would you mind pointing me in the
> area where this should be done? I can experiment with that and see
> if we have any other obvious problems.

Just use setvbuf, I presume the Microsoft runtime has that.

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 May 2006 20:17
Favicon

Re: MinGW gdb run in non-DOS terminal

> What's it connected to then?  A pipe or a console?

I am not very familiar with this part of GPS, but I had a look and
it seems to me that they are using pipes.

> Just use setvbuf, I presume the Microsoft runtime has that.

It does, and in fact, provides a significant improvement in the
ordering of the output, and our testsuite didn't detect any
complications from this. I just have a prototype right now, but
would this be interesting to others?

--

-- 
Joel
Permalink | Reply | 0 comments |
headers
Doug Abbott | 2 May 2006 06:15
Picon

Remote gdb and shared libraries

Hi,

This should be a fairly simple problem of inadequate documentation.  
I've searched the archives and found quite a bit of stuff on shared 
libraries, but nothing that exactly matches the problem I'm seeing.

I'm running gdb 6.3 under Red Hat 9 using gdbserver on an ARM9 target 
board to debug a simple Hello World program.  I've worked through the 
stuff about setting solib-absolute-prefix and both the host and target 
copies of the libraries seem to be identical.

The first suspicious thing that happens is when gdb connects to the 
target, it returns:

    0x40001470 in ?? ()

implying to me that it can't find the name of the function at that 
particular address.  After the program starts and halts at a breakpoint, 
the info share command returns:

    From               To                  Syms Read       Shared Object
    Library
    0x40035cd0     0x401162cc  No                 
    /usr/local/arm/arm-linux/lib/libc.so.6
    0x40001470     0x40011598  No                
    /usr/local/arm/arm-linux/lib/ld-linux.so.2

Hmmm.  The most suspicious aspect of this is the Syms Read column that 
says "No".  Why didn't it read the symbols?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Jacobowitz | 2 May 2006 06:19

Re: Remote gdb and shared libraries

On Mon, May 01, 2006 at 10:15:39PM -0600, Doug Abbott wrote:
> The first suspicious thing that happens is when gdb connects to the 
> target, it returns:
> 
>    0x40001470 in ?? ()
> 
> implying to me that it can't find the name of the function at that 
> particular address.

You're in the dynamic loader but GDB doesn't yet know where the dynamic
loader has been loaded.  This is typical.

>    From               To                  Syms Read       Shared Object
>    Library
>    0x40035cd0     0x401162cc  No                 
>    /usr/local/arm/arm-linux/lib/libc.so.6
>    0x40001470     0x40011598  No                
>    /usr/local/arm/arm-linux/lib/ld-linux.so.2
> 
> Hmmm.  The most suspicious aspect of this is the Syms Read column that 
> says "No".  Why didn't it read the symbols?

Because it couldn't find them.  You have to tell it where they are.
Have you used set solib-absolute-prefix?  If not, try that.  Do your
libraries precisely match the target's?

> With each next command, gdb says "Cannot access memory at address 0x0".  
> When I try to step over a call to printf() (with next), it says  
> "0x000082cc in ?? ()".  Executing next again returns "Cannot find bounds 
> of current function".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vladimir Prus | 2 May 2006 14:49
Picon
Favicon

Re: -var-update and address changes

On Friday 14 April 2006 23:49, Jim Ingham wrote:

> Note as an aside, that we had to add another varobj type which is
> evaluated in the selected frame, whatever that happens to be.  That
> was useful for a general "variable inspector" window.  People wanted
> to put some expression there, and have it re-evaluated in the topmost
> frame whenever they stopped.  So we added that functionality.  But
> that is clearly distinct from what the "*" varobj type is supposed to
> mean.

Hi Jim,
is this "variable inspector" the same thing that's called "watches" in other 
IDEs? Well, I really wish that gdb did support variable objects that are 
reevaluated in the current frame. As it stands now, I have to re-create 
variable objects on each step.

Alternatively, it might be good if gdb provided some way to identify specific 
scope. Then, "watches" can be bound to that scope and be automatically 
disabled when out of scope.

In other words, suppose that while inside some function I'm interested in 
value of "i + 10". Then, there are two choices:

  - Somehow record the scope where I'm interested in that expression,
    and show expression as disabled elsewhere.
  - Try to recompute the expression on each stop.

While the second approach at least guarantees that the expression will be 
re-evaluated each time I enter the "interesting" scope, it also involves a 
bit of extra work for re-evaluating it in other "uninteresting" scopes.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Nick Roberts | 2 May 2006 15:14
Picon

Re: -var-update and address changes

Vladimir Prus writes:
 > On Friday 14 April 2006 23:49, Jim Ingham wrote:
 > 
 > > Note as an aside, that we had to add another varobj type which is
 > > evaluated in the selected frame, whatever that happens to be.  That
 > > was useful for a general "variable inspector" window.  People wanted
 > > to put some expression there, and have it re-evaluated in the topmost
 > > frame whenever they stopped.  So we added that functionality.  But
 > > that is clearly distinct from what the "*" varobj type is supposed to
 > > mean.
 > 
 > Hi Jim,
 > is this "variable inspector" the same thing that's called "watches" in other 
 > IDEs? Well, I really wish that gdb did support variable objects that are 
 > reevaluated in the current frame. As it stands now, I have to re-create 
 > variable objects on each step.

Assuming some ambiguity with current/selected, have you tried (not documented):

"-var-create -  <at>  NAME" 

which behaves a bit differently to "-var-create - * NAME".

--

-- 
Nick                                           http://www.inet.net.nz/~nickrob
Permalink | Reply | 8 comments |
headers
Vladimir Prus | 2 May 2006 15:40
Picon
Favicon

Re: -var-update and address changes

On Tuesday 02 May 2006 17:14, Nick Roberts wrote:
> Vladimir Prus writes:
>  > On Friday 14 April 2006 23:49, Jim Ingham wrote:
>  > > Note as an aside, that we had to add another varobj type which is
>  > > evaluated in the selected frame, whatever that happens to be.  That
>  > > was useful for a general "variable inspector" window.  People wanted
>  > > to put some expression there, and have it re-evaluated in the topmost
>  > > frame whenever they stopped.  So we added that functionality.  But
>  > > that is clearly distinct from what the "*" varobj type is supposed to
>  > > mean.
>  >
>  > Hi Jim,
>  > is this "variable inspector" the same thing that's called "watches" in
>  > other IDEs? Well, I really wish that gdb did support variable objects
>  > that are reevaluated in the current frame. As it stands now, I have to
>  > re-create variable objects on each step.
>
> Assuming some ambiguity with current/selected, have you tried (not
> documented):
>
> "-var-create -  <at>  NAME"
>
> which behaves a bit differently to "-var-create - * NAME".

Wow, that's exactly what I'm looking for. Except that it's buggy :-(
When I have code like this:

  int foo()
  {
      long i = 15;
(Continue reading)

Permalink | Reply | 7 comments |

Gmane