headers
Joel Brobecker | 1 Jul 2008 02:28
Favicon

Re: [RFC] Use gnulib's stdint.h.

Hi Bruno,

> > >   2. ctype/safe-ctype conflict. For instance, cp-support.c includes
> > >      safe-ctype.h.  But at the same time, we previously included
> > >      defs.h, which itself includes gnulib/stdint.h, which includes
> > >      <wchar.h> which includes <ctypes.h>.
> > 
> > > Problem #2 is a lot more problematic, however. I might argue that
> > > this is a actually bug inside gnulib and that gnulib/stdint.h
> > > should be generated in a way that avoids including other standard
> > > header files.
> 
> No. gnulib makes no guarantee that particular headers or symbols are
> not defined.

I wasn't really suggesting that gnulib should make a general guaranty,
but if the wchar.h include could easily be avoided, then it would have
made GDB's life a little easier. It was worth asking :)

>   3. In those places where gnulib could control these extra #includes,
>      the price would be sets of #ifdefs that would be too clumsy to be
>      maintainable.

I see your point.

> The bug is in safe-ctype.h:
> 
>   #ifdef isalpha
>    #error "safe-ctype.h and ctype.h may not be used simultaneously"
>   #endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Jacobowitz | 1 Jul 2008 02:51

Re: [non-stop] 10/10 split user/internal threads

On Mon, Jun 30, 2008 at 01:08:48AM +0100, Pedro Alves wrote:
> - In non-stop mode, the current thread may exit while the
>   user has it selected.  Switching current thread, and restoring
>   it with a cleanup is problematic in non-stop mode.

The target interface is async, the inferior program is running - but
GDB retains a single thread of control.  So unless the inferior runs
while the cleanup is live, there's no problem here.  I suppose it
could be trouble if you enter the expression evaluator, though?

>      Now this example:
> 
>    - User has thread 1 selected.
>    - thread 2 has an event
>    - GDB switches to thread 2 to handle it
>    - It was a breakpoint, and has breakpoint commands attached to it.
>    - The breakpoint has several commands attached actually:
>          thread 3
>          print value1
>          up
>          print value2
>          up
>          print value3
>          end
> 
>    - GDB has finished handling the event, so should restore to the
>      user selected thread and frame.  But, which is it now?
>      thread 1, or thread 3?  In all-stop mode?  In non-stop mode?

IMO it's thread 3 in all-stop and thread 1 in non-stop.  This is a
(Continue reading)

Permalink | Reply | 7 comments |
headers
Joel Brobecker | 1 Jul 2008 03:15
Favicon

Re: [rfc] Replace current_gdbarch in *mips*

Hi Markus,

> this patch replaces most of the current_gdbarch's found in *mips*.
> These replacements are mostly mechanical changes. Unfortunately I dont
> have access to MIPS (linux, bsd, remote) machines.  This patch is
> hence only "tested" by building GDB with --enable-targets=all.

I finally checked out the results of the testing on mips-irix, and
they came out OK. Beware that this only takes care of testing the
changes inside mips-tdep.c and even so the results on this platform
are not stellar. Nonetheless, it's nice to see that it didn't reveal
any new visible regression! :-)

--

-- 
Joel
Permalink | Reply | 1 comment |
headers
Vladimir Prus | 1 Jul 2008 05:53

Re: [MI non-stop 04/11] Implement --thread and --frame.

On Sunday 29 June 2008 21:49:52 Eli Zaretskii wrote:

> > > I dunno, does the MI spec mandate decimal here?  If it does, then my
> > > comment is hereby withdrawn.
> > 
> > The spec does not mandate decimal, or allow hex -- yet. Other commands that
> > take numbers are also silent, however the code appears to use decimal. For
> > example, -stack-list-args and friends use atoi -- which is 10-base.
> 
> Then perhaps we should document that it must be decimal.

Yes. Added to my documentation todo.

- Volodya
Permalink | Reply | 0 comments |
headers
Pedro Alves | 1 Jul 2008 15:37

