Xen devel - May 2005 - RE: possible changes was Re: [PATCH] make domu_debug run-time option + fix int3 handling for MP

> This is a continuation of the discussion that we had when the 
> initial debug support went in. At the time Christian and you 
> thought that it would be ideal if domu_debug were a 
> domain-build / run-time option, as opposed to a xen 
> compile-time option. For the sake of expediency I didn''t do 
> it at the time. This patch was intended to rectify that. 
I was envisaging it as a flag that could be set/cleared at runtime for a
domain, for example, when the gdbserver attached and detached.

I don''t think it''s a domain builder issue.

Thanks,
Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> I was envisaging it as a flag that could be set/cleared at runtime for a
> domain, for example, when the gdbserver attached and detached.
That is fine. There is just the issue of the initial timing window. Also, if the
gdbserver crashes it isn''t really an issue if the flag isn''t
cleared because one
can still run ''xm destroy''. In Linux (2.6.11.8 at least) one
can create
unkillable processes by killing GDB when it is attached to another process.

 
> I don''t think it''s a domain builder issue.
What do I do if I''m starting an OS specifically for debugging? Right
now I can
do an int3 so that it will be paused. GDB isn''t doing the forking and
gdbserver
can''t attach until the VM is running, so there is no equivalent to
putting a
breakpoint on main(). I guess pausing the guest immediately after creation could
work.

			
			-Kip

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>> I don''t think it''s a domain builder issue.
>
> What do I do if I''m starting an OS specifically for debugging?
Right
> now I can
> do an int3 so that it will be paused. GDB isn''t doing the forking
and
> gdbserver
> can''t attach until the VM is running, so there is no equivalent to
> putting a
> breakpoint on main(). I guess pausing the guest immediately after 
> creation could
> work.
Doesn''t the gdb server have to attach to the new vm to be able to set 
the breakpoint, leading to a race anyway? Or have you some way to 
pre-insert an int3?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> Doesn''t the gdb server have to attach to the new vm to be able to
set
> the breakpoint, leading to a race anyway? Or have you some way to 
> pre-insert an int3?
There have been times when I''ve messed things up really early on so
I''ve just
re-compiled with an int3 in locore.s. For developers who wan''t to be
able to set
breakpoints early in boot, I''ve added a boot time option to the command
line
that gets handled in machdep.c:

	if ((caddr_t)xen_start_info->cmd_line)
		kern_envp = xen_setbootenv((caddr_t)xen_start_info->cmd_line);

	boothowto |= xen_boothowto(kern_envp);

        if (boothowto & RB_GDB_PAUSE)
            __asm__("int $0x3;");

This way the VM got paused very early on in boot so that when the gdbserver got 
to attaching to it it hadn''t gotten very far.

=========================================================================
But my recent jaunt through xm has lead me to a cleaner solution:

gopts.opt(''paused'', short=''p'',
          fn=set_true, default=0,
          use=''Leave the domain paused after it is created.'')


So I think we''re good.

Thanks.


					-Kip

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel