headers
Wu Zhou | 1 Nov 2006 15:34
Picon
Favicon

ping: two proposals about frame unwind in RS6K, specifically in Linux

I ever posted two proposals about frame unwind in RS6000. The first one is at:

http://sources.redhat.com/ml/gdb/2006-10/msg00085.html

which don't skip the prologue when the instruction is bl and the  
target is blrl. I coded a patch based on Joel's initial patch and also  
take Daniel's comment into consideration.  It can fix my problems.   
The original post also said that it brought some modification to the  
test result of gdb's testsuite.  My latest investigation shows that  
there is no regression. So I believe this proposal is ok principally.

The second one is at:

http://sources.redhat.com/ml/gdb/2006-10/msg00276.html

which propose to assume the underlying program will comply to the ABI  
when there is no cfi directive, prologue analysis won't find any  
prologue instructions and current context doesn't not belong to any  
special cases which won't comply to ABI.  I coded a proof-of-concept  
patch, which can fix my problem in quite some case and don't bring  
much problem. So I also think that this is feasible.

Anyone would like to take a look at these?  If there are any errors,  
please feel free to correct and educate me.  Thanks a lot!

Regards
- Wu Zhou
Permalink | Reply | 0 comments |
headers
Vladimir Prus | 1 Nov 2006 20:23

help tests


I'm updating the help.exp testcase for the recently committed changes in help 
output, and I'm starting to wonder if all of those help tests are useful. For 
each command the following is tested:

	- The extact help for the command proper
	- The exact list of subcommands -- for prefix commands and command classes.
	- The epilogue that contains things like:

               Command name abbreviations are allowed if unambiguous

I think it's important to test that "help whatever" produces output, and also 
test some general structure -- like presence of that epilogue. 

On the other hand, I'm not sure that testing for the exact list of subcommands 
is desired. It's not something that can be accidentally broken -- subcommands 
don't get added as side effect of some other change -- they can only appear 
if added explicitly. I also don't think that testing for exact help test for 
the command itself does not make sense -- the help is verbatim string in 
sources -- it can't be accidentally broken and I don't think tests should 
protect against somebody modifying random characters in help strings.

What I think must be tested is that:
	
	1. For every command, class, or prefix command, there's some
	docs.

	2. For classes and prefix commands, help output has the list of
	commands in that class or list of subcommands. But the exact
	list of commands should not be tested.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Nov 2006 21:28

[rfc] "reset" / "create-inferior" commands

Some time ago I asked about name choices for a command which would create a
new process, or restart an existing process, without running it.  I've
already done the GDB internals work for such a command; the only reason I
haven't added one already is that I couldn't come up with a name.

Here's what it should do:
  - When doing native debugging, it should fork and exec the program,
    and run until the command shell execs the real program (if necessary).
  - When connected to a remote embedded board, it should send the "restart"
    packet.

That corresponds in both cases to calling target_create_inferior but not
proceed.

I haven't seen a good name which works for both scenarios.  The best idea so
far comes from Paul Brook - if we call the new command "reset", it's
accurate for boards, and not terribly awkward for native processes.
Alternatively, we could add two names for the command which did the same
thing ("create-inferior" or "create-process" as an alias for "reset").

[I would actually have picked "restart" over "reset", but that's taken for
checkpoints.  We could still steal it and use "restart checkpoint 1" for
checkpoints, if others think restart is preferable to reset.]

Any comments on this name?  I keep wanting the command, so I'd like to find
an acceptable name, and then I can go ahead and implement it.

--

-- 
Daniel Jacobowitz
CodeSourcery
(Continue reading)

Permalink | Reply | 7 comments |
headers
Eli Zaretskii | 1 Nov 2006 21:37
Picon

Re: [rfc] "reset" / "create-inferior" commands

> Date: Wed, 1 Nov 2006 15:28:11 -0500
> From: Daniel Jacobowitz <drow <at> false.org>
> 
> I haven't seen a good name which works for both scenarios.  The best idea so
> far comes from Paul Brook - if we call the new command "reset", it's
> accurate for boards, and not terribly awkward for native processes.
> Alternatively, we could add two names for the command which did the same
> thing ("create-inferior" or "create-process" as an alias for "reset").
> 
> [I would actually have picked "restart" over "reset", but that's taken for
> checkpoints.  We could still steal it and use "restart checkpoint 1" for
> checkpoints, if others think restart is preferable to reset.]
> 
> Any comments on this name?  I keep wanting the command, so I'd like to find
> an acceptable name, and then I can go ahead and implement it.

"restart" is good, IMHO.  Some alternative names we might consider:
reinvoke, start-again.
Permalink | Reply | 1 comment |
headers
Mark Kettenis | 1 Nov 2006 23:55
Picon
Picon
Favicon

Re: [rfc] "reset" / "create-inferior" commands

