This is the mail archive of the gdb-patches@sourceware.org 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: [RFC] Don't create inferior in tfile target.


On 05/24/2013 09:07 AM, Yao Qi wrote:

>> "detach" unloads the core, and I assumed tfile behaved the same.
>> I think it'd be reasonable if it did.
> 
> 'detach' uploads the core, but I don't think 'detach' should behave the same in tfile target.  The GDB manual says about 'detach' command:
> 
> "When you have finished debugging the attached process, you can use the detach command to release it from gdb control. Detaching the process continues its execution. After the detach command, that process and gdb become completely independent once more, and you are ready to attach another process or start one with run."
> 

> User can use 'detach' command to release the process from gdb control. Command 'detach' applies to core file, because the pid of the process which core file is dumped is stored in core file, so GDB can 'emulate' the pid of the core file.  However, the tfile and ctf doesn't save the pid in it (unnecessary to do so on the other hand), so command 'detach' doesn't apply to tfile.  The output "The program is not being run." of
> command 'detach' on tfile is reasonable to me.

I think that section is assuming native debugging.

When talking about remote debugging, it also says:

When you have finished debugging the remote program, you can use the
@code{detach} command to release it from @value{GDBN} control.
Detaching from the target normally resumes its execution, but the results
will depend on your particular remote stub.  After the @code{detach}
command, @value{GDBN} is free to connect to another target.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Another way to look at it is that "detach" literally detaches
the core, IOW, let's go of it.  Just like you can detach a
remote bare metal target, even if it has no concept of a pid.

And we have also:

@table @code
@kindex detach inferiors @var{infno}@dots{}
@item detach inferior @var{infno}@dots{}
Detach from the inferior or inferiors identified by @value{GDBN}
inferior number(s) @var{infno}@dots{}.  Note that the inferior's entry
still stays on the list of inferiors shown by @code{info inferiors},
but its Description will show @samp{<null>}.

Anyway...

> (gdb) kill
> Kill the program being debugged? (y or n) y
> You can't do that without a process to debug.
> 
> With this patch,
> 
> (gdb) kill
> The program is not being run.
> 
> According to the GDB manual, 'kill' command is "Kill the child process in which your program is running under gdb", we don't have a child process at all on tfile, IMO, the later is more reasonable.

Agreed.

> 
> The output of 'info threads' on tfile changes also,
> 
> without this patch:
> (gdb) info threads
>   Id   Target Id         Frame
> * 1    process 1         No registers.
> 
> with this patch:
> (gdb) info threads
> No threads.
> 
> I feel the latter is more reasonable.

No strong opinion here.  As long as this doesn't confuse
frontends.  Did you try Eclipse?

>> could you audit/grep the tree for null_ptid uses?  E.g.,
>> I see that dcache.c uses null_ptid as magic number, but
>> probably that doesn't matter for tfile.  There don't seem
>> to be that many checks for null_ptid, and many are in run
>> control code, which obviously doesn't apply, so an audit
>> seems doable.
> 
> I examined the null_ptid usages, looks the usages in target.c are not affected by this change.  I also tried commands 'info frame' and 'maintenance print registers', the output is the same.
> 
> In short, this patch changes the output of some commands, but the changes are reasonable to me.  WDYT?

Okay, let's go with it.  Patch is OK.

-- 
Pedro Alves


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