This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: async operation


Newman, Mark (N-Superior Technical Resource Inc) writes:
 > IMHO async is not an invention of the client but the manner in which gdb
 > controls the client. ;-)
 > 
 > I am attaching a gdb output with remote_debug set.  In this instance the
 > sequence
 > 
 > > interrupt
 > > cont &
 > 
 > worked once but did not work the second time.

[...]
 > 
 > It may be my changes that are causing the problem.
 
Can you try on a gdb w/o your modifications?


 > 
 > Program received signal SIGINT, Interrupt.
 > Sending packet: $M4000acb0,1:55#68...Ack
 > Packet received: ENN
 > Sending packet: $M4000acb0,1:55#68...Ack
 > Packet received: ENN
 > Sending packet: $mbffff830,4#62...Ack
 > Packet received: 55320000
 > Sending packet: $mbffff834,4#66...Ack
 > Packet received: 55320000
 > 0x080483f7 in main (argc=12885, argv=0x3255) at main.c:52
 > 52      while (j < 1000000) {

I assume you said continue here?

 > 
 > Sending packet: $c#63...Ack
 > 
 > remote_stop called

Hmm do you see any output that says that remote_interrupt has been
called as well? I wonder if the signal handlers are screwed up.

 > 
 > Sending packet: $c#63...Packet instead of Ack, ignoring it

gdb keeps issuing the continue command for some reason. maybe it
hasn't realized that the target is actually running. 

elena


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]