Remote Debugging

Remote Debugging

[Tim]

I running gdb 5.2-2 and gdbserver.  Remotely I'm running kernel 2.4-19.
I compiled gdbserver against uClibc.  My app is statically compiled
against glibc 6.

My remote device is an x86 board.

My app is compiled with -ggdb and is not stripped on either the remote
or the host.

I start gdbserver 192.168.0.1:2345 myapp -options on the remote device. 
I start gdb on the host and give it the command target remote
192.168.0.2:2345

the remote device shows a connection from my host.

then I give it the command load myapp.

After all this I cannot view any source.  The 'l' command returns the
error 'no symbol table loaded' and instructs me to use file.

What am I doing wrong?

thanx!

Re: Remote Debugging

[Daniel Jacobowitz]

On Thu, Dec 12, 2002 at 09:29:56AM -0800, Tim wrote:
> I running gdb 5.2-2 and gdbserver.  Remotely I'm running kernel 2.4-19.
> I compiled gdbserver against uClibc.  My app is statically compiled
> against glibc 6.
> 
> My remote device is an x86 board.
> 
> My app is compiled with -ggdb and is not stripped on either the remote
> or the host.
> 
> I start gdbserver 192.168.0.1:2345 myapp -options on the remote device. 
> I start gdb on the host and give it the command target remote
> 192.168.0.2:2345
> 
> the remote device shows a connection from my host.
> 
> then I give it the command load myapp.

Try skipping this step.  You should not use load with gdbserver.

> After all this I cannot view any source.  The 'l' command returns the
> error 'no symbol table loaded' and instructs me to use file.
> 
> What am I doing wrong?

Also be sure to give GDB the executable before connecting, i.e. "gdb
myapp".

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Remote debugging

[Russell Shaw]

On 08/03/15 01:09, Ofir Cohen wrote:
> Hi Russel,
> I hope this is what you're looking for.
>
> I see two approaches:
> 1) File system sharing/copying utility
>      Similar to what you suggested, NFS, scp, etc.
>
>      I do remote debugging all the time with gdb and gdbserver, and I have this
>      batch file (both my host and target are Windows OSes) that copies
> my binaries
>      over SMB share.
>
>      If you build your sources frequently, and you're paranoid about
> typing the same commands
>      over and over again, how about adding a post-build command to call
> this script to deploy the files?
>
>
> 2) Transferring files via remote protocol
>       Once you're connected from gdb to gdbserver, you can use the
> following command [1]:
>       remote put <host file> <target file>
>
>       However, this might be an overkill as it will require gdbserver
> [2] to be attached to
>       some dummy process, and will most likely require you to start new
> gdb and gdbserver
>       processes in order to debug the new binary.
>
> I personally consider option #1 as a valid and normal way of
> host2target remote debugging workflow.

Hi,

I put in /home/russell/myprogdir/.gdbinit:

target extended-remote main:1234

cd /home/russell/myprogdir

file myprog
remote put myprog myprog2

break main

run

define hook-run
kill
file myprog
remote put myprog myprog2
end


I was going to do on the laptop (the above test is all in the same directory on 
the same pc):

gdbserver main:1234 myprog2


When testing with gdbserver invoked on the same pc (main) in the same directory 
(/home/russell/myprogdir), "myprog" is truncated to 0 bytes by "remote put 
myprog myprog", so i had to use myprog2 for the copy. I filed a bug for that.

"remote put" should first copy myprog to /tmp/, open the remote myprog for 
writing (which truncates it), then copy from /tmp/. Another way is to note the 
source and dest are the same, and skip the copying.

Re: Remote debugging

[Ofir Cohen]

Hi Russel,
I hope this is what you're looking for.

I see two approaches:
1) File system sharing/copying utility
    Similar to what you suggested, NFS, scp, etc.

    I do remote debugging all the time with gdb and gdbserver, and I have this
    batch file (both my host and target are Windows OSes) that copies
my binaries
    over SMB share.

    If you build your sources frequently, and you're paranoid about
typing the same commands
    over and over again, how about adding a post-build command to call
this script to deploy the files?


2) Transferring files via remote protocol
     Once you're connected from gdb to gdbserver, you can use the
following command [1]:
     remote put <host file> <target file>

     However, this might be an overkill as it will require gdbserver
[2] to be attached to
     some dummy process, and will most likely require you to start new
gdb and gdbserver
     processes in order to debug the new binary.

I personally consider option #1 as a valid and normal way of
host2target remote debugging workflow.

- Ofir


[1] https://sourceware.org/gdb/onlinedocs/gdb/File-Transfer.html
[2] https://ftp.gnu.org/old-gnu/Manuals/gdb-5.1.1/html_node/gdb_130.html

On 7 March 2015 at 15:52, Russell Shaw <rjshaw@netspace.net.au> wrote:
> Hi,
> I'm trying to set up running gdbserver on a laptop and ddd/gdb on a desktop
> pc.
>
> Apart from exporting an NFS directory from the laptop, what other easy way
> is there to get the compiled binary debugee automatically transferred from
> the desktop to the laptop?

Remote debugging

[Russell Shaw]

Hi,
I'm trying to set up running gdbserver on a laptop and ddd/gdb on a desktop pc.

Apart from exporting an NFS directory from the laptop, what other easy way is 
there to get the compiled binary debugee automatically transferred from the 
desktop to the laptop?

Re: Remote debugging

[luca risso]

>On Fri, Mar 19, 2004 at 10:13:40AM +0000, luca risso wrote:
> > Hi,
> >
> > I'm trying to debug an application running on a PPC board with Linux 
>2.4.25.
> >
> > I'm new about this kind of environment so please don't be surprised if 
>my
> > question seems too silly.
> > Using GDBServer I can run the program on the target and set breakpoints 
>to
> > stop a thread.
> > I seems to me that should be possible (I've still not experinced that) 
>also
> > to stop all threads of a process on the same breakpoint.
> >
> > Now, is it possible someway to stop all processes running on the board?
> > It would be useful when debugging processes sending messages to each 
>other.
> > Something similar is available using psos and VxWorks environments where
> > all processes seems to be "freezed" at a time.
>
>No, it's not possible.  GDB can only manage one process at a time.
>
>By the way, every time you stop a thread, GDB arranges for all threads
>in that process to stop.  GDB doesn't currently support any other mode.
>

In this case, for such an embedded appilcation, do you think it could be
reasonable to compile all the application stuff along with the Linux kernel?
Then probably my program would appear as a kernel thread (??) so that it can
be debugged using gdb stubs for kernel debugging.

Do you see any drawback in this approach?
Is there a "standard" or "common" approach for this kind of application?

Thanks a lot. Regards.

        Luca

_________________________________________________________________
Filtri antispamming e antivirus per la tua casella di posta 
http://www.msn.it/msn/hotmail

Re: Remote debugging

[Daniel Jacobowitz]

On Fri, Mar 19, 2004 at 10:13:40AM +0000, luca risso wrote:
> Hi,
> 
> I'm trying to debug an application running on a PPC board with Linux 2.4.25.
> 
> I'm new about this kind of environment so please don't be surprised if my 
> question seems too silly.
> Using GDBServer I can run the program on the target and set breakpoints to 
> stop a thread.
> I seems to me that should be possible (I've still not experinced that) also 
> to stop all threads of a process on the same breakpoint.
> 
> Now, is it possible someway to stop all processes running on the board?
> It would be useful when debugging processes sending messages to each other.
> Something similar is available using psos and VxWorks environments where 
> all processes seems to be "freezed" at a time.

No, it's not possible.  GDB can only manage one process at a time.

By the way, every time you stop a thread, GDB arranges for all threads
in that process to stop.  GDB doesn't currently support any other mode.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Remote debugging

[luca risso]

Hi,

I'm trying to debug an application running on a PPC board with Linux 2.4.25.

I'm new about this kind of environment so please don't be surprised if my 
question seems too silly.
Using GDBServer I can run the program on the target and set breakpoints to 
stop a thread.
I seems to me that should be possible (I've still not experinced that) also 
to stop all threads of a process on the same breakpoint.

Now, is it possible someway to stop all processes running on the board?
It would be useful when debugging processes sending messages to each other.
Something similar is available using psos and VxWorks environments where all 
processes seems to be "freezed" at a time.

May it be useful to compile all my stuff  along with Linux and then use gdb 
stubs normaly adopted for kernel debugging?

Thanks for your help

         Luca

_________________________________________________________________
Get reliable access on MSN 9 Dial-up. 3 months for the price of 1! 
(Limited-time offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

RE: remote debugging

[nak26]

>>  gdb> load
>
>You should not do that, gdbserver already loaded the program.
>The rest of your problems may be related to this step.
>

What works for me is
1.) gdb> file executable_name

--That, of course, works if you built the executable locally, and also have 
access --to the code

2.) gdb> break break_point_somewhere

3.) gdb> continue

--Don't do run, since gdbserver has already fired the process (on the remote 
--machine).

