This is the mail archive of the archer@sourceware.org mailing list for the Archer 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]

gdbstub initial code, v5


On 08/19, Oleg Nesterov wrote:
>
> Next step: handle exit correctly and report W/S. I misunderstood
> what gdbserver does when the main thread exits, it is not stupid
> as I wrongly thought.

Yes, in non-stop mode gdbserver reports W/X;process:PID when the
last thread exits. This makes sense, so does ugdb.

But,

==================================================================
All, please ack/nack the behavioral difference!

When the main thread exits, gdbserver still exposes it to gdb as
a running process. It is visible via "info threads", you can switch
to this thread, $Tp or $Hx result in "OK" as if this thread is alive.
gdbserver even pretends that $vCont;x:DEAD_THEAD works, although
this thread obviously can never report something.

I don't think this is really right. This just confuses the user, and
imho this should be considered like the minor bug.

ugdb doesn't do this. If the main thread exits - it exits like any
other thread. I played with gdb, it seems to handle this case fine.

==================================================================

Problems:

	- I forgot to implement the attach to the thread group
	  with the dead leader. Next time.

	- The exit code (Wxx) can be wrong in mt-case.

	  The problem is, ->report_death can't safely access
	  ->group_exit_code with kernel < 2.6.35. This is
	  solveable.

Roland, sorry, I ignored your emails for today. It is not easy to me
to switch between ugdb an utrace ;)

Oleg.

Attachment: ugdb.c
Description: Text document


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