Re: Pending breakpoints and scripts

Re: Pending breakpoints and scripts

[Michael Elizabeth Chastain]

> Thoughts?

You might not agree with this thought ... push back the branch cut until
there haven't been any new "breakpoint pending" issues surfaced for a
week.

(Kind of a brutal thought, I know)

Michael C

Re: Pending breakpoints and scripts

[Andrew Cagney]

> Thoughts?
> 
> 
> You might not agree with this thought ... push back the branch cut until
> there haven't been any new "breakpoint pending" issues surfaced for a
> week.
> 
> (Kind of a brutal thought, I know)

Well, looking at the math:

- I post the enable tui patch today (...)
- wait a week
- I commit the enable tui patch (which will make a mess)
- wait a week
- branch

that puts the branch at ~22.

I think enabling the TUI will make this breakpoint stuff look like a ripple.

(I'm obviously going to have to commit the TUI stuff earlier :-/)

Andrew

New command

[MuthuKumar-Hotpop]

Hello All,

I have tried to define the user commands in the GDB as
define clr
>she clear
>end
document clr
>It is used to clear the gdb workspace screen.
>end

The changes are in the particular session only.When I quit the gdb ,the next time there is no command like that.
What we have to do to make the user-command to be put permanently.

Thanks,
Muthukumar

Re: New command

[Kip Macy]

add the definition to your .gdbinit

On Tue, 10 Feb 2004, MuthuKumar-Hotpop wrote:

> Hello All,
>
> I have tried to define the user commands in the GDB as
> define clr
> >she clear
> >end
> document clr
> >It is used to clear the gdb workspace screen.
> >end
>
> The changes are in the particular session only.When I quit the gdb ,the next time there is no command like that.
> What we have to do to make the user-command to be put permanently.
>
> Thanks,
> Muthukumar
>
>
>
>

Re: New command

[MuthuKumar-Hotpop]

Hello Kip and all,

 Thanks.I am using HP-UX.
GDB version is 
HP gdb 4.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.

Thanks,
Muthukumar


> add the definition to your .gdbinit
> 
> > I have tried to define the user commands in the GDB as
> > define clr
> > >she clear
> > >end
> > document clr
> > >It is used to clear the gdb workspace screen.
> > >end
> >
> > The changes are in the particular session only.When I quit the gdb ,the next time there is no command like that.
> > What we have to do to make the user-command to be put permanently.
> >

Pending breakpoints and scripts

[Andrew Cagney]

Anyone noticed this?

(top-gdb) run testsuite/gdb.base/advance
Starting program: ...
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Breakpoint 1 (internal_error) pending.
Function "info_command" not defined.
Breakpoint 2 (info_command) pending.
(top-gdb)

It's caused by this:

           if (!query ("Make breakpoint pending on future shared library 
load? ")
)
             return rc;

The old behavior was: when in batch mode, throw an error (and hence 
abandon the script) if the breakpoint insert fails.

The new behavior is: when in batch mode, always insert the breakpoint. 
when not in batch mode never throw an error.

For the existing behavior to be restored the query's logic would need to 
be reversed (ask the oposite question) and then re-throw the error.  A 
/pending qualifier could then be added.

Thoughts?
Andrew

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Mon, Feb 09, 2004 at 03:02:19PM -0500, Andrew Cagney wrote:
> Anyone noticed this?
> 
> (top-gdb) run testsuite/gdb.base/advance
> Starting program: ...
> Setting up the environment for debugging gdb.
> Function "internal_error" not defined.
> Breakpoint 1 (internal_error) pending.
> Function "info_command" not defined.
> Breakpoint 2 (info_command) pending.
> (top-gdb)
> 
> It's caused by this:
> 
>           if (!query ("Make breakpoint pending on future shared library 
> load? ")
> )
>             return rc;
> 
> The old behavior was: when in batch mode, throw an error (and hence 
> abandon the script) if the breakpoint insert fails.
> 
> The new behavior is: when in batch mode, always insert the breakpoint. 
> when not in batch mode never throw an error.
> 
> For the existing behavior to be restored the query's logic would need to 
> be reversed (ask the oposite question) and then re-throw the error.  A 
> /pending qualifier could then be added.
> 
> Thoughts?

I'd rather not reverse the question.  We could check from_tty at the
call site, and not set pending breakpoints if no tty...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Andrew Cagney]

> On Mon, Feb 09, 2004 at 03:02:19PM -0500, Andrew Cagney wrote:
> 
>> Anyone noticed this?
>> 
>> (top-gdb) run testsuite/gdb.base/advance
>> Starting program: ...
>> Setting up the environment for debugging gdb.
>> Function "internal_error" not defined.
>> Breakpoint 1 (internal_error) pending.
>> Function "info_command" not defined.
>> Breakpoint 2 (info_command) pending.
>> (top-gdb)
>> 
>> It's caused by this:
>> 
>>           if (!query ("Make breakpoint pending on future shared library 
>> load? ")
>> )
>>             return rc;
>> 
>> The old behavior was: when in batch mode, throw an error (and hence 
>> abandon the script) if the breakpoint insert fails.
>> 
>> The new behavior is: when in batch mode, always insert the breakpoint. 
>> when not in batch mode never throw an error.
>> 
>> For the existing behavior to be restored the query's logic would need to 
>> be reversed (ask the oposite question) and then re-throw the error.  A 
>> /pending qualifier could then be added.
>> 
>> Thoughts?
> 
> 
> I'd rather not reverse the question.  We could check from_tty at the
> call site, and not set pending breakpoints if no tty...

Why?

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Tue, Feb 10, 2004 at 04:22:41PM -0500, Andrew Cagney wrote:
> >On Mon, Feb 09, 2004 at 03:02:19PM -0500, Andrew Cagney wrote:
> >
> >>Anyone noticed this?
> >>
> >>(top-gdb) run testsuite/gdb.base/advance
> >>Starting program: ...
> >>Setting up the environment for debugging gdb.
> >>Function "internal_error" not defined.
> >>Breakpoint 1 (internal_error) pending.
> >>Function "info_command" not defined.
> >>Breakpoint 2 (info_command) pending.
> >>(top-gdb)
> >>
> >>It's caused by this:
> >>
> >>          if (!query ("Make breakpoint pending on future shared library 
> >>load? ")
> >>)
> >>            return rc;
> >>
> >>The old behavior was: when in batch mode, throw an error (and hence 
> >>abandon the script) if the breakpoint insert fails.
> >>
> >>The new behavior is: when in batch mode, always insert the breakpoint. 
> >>when not in batch mode never throw an error.
> >>
> >>For the existing behavior to be restored the query's logic would need to 
> >>be reversed (ask the oposite question) and then re-throw the error.  A 
> >>/pending qualifier could then be added.
> >>
> >>Thoughts?
> >
> >
> >I'd rather not reverse the question.  We could check from_tty at the
> >call site, and not set pending breakpoints if no tty...
> 
> Why?

Well, how would you word it?  It makes more intuitive sense to me to
answer 'y' to create something special and 'n' to do nothing, than the
other way around.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Andrew Cagney]

>> >I'd rather not reverse the question.  We could check from_tty at the
>> >call site, and not set pending breakpoints if no tty...
> 
>> 
>> Why?
> 
> 
> Well, how would you word it?  It makes more intuitive sense to me to
> answer 'y' to create something special and 'n' to do nothing, than the
> other way around.

Something like:

"Discard breakpoint, rather than mark it pending?"

is a guess.

The real problem here is with batch scripts, the change breaks existing 
script behavior (which is never a good thing).

How about this, we introduce:
	nquery()
	yquery()
where the default (batch mode, and when return is pressed is n/y 
respectively).  We'd need the language police to look over the interface 
but should otherwize be ok.

Andrew

PS: There's a GUI bug here also.  The query doesn't contain the error 
message (cf my recent change to internal-error where I made certain each 
query contained the full context of the question).

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Wed, Feb 11, 2004 at 09:31:23AM -0500, Andrew Cagney wrote:
> 
> >>>I'd rather not reverse the question.  We could check from_tty at the
> >>>call site, and not set pending breakpoints if no tty...
> >
> >>
> >>Why?
> >
> >
> >Well, how would you word it?  It makes more intuitive sense to me to
> >answer 'y' to create something special and 'n' to do nothing, than the
> >other way around.
> 
> Something like:
> 
> "Discard breakpoint, rather than mark it pending?"
> 
> is a guess.

That's why I don't want to reverse the question - I find that really
unintuitive.  Perhaps it's just me.

> The real problem here is with batch scripts, the change breaks existing 
> script behavior (which is never a good thing).
> 
> How about this, we introduce:
> 	nquery()
> 	yquery()
> where the default (batch mode, and when return is pressed is n/y 
> respectively).  We'd need the language police to look over the interface 
> but should otherwize be ok.

Works for me.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Andrew Cagney]

> The real problem here is with batch scripts, the change breaks existing 
>> script behavior (which is never a good thing).
>> 
>> How about this, we introduce:
>> 	nquery()
>> 	yquery()
>> where the default (batch mode, and when return is pressed is n/y 
>> respectively).  We'd need the language police to look over the interface 
>> but should otherwize be ok.
> 
> 
> Works for me.

Lets see if we can pin down the interface (adding JeffJ to the CC list):

nquery("A question?")

	A question? [n]:

	- press return => implied "n"
	- batch mode => implied "n"

that would mean here:

> if (!query ("Make breakpoint pending on future shared library load? ")

nquery ("Make breakpoint pending on future shared library load?");

	Make breakpoint pending on future shared library load? [n]:

	- press return => old behavior
	- batch mode => old behavior
	- "y" => new behavior

Looking at the "set breakpoint pending":

yes - implies the above is "y"
no - implies that the above is "n"
auto - implies that the query occures

Jeff, work for you?

Andrew

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 02:24:32PM -0500, Andrew Cagney wrote:
> >The real problem here is with batch scripts, the change breaks existing 
> >>script behavior (which is never a good thing).
> >>
> >>How about this, we introduce:
> >>	nquery()
> >>	yquery()
> >>where the default (batch mode, and when return is pressed is n/y 
> >>respectively).  We'd need the language police to look over the interface 
> >>but should otherwize be ok.
> >
> >
> >Works for me.
> 
> Lets see if we can pin down the interface (adding JeffJ to the CC list):
> 
> nquery("A question?")
> 
> 	A question? [n]:
> 
> 	- press return => implied "n"
> 	- batch mode => implied "n"

How would you feel about "[n/y]"?  Otherwise, I like this.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Andrew Cagney]

> On Tue, Feb 17, 2004 at 02:24:32PM -0500, Andrew Cagney wrote:
> 
>> >The real problem here is with batch scripts, the change breaks existing 
> 
>> >>script behavior (which is never a good thing).
>> >>
>> >>How about this, we introduce:
>> >>	nquery()
>> >>	yquery()
>> >>where the default (batch mode, and when return is pressed is n/y 
>> >>respectively).  We'd need the language police to look over the interface 
>> >>but should otherwize be ok.
> 
>> >
>> >
>> >Works for me.
> 
>> 
>> Lets see if we can pin down the interface (adding JeffJ to the CC list):
>> 
>> nquery("A question?")
>> 
>> 	A question? [n]:
>> 
>> 	- press return => implied "n"
>> 	- batch mode => implied "n"
> 
> 
> How would you feel about "[n/y]"?  Otherwise, I like this.

As in?

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 02:39:05PM -0500, Andrew Cagney wrote:
> >On Tue, Feb 17, 2004 at 02:24:32PM -0500, Andrew Cagney wrote:
> >
> >>>The real problem here is with batch scripts, the change breaks existing 
> >
> >>>>script behavior (which is never a good thing).
> >>>>
> >>>>How about this, we introduce:
> >>>>	nquery()
> >>>>	yquery()
> >>>>where the default (batch mode, and when return is pressed is n/y 
> >>>>respectively).  We'd need the language police to look over the 
> >>interface >>but should otherwize be ok.
> >
> >>>
> >>>
> >>>Works for me.
> >
> >>
> >>Lets see if we can pin down the interface (adding JeffJ to the CC list):
> >>
> >>nquery("A question?")
> >>
> >>	A question? [n]:
> >>
> >>	- press return => implied "n"
> >>	- batch mode => implied "n"
> >
> >
> >How would you feel about "[n/y]"?  Otherwise, I like this.
> 
> As in?

nquery("A question?");
  A question? (n or y) <CURSOR>

or

  A question? [n/y]: <CURSOR>

Simply to clarify that it is a yes-no question.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Jeff Johnston]

Daniel Jacobowitz wrote:
> On Tue, Feb 17, 2004 at 02:39:05PM -0500, Andrew Cagney wrote:
> 
>>>On Tue, Feb 17, 2004 at 02:24:32PM -0500, Andrew Cagney wrote:
>>>
>>>
>>>>>The real problem here is with batch scripts, the change breaks existing 
>>>
>>>>>>script behavior (which is never a good thing).
>>>>>>
>>>>>>How about this, we introduce:
>>>>>>	nquery()
>>>>>>	yquery()
>>>>>>where the default (batch mode, and when return is pressed is n/y 
>>>>>>respectively).  We'd need the language police to look over the 
>>>>
>>>>interface >>but should otherwize be ok.
>>>
>>>>>
>>>>>Works for me.
>>>

Me too.

>>>>Lets see if we can pin down the interface (adding JeffJ to the CC list):
>>>>
>>>>nquery("A question?")
>>>>
>>>>	A question? [n]:
>>>>
>>>>	- press return => implied "n"
>>>>	- batch mode => implied "n"
>>>
>>>
>>>How would you feel about "[n/y]"?  Otherwise, I like this.
>>
>>As in?
> 
> 
> nquery("A question?");
>   A question? (n or y) <CURSOR>
> 
> or
> 
>   A question? [n/y]: <CURSOR>
> 
> Simply to clarify that it is a yes-no question.
> 

I agree you have to indicate a yes/no question.  Would it be clearer to add 
square brackets around the default in each case ([y] or n) vs (y or [n])?  This 
is closer to the old query which was (y or n).

-- Jeff J.

Re: Pending breakpoints and scripts

[Andrew Cagney]

> I agree you have to indicate a yes/no question.  Would it be clearer to add square brackets around the default in each case ([y] or n) vs (y or [n])?  This is closer to the old query which was (y or n).

That appears to work.  " (y or n) [n]: " is getting too long.

Andrew

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 03:14:30PM -0500, Andrew Cagney wrote:
> >I agree you have to indicate a yes/no question.  Would it be clearer to 
> >add square brackets around the default in each case ([y] or n) vs (y or 
> >[n])?  This is closer to the old query which was (y or n).
> 
> That appears to work.  " (y or n) [n]: " is getting too long.

Fine by me.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Andrew Cagney]