> Date: Wed, 1 Nov 2006 15:28:11 -0500
> From: Daniel Jacobowitz <drow <at> false.org>
> 
> Some time ago I asked about name choices for a command which would create a
> new process, or restart an existing process, without running it.  I've
> already done the GDB internals work for such a command; the only reason I
> haven't added one already is that I couldn't come up with a name.
> 
> Here's what it should do:
>   - When doing native debugging, it should fork and exec the program,
>     and run until the command shell execs the real program (if necessary).
>   - When connected to a remote embedded board, it should send the "restart"
>     packet.
> 
> That corresponds in both cases to calling target_create_inferior but not
> proceed.
> 
> I haven't seen a good name which works for both scenarios.  The best idea so
> far comes from Paul Brook - if we call the new command "reset", it's
> accurate for boards, and not terribly awkward for native processes.
> Alternatively, we could add two names for the command which did the same
> thing ("create-inferior" or "create-process" as an alias for "reset").
> 
> [I would actually have picked "restart" over "reset", but that's taken for
> checkpoints.  We could still steal it and use "restart checkpoint 1" for
> checkpoints, if others think restart is preferable to reset.]
> 
> Any comments on this name?  I keep wanting the command, so I'd like to find
> an acceptable name, and then I can go ahead and implement it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 2 Nov 2006 00:06

Re: [rfc] "reset" / "create-inferior" commands

On Wed, Nov 01, 2006 at 11:55:49PM +0100, Mark Kettenis wrote:
> This sounds like a command I've always wanted, but I don't associate
> it at all with "reset".  "create-inferior" might be more appropriate,
> but I don't think it'll make sense to people who don't know GDB's
> internals.  How about "setup"?  Sounds to me like that's what this
> command will do; setting up a new process to be debugged.

That does seem more intuitive.

Mark, Eli, how do you feel about using both "restart" and "setup"? 
While they're the same action in GDB internals, I think they're
different actions from the user's point of view.

I'm not going to rush ahead on this - I feel like I've been trying to
come up with a good name for this command for a year now :-)

--

-- 
Daniel Jacobowitz
CodeSourcery
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 Nov 2006 22:11
Favicon

Re: [rfc] "reset" / "create-inferior" commands

> > Any comments on this name?  I keep wanting the command, so I'd like to find
> > an acceptable name, and then I can go ahead and implement it.
> 
> "restart" is good, IMHO.  Some alternative names we might consider:
> reinvoke, start-again.

The only nit I have with "restart" is that it implies that something
is already running. But I presume that the command could be used when
no process has been started yet, right? I would have liked
"start-process", but then it creates a completion collision with
"start".

"create-process" sounds more accurate to me.

--

-- 
Joel
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 2 Nov 2006 05:23
Picon

Re: [rfc] "reset" / "create-inferior" commands

> Date: Wed, 1 Nov 2006 18:06:23 -0500
> From: Daniel Jacobowitz <drow <at> false.org>
> Cc: gdb <at> sourceware.org
> 
> Mark, Eli, how do you feel about using both "restart" and "setup"? 
> While they're the same action in GDB internals, I think they're
> different actions from the user's point of view.

"setup" is too general, IMO.

OTOH, I have no problems with "create-process" or "create-inferior" or
"init-inferior" or "reinit-inferior".
Permalink | Reply | 0 comments |
headers
Fabian Cenedese | 2 Nov 2006 08:29
Picon

Re: *SPAM*Re: Memleaks?

At 07:16 31.10.2006 -0500, Christopher Faylor wrote:
>On Mon, Oct 30, 2006 at 08:45:10AM -0500, Daniel Jacobowitz wrote:
>>On Mon, Oct 30, 2006 at 12:40:56PM +0100, Fabian Cenedese wrote:
>>> I admit that I used not a state-of-the-art gdb, but I don't think that
>>> this was changed recently. I'd be pleased if you can correct me.
>>> 
>>> GNU gdb 6.2.50_2004-10-14-cvs
>>
>>This is two years old; I can't really speculate on what has changed
>>since then.  It may be simple memory leaks, or it may be something more
>>complex.
>
>FWIW, the current Cygwin version of gdb is 6.5+.

Which has the same errors.

bye  Fabi
Permalink | Reply | 0 comments |
headers
Andrew STUBBS | 2 Nov 2006 12:52

Re: [rfc] "reset" / "create-inferior" commands

Daniel Jacobowitz wrote:
> [I would actually have picked "restart" over "reset", but that's taken for
> checkpoints.  We could still steal it and use "restart checkpoint 1" for
> checkpoints, if others think restart is preferable to reset.]

If the initial state is (or can be) considered a special checkpoint then 
this is what it should be.

Otherwise the concepts, and therefore commands, should not be confused.

Another possible name I haven't seen yet is 'launch'.

Andrew
Permalink | Reply | 1 comment |

Gmane