Re: [non-stop] 10/10 split user/internal threads

A Tuesday 01 July 2008 01:51:28, Daniel Jacobowitz wrote:
> On Mon, Jun 30, 2008 at 01:08:48AM +0100, Pedro Alves wrote:
> > - In non-stop mode, the current thread may exit while the
> >   user has it selected.  Switching current thread, and restoring
> >   it with a cleanup is problematic in non-stop mode.
>
> The target interface is async, the inferior program is running - but
> GDB retains a single thread of control.  So unless the inferior runs
> while the cleanup is live, there's no problem here.  I suppose it
> could be trouble if you enter the expression evaluator, though?

Sure it can run while the cleanup is live.  It could already be
running when the cleanup was created.  Remember that the selected
thread may be running at any time.

If the selected thread was not running, but it is set
running while the cleanup is live, and we enter the expression
evaluator, I don't think there's a problem currently, as
returning from infcalls tries to restore the originally
selected frame.

The other case the current thread may be set running is:

01: foo3()
02: {
03: }
04: 
05: foo2()
06: {
07:   foo3();
(Continue reading)

Permalink | Reply | 6 comments |
headers
Daniel Jacobowitz | 1 Jul 2008 16:03

Re: [non-stop] 10/10 split user/internal threads

On Tue, Jul 01, 2008 at 02:37:44PM +0100, Pedro Alves wrote:
> A Tuesday 01 July 2008 01:51:28, Daniel Jacobowitz wrote:
> > On Mon, Jun 30, 2008 at 01:08:48AM +0100, Pedro Alves wrote:
> > > - In non-stop mode, the current thread may exit while the
> > >   user has it selected.  Switching current thread, and restoring
> > >   it with a cleanup is problematic in non-stop mode.
> >
> > The target interface is async, the inferior program is running - but
> > GDB retains a single thread of control.  So unless the inferior runs
> > while the cleanup is live, there's no problem here.  I suppose it
> > could be trouble if you enter the expression evaluator, though?
> 
> Sure it can run while the cleanup is live.  It could already be
> running when the cleanup was created.  Remember that the selected
> thread may be running at any time.

Doesn't matter if the thread is already running.  We won't go looking
for events while normal cleanups are on the stack in most cases - so
even if the thread exits, we won't remove it from the thread list
until later.  But the evaluator, and some commands, might cause us to
return to w_f_i.  That's all I meant.

> The user loses the selected frame in thread 1, because when
> the cleanup is ran, the thread is running/stepping.
> Since the thread stepped into another frame, we could
> claim that since the originally selected frame is still live,
> it should still be selected.  But, it can also be
> claimed that, though luck, the thread was set running,
> you lose the selected frame.  This doesn't seem
> like an important enough case to care about.  Agree?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Pierre Muller | 1 Jul 2008 23:37
Picon
Picon

[RFA] use filename_completer for add_setshow_optional_filename_cmd


  I discovered that
set debug-file-directory does not use filename_completer.

  This is because add_setshow_optional_filename_cmd
does not set the set completer to filename completer,
contrary to add_setshow_filename_cmd.

  Is there any reason for this?
Or is it just a bug?

  The following small patch fixes this
by setting the set part completer to filename_completer
for  add_setshow_optional_filename_cmd
exactly as is done in add_setshow_filename_cmd.

  There are currently only three adffected commands:

"set debug-file-directory"
"set args"
"set solib-search-path"

  Only the second one might be questionable,
but I also find that it is reasonable to have filename
completion for "set args" as this is now done on
most shells.

  I ran the testsuite with that patch on cygwin,
and the only difference I got was in gdb.trace/packetlen.exp
but I can't see any relation with the patch, and this
(Continue reading)

Permalink | Reply | 6 comments |
headers
Pedro Alves | 2 Jul 2008 00:02

Re: [RFA] use filename_completer for add_setshow_optional_filename_cmd

(following the spirit of speaking up if you spent the time
 looking at the patch)

A Tuesday 01 July 2008 22:37:42, Pierre Muller wrote:
>   I discovered that
> set debug-file-directory does not use filename_completer.
>
>   This is because add_setshow_optional_filename_cmd
> does not set the set completer to filename completer,
> contrary to add_setshow_filename_cmd.
>
>   Is there any reason for this?
> Or is it just a bug?

IMHO, it's just a feature miss.

>   The following small patch fixes this
> by setting the set part completer to filename_completer
> for  add_setshow_optional_filename_cmd
> exactly as is done in add_setshow_filename_cmd.
>
>   There are currently only three adffected commands:
>
> "set debug-file-directory"
> "set args"
> "set solib-search-path"
>
>   Only the second one might be questionable,
> but I also find that it is reasonable to have filename
> completion for "set args" as this is now done on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pedro Alves | 2 Jul 2008 05:28

Re: [non-stop] 10/10 split user/internal threads

A Tuesday 01 July 2008 15:03:11, Daniel Jacobowitz wrote:
> On Tue, Jul 01, 2008 at 02:37:44PM +0100, Pedro Alves wrote:
> > A Tuesday 01 July 2008 01:51:28, Daniel Jacobowitz wrote:
> > > On Mon, Jun 30, 2008 at 01:08:48AM +0100, Pedro Alves wrote:
> > There's one issue that I'd like to point out.  That is, is a
> > thread exits, and it was inferior_ptid, we can't just switch
> > inferior_ptid to null_ptid as I could with split user/internal
> > threads split.  A *lot* of things break.
> >
> > The issue arises with the OS quickly reusing ptids:
> >
> >   - inferior_ptid (ptid1) exits, we can't delete it from the
> >     thread list yet (things break, e.g. context switching...,
> >     but many other things break in target code.)
> >   - We mark it with THREAD_EXITED, but leave it there.
> >   - target notifies new thread with ptid1.  There's already
> >     such a thread in the list, and it's also the
> >     current thread -- inferior_ptid.
> >   - To add this new thread to the list, we must get rid
> >     of the old exited thread.  Conceptually, this new thread
> >     although it has the target identifier, it should have a
> >     new GDB thread id.  So, we could say that in this case,
> >     the "non-stop doesn't change threads" premise breaks.  But,
> >     then again, the user couldn't do anything to the exited
> >     thread anyway, and it can only exit is it is running, in which
> >     case the user also couldn't do most things with it.  Maybe we
> >     can just live with this exception.
>
> IMO, as long as GDB is not likely to crash, I don't think there's a
> big problem here.  If we, for instance, fail to report one pair of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pedro Alves | 2 Jul 2008 05:29

Re: [non-stop] 01/10 Add "executing" property

A Monday 23 June 2008 02:03:53, Daniel Jacobowitz wrote:
> On Tue, Jun 17, 2008 at 07:24:04PM +0100, Pedro Alves wrote:
> >  <at>  <at>  -422,7 +417,10  <at>  <at>  execute_command (char *p, int from_tty)
> >
> >        /* If the target is running, we allow only a limited set of
> >           commands. */
> > -      if (target_can_async_p () && target_executing && !get_cmd_async_ok
> > (c)) +      if (target_can_async_p ()
> > +	  && target_has_execution
> > +	  && any_running ()
> > +	  && !get_cmd_async_ok (c))
> >  	error (_("Cannot execute this command while the target is running."));
> >
> >        /* Pass null arg rather than an empty one.  */
>
> Don't need target_has_execution here anymore, do we?

That's correct.  I've fixed it.  I've also removed the stop_soon check
that you noticed I was dropping in a later patch in the series.  I
couldn't find a reason it is needed now.

> The patch otherwise looks OK.

Thanks.  Here's the updated patch that I'll commit unless there
are more comments to it.

--

-- 
Pedro Alves
Attachment (001-is_executing.diff): text/x-diff, 20 KiB
(Continue reading)

Permalink | Reply | 0 comments |

Gmane