--Nik

Re: remote debugging

[Quality Quorum]

On Fri, 13 Jun 2003, Brijesh Shukla wrote:

> Hello,
>
> Can any body explain the remote debugging application in Linux.
> currently for testing purpose as simple case, I have chosen two i686
> Pentium machines with Linux
> installed on two systems. on system I am running gdb and in another
> system I am running gdb server. I did the following steps.
>
> Target:
>  gdbserver host:port program
>
>  //Now gdbserver has been started
>
> Host:
>
>  // I compiled the simple hello word program as    gcc -g program.c -o
> program
>  // copied the program into target system
>
>  gdb program
>  gdb> target remote host:port
>  gdb>
>
>  // connection established
>  gdb> load

You should not do that, gdbserver already loaded the program.
The rest of your problems may be related to this step.

>
>  // it is showing loading the sections, I m not sure the addresses from
> local machine or from target machine ( how can I verify ? in our
> case,sicne both machine
>  are same architecture and same OS)
>
>  I can set break point to main.
>
>  if I do step or next, I am getting the error message "cannot find
> bounds of current function"
>
>  if I do continue, I am getting the error message " program received
> SIGSEGV, segmentation fault"
>
> can anybody tell me where is the wrong ?
>
> Is there anything's need to be take care while building the gdb in one
> machine. ?  currently I am using the default gdb installed in machine
> due to both machine are same architecture.
>
> Regards
> Brijesh Shukla
>

Thanks,

Aleksey

remote debugging

[Brijesh Shukla]

Hello,
 
Can any body explain the remote debugging application in Linux. 
currently for testing purpose as simple case, I have chosen two i686 
Pentium machines with Linux
installed on two systems. on system I am running gdb and in another 
system I am running gdb server. I did the following steps.
 
Target:
 gdbserver host:port program
 
 //Now gdbserver has been started
 
Host:
 
 // I compiled the simple hello word program as    gcc -g program.c -o 
program
 // copied the program into target system
 
 gdb program
 gdb> target remote host:port
 gdb>
 
 // connection established
 gdb> load
 
 // it is showing loading the sections, I m not sure the addresses from 
local machine or from target machine ( how can I verify ? in our 
case,sicne both machine
 are same architecture and same OS)
 
 I can set break point to main.
 
 if I do step or next, I am getting the error message "cannot find 
bounds of current function"
 
 if I do continue, I am getting the error message " program received 
SIGSEGV, segmentation fault"
 
can anybody tell me where is the wrong ?
 
Is there anything's need to be take care while building the gdb in one 
machine. ?  currently I am using the default gdb installed in machine 
due to both machine are same architecture.
 
Regards
Brijesh Shukla

remote debugging

[Patricia Alba]

hi !
i'm using gdb to debug an application on a remote
target (hitachi 16-bit microcontroller). i downloaded
the gdb stub for a different version and ported it to
work on the board i'm using. i'm able to connect, but
the gdb is unstable. it generates a sigtrap exception
for even normal termination of the program. the values
of local variables are also not working correctly.
any pointers on how to go about debugging the
debugger??

Patricia

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

remote debugging

[Vinayak P Risbud]

        Hi,
            I am trying to use remote debugging using LAN (Tcp/Ip) on
Redboot
            What I understood till now is,
                    1.  the main polls net_io_test function during idle
time
                    2.  The function net_io_test checks for
                                        tcp_sock.state == _ESTABLISHED
                    3.   If established, the control calls
net_io_assume_console
                         to setup debug channel.

                But,  after this, how the flow goes,  I am not able to
trace.
                my gdb client on remote PC sends $Hc-1#09 command,
                over tcp/ip link.
                I am not able to trace, where and how exactly this gdb
                command is read and processed (i.e trap is generated ?)

                Can any one help in tracing the flow ?

            Thanks in advance
                Vinayak

remote debugging

[malar kavi]

Hi,
    tell me something in detail about the stubs used
in
remote debugging with gdb

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/
From fnasser@redhat.com Wed Jan 24 06:16:00 2001
From: Fernando Nasser <fnasser@redhat.com>
To: malar kavi <malarkavi@yahoo.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote debugging
Date: Wed, 24 Jan 2001 06:16:00 -0000
Message-id: <3A6EE34E.579C1563@redhat.com>
References: <20010124062335.4822.qmail@web5504.mail.yahoo.com>
X-SW-Source: 2001-01/msg00167.html
Content-length: 286

malar kavi wrote:
> 
> Hi,
>     tell me something in detail about the stubs used
> in
> remote debugging with gdb
> 

It is in the manual.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From jtc@redback.com Wed Jan 24 10:52:00 2001
From: jtc@redback.com (J.T. Conklin)
To: malar kavi <malarkavi@yahoo.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote debugging
Date: Wed, 24 Jan 2001 10:52:00 -0000
Message-id: <5mvgr4srz5.fsf@jtc.redback.com>
References: <20010124062335.4822.qmail@web5504.mail.yahoo.com>
X-SW-Source: 2001-01/msg00168.html
Content-length: 473

>>>>> "malar" == malar kavi <malarkavi@yahoo.com> writes:
malar> Hi, tell me something in detail about the stubs used in remote
malar> debugging with gdb

As Fernando mentioned, how to integrate/use the sample stubs is
described in the manual.  If after reading that section you still have
specific questions, don't hesitate to ask them.  We'll do our best to
answer them, as well as improve the manual to make it clearer.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From friedrich.beckmann@gmx.de Wed Jan 24 13:39:00 2001
From: Friedrich Beckmann <friedrich.beckmann@gmx.de>
To: gdb@sources.redhat.com
Subject: JTAG debug support for ARM
Date: Wed, 24 Jan 2001 13:39:00 -0000
Message-id: <3A6F4BFD.8EEC6FF6@gmx.de>
X-SW-Source: 2001-01/msg00169.html
Content-length: 1560

Hi,

i have found a site http://www.ocdemon.com which offers the gnu
toolchain with support for wiggler/raven JTAG interfaces.  I have not
tested this and would like to know if anybody has some experience with
this. The sources for the Wiggler drivers are not included in the
distribution.
Is there any person related to this site? I cannot find any name on the
sites pages.
Is there something illegal behind this?

As far as I have figured it out, the standard gdb release supports the
ARM RDI interface. This requires the ANGEL software installed
(and is then connected via a serial interface).

Optionally the OLD EmbeddedICE Box which can interpret the RDI commands
to JTAG
commands can be used. The new MultiICE debug box from ARM requires
software support on the host which is not available for linux at the
moment.

There is a configure option --multi-ice in the gdb release which
lets me assume that the commercial GnuPRO tools from Redhat
have support for the MultiICE. The multi-ice-gdbserver seems not to
be under GNU license.

The JEENI JTAG interface from http://www.episupport.com seems understand
the RDI commands
directly as the ARM EmbeddedICE does. So this is also usabled via the
gdi rdi interface.

http://www.abatron.ch also offers a JTAG interface but with a dedicated
gdb driver
software for linux. gdb.

Is anybody using the wiggler with gdb for the ARM7?

Which software are you using?

Is anybody out there who is putting effort in writing a GNU-licensed
remote interface
for a low-cost JTAG interface like the wiggler?

Friedrich

Re: Remote Debugging

[Fernando Nasser]

Yu Xuanwei wrote:
> 
> Hi, Folks:
> 
> I am a rookie. I want to know something about remote debugging:
> 
> 1. On target: The gdbserver manipulates target application, which is
> stripped.
> 
> 2. On host: GDB run "target remote ..." to customize the target.
> 
> Then where is the symbol file for target application? Should I native
> compile the target application on host? Or ...?
> 