>> >>Lets see if we can pin down the interface (adding JeffJ to the CC list):
>> >>
>> >>nquery("A question?")
>> >>
>> >>	A question? [n]:
>> >>
>> >>	- press return => implied "n"
>> >>	- batch mode => implied "n"
> 
>> >
>> >
>> >How would you feel about "[n/y]"?  Otherwise, I like this.
> 
>> 
>> As in?
> 
> 
> nquery("A question?");
>   A question? (n or y) <CURSOR>
> 
> or
> 
>   A question? [n/y]: <CURSOR>
> 
> Simply to clarify that it is a yes-no question.

Er, ...

 > How about this, we introduce:
 > 	nquery()
 > 	yquery()
 > where the default (batch mode, and when return is pressed is n/y
 > respectively).

with what you suggest, how is the user to differientiate the 
consequences of entering return when presented with either of:
	nquery("A question?")
	A question? [y/n]:
and
	yquery("A question?")
	A question? [y/n]:
something like:
	A question? (y or n) [n]:
would be needed (which would be getting into redundant verbage).
	
Andrew

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 03:13:19PM -0500, Andrew Cagney wrote:
> 
> >>>>Lets see if we can pin down the interface (adding JeffJ to the CC list):
> >>>>
> >>>>nquery("A question?")
> >>>>
> >>>>	A question? [n]:
> >>>>
> >>>>	- press return => implied "n"
> >>>>	- batch mode => implied "n"
> >
> >>>
> >>>
> >>>How would you feel about "[n/y]"?  Otherwise, I like this.
> >
> >>
> >>As in?
> >
> >
> >nquery("A question?");
> >  A question? (n or y) <CURSOR>
> >
> >or
> >
> >  A question? [n/y]: <CURSOR>
> >
> >Simply to clarify that it is a yes-no question.
> 
> Er, ...
> 
> > How about this, we introduce:
> > 	nquery()
> > 	yquery()
> > where the default (batch mode, and when return is pressed is n/y
> > respectively).
> 
> with what you suggest, how is the user to differientiate the 
> consequences of entering return when presented with either of:
> 	nquery("A question?")
> 	A question? [y/n]:
> and
> 	yquery("A question?")
> 	A question? [y/n]:
> something like:
> 	A question? (y or n) [n]:
> would be needed (which would be getting into redundant verbage).

