A few things we've been up to at Apple lately

A few things we've been up to at Apple lately

[Jason Molenda]

Hey all, I figured I'd send a note to say what's up as long as I'm
sending in a patch.

Klee and I have been going over the testsuite on our platform for
the past couple months.  Over time, our gdb had diverged from the
FSF gdb to the point where we had ~800 failures and a couple hundred
unresolved test cases -- the testsuite was useless for us.  We've
been fixing testcases to match our output where we've purposely
diverged from the FSF style; fixing our code to behave correctly;
and filing Apple internal bug reports for all the known failures.
We're down to 15-20 unfiled fails now, and many of those are known
failures in the generic code.

My time allocated for fixing test cases has expired, but as my last
little bit of work I created a testsuite/gdb.apple directory and
put in some really horribly written test cases :-) for several of
our platform-specific features or general features that haven't
been pushed back to the FSF.   (the latest version of all of this
is not yet on the mainline - the supercow-branch is where all the
action is at the moment)


Not to steal his thunder, but Jim Ingham has recently been adding
dynamic type information to varobj's for our long-suffering C++
users' benefit.  When a varobj represents a pointer to an object,
and the inferior changes the pointer to a different class (in the
same inheritance tree, I gather), var-update will record that
difference and know that any children of that varobj are now dead.
He does all of this with the rtti_type information.  I'm pretty
C++-stupid; Jim could explain why this is such a spiffy good thing
better than me.


Although not strictly new, Rab Hagy recently added a clever feature
to the Project Builder debugger UI for some common ObjectiveC
objects, e.g. NSString (akin to C++'s String).  When PB is displaying
an NSString object (or an object that inherits from NSString) in
its Locals window, it makes an inferior function call to render it
to a C string, which it displays.  People who program in language
like ObjC use the native String classes to store these sorts of
things, and a GUI that only displays a pointer to the object in its
Locals window is remarkably frustrating.  The cost of making these
inferior function calls is hard to swallow, but we've found it
makes the tool vastly more usable for end users.

Klee's recent changes have been almost entirely concerned with
boring old MacOS X shared library/executable file handling :-)
to get some naghty little edge cases tweaked up.  He's also been
merging over from the FSF quite frequently and trying to spank
out unnecessary divergence between the Apple and FSF gdb sources.

Well anyway, I happened have this all on the tip of my tongue so
I thought I'd dash off a note.  Having just cleaned up all the
gdb.mi test cases, I'm also happy to talk about all the things
we've changed in MI while making it work for Project Builder over
the past few years.  

Wait, here's one good one - would you believe our varobj's can
track when they've gone out of scope?  Man it's cool!  If you're
at a function like this:

void foo (void) {
  int a;
  char b;
  {
     int d;
     float f;
  }
}

When you stop at the top of foo and create objects for all the
locals, gdb will return 4 varobj's, with the last two ("d" and "f")
marked as in_scope="false".  The UI can then display all the
variables for the function and mark those not yet visible as "out
of scope" or greyed out.  When you step into the inner block, those
variables are updated to in_scope="true" and we can display their
values.


You can see all this and more -- much more! -- via our public anoncvs
server:
	http://developer.apple.com/darwin/tools/cvs/
(free reg required, blah blah, yes we know, Apple is evil, etc etc)

J

Re: A few things we've been up to at Apple lately

[Andrew Cagney]

> Klee and I have been going over the testsuite on our platform for
> the past couple months.  Over time, our gdb had diverged from the
> FSF gdb to the point where we had ~800 failures and a couple hundred
> unresolved test cases -- the testsuite was useless for us.  We've
> been fixing testcases to match our output where we've purposely
> diverged from the FSF style; fixing our code to behave correctly;
> and filing Apple internal bug reports for all the known failures.
> We're down to 15-20 unfiled fails now, and many of those are known
> failures in the generic code.

Do you know about KFAIL?
(Thanks for the update).

Andrew

Re: A few things we've been up to at Apple lately

[Klee Dienes]

You can also get a slightly out-of-date snapshot from:

	http://www.opensource.apple.com/projects/darwin/6.0/projects.html	 
http://www.opensource.apple.com/projects/darwin/6.0/source/other/gdb- 
20020918.tar.gz

without any evil click-to-agree business; I'll ask the guy who  
maintains that page to bring the sources up-to-date on Monday.

As far as I know, the only reason for the "click to agree" for live CVS  
access to GDB sources is because that's how the whole CVS repository is  
set up, and the CVS maintainer has never gotten the spare cycles to set  
up a separate server with separate access policy for the non-APSL  
sources.

On Saturday, November 9, 2002, at 04:49 AM, Jason Molenda wrote:
> You can see all this and more -- much more! -- via our public anoncvs
> server:
> 	http://developer.apple.com/darwin/tools/cvs/
> (free reg required, blah blah, yes we know, Apple is evil, etc etc)

Re: A few things we've been up to at Apple lately

[Jason Molenda]

On Sat, Nov 09, 2002 at 09:06:21AM -0500, Andrew Cagney wrote:

> > diverged from the FSF style; fixing our code to behave correctly;
> > and filing Apple internal bug reports for all the known failures.
> > We're down to 15-20 unfiled fails now, and many of those are known
> > failures in the generic code.
> 
> Do you know about KFAIL?
> (Thanks for the update).

Yeah, I saw some a mention of that as I was setting everything up.
What do you think about accepting KFAIL patch submissions
*-apple-darwin* with references to an internal-only-to-Apple bug
database?  Here's what we've done so far:

For my first cut, I was adding bug report #'s right into the test
case name -- it made it easy to grep for and fix when we close the
bug reports.  Personally, I wanted to see the test failures in my
make check output even though they were known fails so I wouldn't
forget them. :-)  

Klee had a different take on the matter.  (1) he didn't want unnecessary
changes to the testsuite, which inevitably cause merge headaches.  (2)
he didn't want to see known failures that have bugs filed--he wants it to
be easy to see if there are new, unknown problems.  (akin to the KFAIL
behavior)

He added some functionality to dejagnu so that our
dejagnu/baseboards/macosx.exp file contains a list of tests that
are known to fail on our system, e.g.

# 3061801 - gdb doesn't deliver signals to inferior proccess
setup_site_fail "gdb.base/annota1.exp" "*" "send SIGUSR1 (r. 3061801)" "3061801"

# 3049981 - unable to pass structs containing chars to functions called from gdbsetup_site_fail "gdb.base/call-rt-st.exp" "powerpc-apple-darwin*" "print print_three_chars(*three_char) (r. 3049981)" "3049981"

He added a --site command line option to runtest where he can
specify types of setup_site failures to suppress -- xfails, kfails,
or fails, and any testsuite failure that's listed in macosx.exp
will be suppressed in the make check output.

Well anyway, it's an interesting different take on the problem.  If
we could get setup_kfail's added to the FSF sources, I we'd go for
that.  The only minor nit I see with kfail as it's implemented right
now is that it prints "(PRMS: 3061801)" which could potentially confuse
someone into thinking these bug reports are in the gdb PRMS database
somewhere..

J

Re: A few things we've been up to at Apple lately

[Daniel Jacobowitz]

On Sat, Nov 09, 2002 at 12:12:02PM -0800, Jason Molenda wrote:
> Well anyway, it's an interesting different take on the problem.  If
> we could get setup_kfail's added to the FSF sources, I we'd go for
> that.  The only minor nit I see with kfail as it's implemented right
> now is that it prints "(PRMS: 3061801)" which could potentially confuse
> someone into thinking these bug reports are in the gdb PRMS database
> somewhere..

FYI, it is now.  It's in DejaGNU 1.4.3.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: A few things we've been up to at Apple lately

[Jason Molenda]

On Sat, Nov 09, 2002 at 05:47:42PM -0500, Daniel Jacobowitz wrote:
> On Sat, Nov 09, 2002 at 12:12:02PM -0800, Jason Molenda wrote:
> > Well anyway, it's an interesting different take on the problem.  If
> > we could get setup_kfail's added to the FSF sources, 

> FYI, it is now.  It's in DejaGNU 1.4.3.


Sorry, not clear.  I meant that if we could add Apple specific
setup_kfail entries to the generic FSF gdb sources, I'd be happy
to do that.  The obvious retort, 'Well file PRs about the failures
in gdb's PRMS db' doesn't work well - our whole workflow at Apple
is built around our internal bug database.  The best we could do
is duplicate the bug reports in both databases and try to keep them
synchronized by hand - and I'd be the first person to say the nay-no
to that idea. :-)

J