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: [patch] Skip gdb.threads/execl.exp on remote target


On Thursday 23 June 2011 08:16:04, Yao Qi wrote:
> > 
> >>
> >> The condition checking in my patch is "{ [is_remote target] }", instead
> >> of "{ [is_remote target] || ![isnative] }", which is widely used
> >> elsewhere, because "![isnative]" can be regarded as a subset of
> >> "is_remote target".  I can't think of a case that non-native debugger
> >> works with non-remote board.  Am I missing something?
> > 
> > isnative just returns whether the build triplet is the same
> > as the target _triplet_.  It's unrelated to whether the remote
> > protocol is being used or not, and it's orthogonal to the board
> > in use.  Not using it here is correct, because for example,
> > one may be running dejagnu on a x86-linux machine (build), using
> > remote host testing to test a native debugger running on
> > an HP-UX host, and we'd still want gdb's native exec support
> > to be tested then.
> > 
> 
> Following your example, I am wondering is "proc isnative" used correctly
> or is "proc isnative" what we need in test cases?  In your example
> (build = x86_64-linux, target == host == HP-UX), foll-fork.exp,
> foll-vfork.exp, multi-forks.exp, and checkpoint.exp can be run, but they
> are skipped because isnative returns 0.
> 
> If so, we may need a new proc is_native_debugger, and replace isnative
> by it in some cases.  What do you think?
> 
> # Return 1 if a native debugger is build (either native build or cross #
> build).
> proc is_native_debugger { } {
>     global target_triplet
>     global host_triplet
> 
>     if {[string match $host_triplet $target_triplet]} {
>         return 1
>     }
>     return 0
> }

Yes, and no.  Yes, centralized procedures that expose an API
with the semantics we need is nice, so that we don't have to
think these things over and over.  This remote/native business
is indeed a source of never ending confusion.  And no,
"is_native_debugger" makes it sound like you'll return true if
you're debugging with the native debugger rather than target
remote or target sim, say.  You could be testing x86-linux
gdbserver on a x86-linux host, and that would return true
to is_native_debugger.

-- 
Pedro Alves


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