Nope.  You cross compile your executable with "-g".  Create a stripped copy 
(not necessary if you don't care about file sizes in the target) and copy
the stripped version to the target.  Load it with gdbserver.

On the host side:  gdb <your-complete-executable-with-debug-info>
and proceed as you mentioned.

But please, before you try to go any further, print a copy of the 
"Debugging with GDB" manual.  It is in the doc directory (you can make it in
various flavors - ps among them).  It is also available as an info topic 
if GDB is correctly installed on your system.

 

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From Denset.Serralta@radisys.com Fri Dec 01 11:55:00 2000
From: Denset.Serralta@radisys.com
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: GDB does not step into or over "sleep" function
Date: Fri, 01 Dec 2000 11:55:00 -0000
Message-id: <OF9A6588DE.02D8BDD2-ON852569A8.006B6937@radisys.com>
X-SW-Source: 2000-12/msg00004.html
Content-length: 3359

                                                                                                                        
                    Jim Blandy                                                                                          
                    <jimb@zwingli.cygn        To:     Denset.Serralta@radisys.com                                       
                    us.com>                   cc:     gdb@sources.redhat.com                                            
                    Sent by:                  Subject:     Re: GDB does not step into or over "sleep" function          
                    gdb-owner@sources.                                                                                  
                    redhat.com                                                                                          
                                                                                                                        
                                                                                                                        
                    11/28/00 08:07 PM                                                                                   
                                                                                                                        
                                                                                                                        






Jim Blandy wrote:
>Let me make sure I understand.  If you have code like this:
>
>    ... some code ...
>    ProcessSleep (...);
>    ... some more code ...
>
>and you set a breakpoint on the `some more code' line, your program
>hangs and never reaches the breakpoint.

>But if you run the program without GDB, it sleeps the expected amount
>of time, and then continues normally.


Thanks for responding

You are correct. The breakpoint in  "...some more code ..." is never
reached. We are suspecting
at the moment that it is a problem with the ProcessSleep function since the
hang occurrs when we
'step into' or 'step over' it. What we don't know is whether it is a
problem with our underlying kernel
functions or whether GDB has a problem with a "sleep" function which
allocates a semaphore,
blocks on it subject to a user specified timeout and then returns the
semaphore. We are leaning
to suspecting that it is a problem with our custom kernel (i.e. GDB is
innocent). However I thought
I would ask the GDB group, with all the combined experience developing GDB,
just in case they
saw something obvious.

Thanks again
Denset.Serralta@radisys.com


>Denset.Serralta@radisys.com writes:
>> We are using GDB 4.18 on an NT host to debug target software running on
a
>> PowerPC based adapter. We are using a function called ProcessSleep which
is
>> a call to our kernel.  It basically allocates a semaphore, blocks on it
>> subject to a user specified timeout and then returns the semaphore.One
>> problem we can't seem to get around though is that if the process being
>> debugged makes a 'ProcessSleep' call, the debugger never gains control
when
>> we step over it.  Even if we set a breakpoint past the call and let it
run,
>> it never returns.  A status utility that we have shows the process as
>> queued, but we never regain control.  Does anybody know any reason(s)
why
>> this should happen.

Re: Remote Debugging

[Andrew Cagney]

Timo Ketola wrote:
> 
> Hi all,
> 
> I just subscribed to this list...
> 
> I'm adapting the gdb and the remote stub for our embedded system.
> Debugging works already over a RS232 line but I have a couple of
> questions for which I can't find an answer:
> 
> 1) I want to be able to debug also over a CAN network. I think I have to
> write a new interface for the gdb. Namely the getpkt and putpkt of the
> remote.c should be reimplemented. But what is a clean way? Could someone
> assist me a bit.

A alternative might be to modify gdbserver (or the like) and use GDB's
remote protocol (target extended-remote).  (I'm not sure what a CAN
network is).

> 2) When I 'load' a new executable into the target the loading works well
> but the symbols are not loaded. At the end of generic_load function
> comment asks whether symbol_file_add function should be called. Is that
> exactly the right thing to do?

Are you loading different files or the same file?

	(gdb) file  foo.out
	(gdb) target .....
	(gdb) load

both loads the file and updates the symbols.  There are also commands
for loading symbols from a specific file.

> 3) How do I get a clean information about the load of the new executable
> in the stub? Before a new executable is started (or an old one
> restarted) the stub needs to do a couple of things (for example clean up
> the stack).

I've seen this done two ways:

	o	the embedded equivalent of crt0.o
		initialises the stack (and zero's
		bss)

	o	*_create_inferior() performs
		the initialize operation.
		(see remote-sim.c)

enjoy,
	Andrew
From kevinb@cygnus.com Thu Feb 24 01:52:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 01:52:00 -0000
Message-id: <1000224095244.ZM13976@ocotillo.lan>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <Franz.Sirl-kernel@lauterbach.com>
X-SW-Source: 2000-02/msg00001.html
Content-length: 890

On Feb 22, 11:09pm, Franz Sirl wrote:

> >I invite those of you who have Linux/PPC machines to try out these
> >changes and let me know how they work.  Also, please let me know about
> >any problems that you find.
> 
> I've just uploaded an RPM with the current CVS source to
> ftp://devel.linuxppc.org/users/fsirl/ so people can easily test it.

Thanks.

[...]
> A quick test of gdb looked very promising, I already installed it as the
> default gdb on our build system. What about "info float"? Are you going to
> tackle this yourself later or do you want to leave the implementation to
> somebody else?

If someone else is willing to do the implementation for "info float",
I'm willing to integrate the patches.  (I rarely have need for "info
float", so it may be better if someone else did the implementation.)
OTOH, if no one sends me patches, I'll try to get to it eventually.

Kevin
From kevinb@cygnus.com Thu Feb 24 02:12:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: khendricks@ivey.uwo.ca
Cc: gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 02:12:00 -0000
Message-id: <1000224101226.ZM14012@ocotillo.lan>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <00022221542500.09439@localhost.localdomain> <khendricks@ivey.uwo.ca>
X-SW-Source: 2000-02/msg00002.html
Content-length: 1901

On Feb 22,  9:49pm, Kevin Hendricks wrote:

> Here is my first bug report.  This is with gdb from today's cvs
> (after your later commit) debugging a problem with Motif Drag-n-Drop
> in the jdk under native threads.
>
> Everything was working fine until I decided to rerun the program
> from within gdb without removing my shared library breakpoints
> first.

Does it work if you disable your shared library breakpoints first?

> Here is the resulting log file.  Notice the non-existent breakpoint
> 0 and also even through I manually removed all of my breakpoints and
> tried to continue I could not do so.
> 
> I hope this info helps.  The only simple test case would be to
> actually run the DDTest java program under the jdk with Motif source
> around.
> 
> Let me know if you would like more info about this bug (explicit
> steps to try) and I would be happy to follow instructions.

I've seen this problem before on other platforms.  It would really be
nice to have a relatively small test case to debug this problem with. 
Do you think you could whittle the problem down to something that you
could send us the source to?  

It'd also be nice to incorporate such a test into the test suite.  If
you can provide me with a C program which exhibits the problem, I'll
work on the expect script to incorporate it into the test suite.  (I'll
also work on tracking down the bug and fixing it.)  Remember that we'll
need copyright assignments for anything that winds up in the test suite.

You may (or may not) find it useful to start with the shared library
tests already in the test suite.  Take a look in gdb/testsuite/gdb.base
at the files shmain.c, shr1.c, and shr2.c.

BTW, I just fixed one of the bugs (there were actually two separate bugs)
which was causing one of the shared library tests to fail.  I'll commit
this fix later on today, but I doubt it will solve your problem.

Thanks,

Kevin
From Franz.Sirl-kernel@lauterbach.com Thu Feb 24 02:22:00 2000
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 02:22:00 -0000
Message-id: <4.2.2.20000224111642.04d2f430@mail.lauterbach.com>
References: <Franz.Sirl-kernel@lauterbach.com> <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> <1000224095244.ZM13976@ocotillo.lan>
X-SW-Source: 2000-02/msg00003.html
Content-length: 728

At 10:52 24.02.00 , Kevin Buettner wrote:
> > A quick test of gdb looked very promising, I already installed it as the
> > default gdb on our build system. What about "info float"? Are you going to
> > tackle this yourself later or do you want to leave the implementation to
> > somebody else?
>
>If someone else is willing to do the implementation for "info float",
>I'm willing to integrate the patches.  (I rarely have need for "info
>float", so it may be better if someone else did the implementation.)
>OTOH, if no one sends me patches, I'll try to get to it eventually.

Ok, I just wanted to clear the status of "info float", I'll take a look at 
it too and maybe I should already think about "info vector" :-)).

Franz.