Easy, it would be:
> 	nquery("A question?")
> 	A question? [n/y]:

> 	yquery("A question?")
> 	A question? [y/n]:

If you want to use (y or n) [y], then that's fine by me too.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Pending breakpoints and scripts

[Andrew Cagney]

> with what you suggest, how is the user to differientiate the 
>> consequences of entering return when presented with either of:
>> 	nquery("A question?")
>> 	A question? [y/n]:
>> and
>> 	yquery("A question?")
>> 	A question? [y/n]:
>> something like:
>> 	A question? (y or n) [n]:
>> would be needed (which would be getting into redundant verbage).
> 
> 
> Easy, it would be:

This is a joke, right?

>> 	nquery("A question?")
>> 	A question? [n/y]:
> 
> 
>> 	yquery("A question?")
>> 	A question? [y/n]:
> 
> 
> If you want to use (y or n) [y], then that's fine by me too.

Jeff's come up with a workable solution.

Andrew

Re: Pending breakpoints and scripts

[Daniel Jacobowitz]

On Tue, Feb 17, 2004 at 03:30:27PM -0500, Andrew Cagney wrote:
> >with what you suggest, how is the user to differientiate the 
> >>consequences of entering return when presented with either of:
> >>	nquery("A question?")
> >>	A question? [y/n]:
> >>and
> >>	yquery("A question?")
> >>	A question? [y/n]:
> >>something like:
> >>	A question? (y or n) [n]:
> >>would be needed (which would be getting into redundant verbage).
> >
> >
> >Easy, it would be:
> 
> This is a joke, right?

No, it was a serious suggestion.  It's pretty standard for the first
option to be the default.  If you don't like it, that's fine, Jeff's
suggestion works for me also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer