Difference between revisions of "DSDP/DD/Face-to-face Toronto 9-10-Jan-2007"

Revision as of 17:04, 9 January 2007

Location and Dates

• Location: IBM Software Lab – Toronto (see logistics below)
• Tues 9-Jan-07: 0900 – 1700
• Wed 10-Jan-07: 0900 – 1500 (approx)

Agenda (under construction)

• Update on Flex hierarchy changes in M4.
• Update on DSF architecture and GDB/mi implementation.
• Update on Memory group.
• Update on pin/clone.
• DSDP/Debug Roadmap
• Introduction to IP-XACT editor:
  • Demonstration
  • Architectural overview
• Coding camp for DSF.

Attendees

Open to all. Please add your name to the list.

• John Cortell, Freescale
• Steve Furr, Freescale
• Ted Williams, Wind River
• Doug Gaff, Wind River
• Randy Rohrbach, Wind River
• Fran Litterio, Wind River (remotely)
• Pawel Piech, Wind River
• Darin Wright, IBM
• Doug Schaefer, QNX
• Chris Recoskie, IBM
• Dominique Toupin, Ericsson / R&D PM&T
• Veenu Verma, Ericsson / TSP
• Francois Chouinard, Ericsson / TSP
• Martin Gunnesson, Ericsson / CPP DTE
• Alf Larsson, Ericsson / CPP DTE
• Magnus Ohlin, Ericsson / EMP
• Rune Hylsberg Jacobsen, Ericsson / IS
• Mark Melvin, AMI Semiconductor
• Todd Lee, AMI Semiconductor
• Ken Dyck, AMI Semiconductor
• Vivian Kong, IBM
• Jason Montojo, IBM
• Mike Kucera, IBM
• Samantha Chan, IBM
• Alan Boxall, IBM
• Pete Nicholls, IBM
• Mikhail Khodjaiants, ARM (remotely)
• Anthony Berent, ARM
• Ewa Matejska, PalmSource
• Paul Gingrich, TI
• Martin Swiezawski, TI
• Patrick Chuong, TI
• Dobrin Alexiev, TI
• Baltasar Belyavsky, TI

Logistics

• Area hotels: (the Hilton is about a 2 minute walk)
  • Hilton Suites Hotel & Conference Centre Toronto/Markham (formerly Embassy Suites)
    8500 Warden Avenue
    Markham, Ontario
    Phone: 905 470-8500
    http://www.hilton.com/en/hi/hotels/index.jhtml;jsessionid=4KXATC2AU1HHJJ31AOQMISQ?ctyhocn=YYZAPHF
    Distance to 8200 Warden: 0.5 km
  • Radisson Hotel Toronto-Markham
    50 East Valhalla Drive
    Markham, Ontario
    Phone: 905 477-2010
    Distance to 8200 Warden: 3 km
  • Holiday Inn Hotel & Suites Markham
    7095 Woodbine Ave.
    Markham, Ontario
    Phone: 905 474-0444
    Distance to 8200 Warden: 5 km
    

• Face-to-Face Location
  • IBM Software Lab
    8200 Warden Ave, Markham, ON L6G 1A1
    CANADA
    http://maps.google.ca/maps?f=q&hl=en&q=8200+Warden+Avenue,+Markham,+Canada&ie=UTF8&z=14&ll=43.856997,-79.321032&spn=0.022528,0.08214&om=1&iwloc=addr

• Driving Directions from Airport:
  • The lab is just off Warden Ave between Highway 407 and Highway 7 in Markham.
  • To 8200 using the 407 Express Toll Route*:
    When exiting the airport follow the signs for Highway 427 North. Drive north on Highway 427 and exit on to Highway 407 ETR East. Follow Highway 407 ETR east for 28 km to the Warden Ave exit. Turn left (north) at the Warden Ave exit stop light. Go north on Warden Ave and prepare to exit right on to the IBM overpass which will take you into the Lab.
    *Please advise the auto rental agency before taking the 407 ETR . The toll (approx. $6.00 CDN one way + possible auto rental agency administration fees) will be billed to your credit card.
  • To 8200 using Highway 401:
    When exiting the airport follow the signs for Highway 401 East. Drive east on Highway 401 for 27 Kilometres to the Don Valley Parkway/404 exit. Go north (towards Newmarket) on the 404 and exit at Hwy 7. Proceed east on Hwy 7 to South Town Centre Blvd (South Town Centre Blvd is east of Rodick Rd and west of Warden Ave). Turn right (south) on South Town Centre Blvd Follow this road straight into the Lab.

Opening Statement (Doug Gaff, Wind River Systems)

• 32 participants present, 2(?) dialed in
• Doug Gaff introduced himself and thanked the group for attending.
• The group went around the room introducing ourselves.
• First face to face in about one year.
• Technical topics first day, project status second day.
• Anthony Berent is working on an parser contributions, but was unable to make the meeting. Doug G anticipates an update soon.

Flexible Hierarchy update (Darin Wright, IBM Rational Software)

[ TODO link to Darin's slides about Flexible Hierarchy]

• Views
  • APIs were provisional in 3.2. There was a plan to make these APIs "public" in 3.3. There has been progress, but many are still marked as experimental.
    • How many have been using the new APIs? Two hands.
  • Question: Coalescing delay? Darin thinks the user will see blank, empty space as the user scrolls faster than the data can populate.
• JFace viewers don't support filtering/sorting when in virtual mode.
  • • To continue existing filter support, elements will be requested to fill the viewport. If some of these elements are filtered out, additional requests will load more data until the viewport is filled. This will cause the scroll bar to recalculate the maximum as the user scrolls.
    • If you want a stable UI, put the filter in the model.
• Debug Commands & Handlers
  • new to 3.3, events are fired for context selection
  • interfaces moved from debug ui to core plugin
• Other Enhancements
  • Mixed mode launching (profile & debug at same time, for example)
  • Multiple launches for the same configuration type & mode
  • contribute tabs to existing launch configuration tab groups
  • context sensitive launching (run as, debug as selection sensitive)
  • pluggable detail panes, was just text, now extension point allows for any SWT control, thin, lightweight. support for more than one detail pane for a given selection.
• Darin will talk about these topics in more detail at his eclipsecon tutorial.

View Model (Pawel Piech, Wind River Systems)

[ TODO link to Debugger Services Framework View Model slides ]

• common pattern identified as a potentially useful contribution
• Pawel demonstrated the "Timers" DSF view model example

Pin & Clone (Pawel Piech, Wind River Systems)

• Prototype implementation has been posted to bugzilla. [ TODO link ]
• Pawel gave a demo using JDT. These changes do not require DSF. The enhancement is to the platform.
• One can pin to a specific context OR provider. Historically, the debug view has been the only provider. In the future, the user might pin a variables view to the Target Manager instead of the debug view.
• Persistence is not yet stated saved between sessions
• Tooltip indication of pin status requires hovering. Pete, Doug G and others believe colored indication is necessary. Darin believes there should be stability of the toolbar. Changing the text could cause the toolbar to reshuffle. He believes a more standard workbench metaphor would include changing of the tab color.
• Do people feel that this is valuable enough as is?
  • Chris R: Even if it has issues, it's better than what we have now, which is nothing.
  • Pawel: The command service APIs are set to become public/final in this release. This patch requires changes. There is some urgency.
• Open issue: different use cases. Hopefully there aren't any more API changes required, but until we are firm on workflow, it's hard to know.
• Can this be committed in 3.3?

Debugger Services Framework (Pawel Piech, Wind River Systems)

[ TODO link to DSF slides ]

• Repeat of presentation given at the CDT conference.
• Why create another debug model, compare/constrast with CDI, features of the framework, migration options, future plans.
• Doug S: A lot of companies have embedded debuggers based on CDT. What do people in this category want to get out of DSF?
  • Multi-core
  • True OCD/hardware debugging
  • Ability to plug in additional components in a supported and standard way.
  • Explicit goal should be to get people using DSF. It's critical for the survival of the project.
  • Ability to access the data model for non-UI purposes.
• Discussion about CDI vs DSF. DSF is more complicated for the simple cases. CDI has had more iterations and testing and benefits from greater maturity. For embedded, remote and other high latency debug use cases, the complexity associated with asynchronous models (DSF) is justified by the performance gains.
• 0.9 release with complete and stable service interfaces.
  • Continued development on the GDB-MI implementation.
  • Wind River plans to use DSF for their next commercial release, but without feedback from the community, the interfaces and model might not fit the needs of the community.

State of the Project (Doug Gaff)

[ TODO Doug's slides about DD history and progress starting with the BOF pre-DSDP/DD ]

• Good things: memory view, DSF, spirit working group, terminal (went into TM project)
• Some progress: Registers, Breakpoints, Editor/Disassembly, Console, Pin/Clone
• Stagnant: Debug view, Source lookup, Launch
• Attendance has been very exciting. We had hoped that there would be similar interest over development participation.
• When we started off, we believed there would be more early collaboration. We've heard from many that commercial work not left sufficient time for DD open source development.
• Wind plans to adopt DSF commercially in 2007. We might not be able to staff continued development on the GDB-MI DSF reference implementation.
• Open discussion
  • Darin: Does DD have any backward compatibility requirement? Doug G: No, because it is experimental.
  • TI: We don't know if we need DSF, yet. Same feature set, no benefit to switch other than testing new framework. Backend is synchronous. We would like fast stepping and performance is an issue. Multicore as well. Testing the waters at this point. Wait and see. SPIRIT is a large decision requiring the agreement of multiple groups. No interest in GDB implementation. CDI not required, but it would be a plus (less code to rewrite). TI does get value out of the debug discussions. After product is release, there might be resources available.
  • Freescale: Us, too. We need DSF. We need multicore. CDT is weak for multicore. Same issues with SPIRIT. GDB implementation not required. CDI compatibility not required. Will use CDI/CDT until a migration is complete. These discussions are useful.
  • AMI: No resources to investigate the use of DSF. Faces same issues as Wind. It would be a big architectural change, not a minor API change. Beyond an eclipse.org style "hello world", not enough resources to try it out. Based on the current state, where can one begin? Unsure of plans for SPIRIT. GDB-MI and CDI/CDT not used. Good at filing bugs against platform. Has used flexible hierarchy. Discussions useful. Interested in Terminal/Console. Company is huge, but software team feels small. Would probably use DSF if starting today. Difficult to evaluate without reference design.
  • IBM (Pete): DSF no, SPIRIT no, GDB-MI no, CDI/CDT maybe, values discussions. Some IDEs may use CDT in the future. Has not really looked into flexible hierarchy, but expects to use it heavily within the next six months. How many interested in launch proposal? If not, we'll end up with an IBM design.
  • IBM (Chris): DSF might possible become more interesting depending what happens with Doug S's windows debugger. Discussions always useful, even if not directly working on discussed topics at the moment.
  • PalmSource (Ewa): Using CDT and whatever CDT decides to use. Performance is important. Driving CDT toward improvements in performance is useful. Discussions are useful. Not planning to use SPIRIT.
  • Ericson: Multicore useful, SPIRIT not really, GDB yes, CDI compatibility not important. Good debugging based on DSF would be fine. First meeting.
  • QNX (Doug S): CDI/CDT already meets needs. It'll be hard to get resources to work on DSF. GDB-MI based, would be important if there were a move to DSF. Windows debugger will be MI based. DSF could be tested/evaluated for this task.
  • ARM (Anthony): DSF is a good fit for architectures used in debuggers, but unfortunately the whole debugger is written in C++. If and when product moves to java/eclipse, DSF will be a good fit. SPIRIT already used in products. No interest in GDB-MI or CDI. Discussions valuable.
  • ARM (Mikhail): Not going to use DSF, will improve CDI. Liked DSF from the whitepaper, but found code difficult. Hasn't looked at it in a long time. Will be using SPIRIT. GDB-MI used today.
  • Nokia (Ken): Needs DSF, DSF features, would like to have looked at it more seriously six months ago, started picking it up again last week. Would like to see DSF integrated into CDT. The rest of their product will continue to use CDT features. Will likely use SPIRIT eventually. Would like to see GDB-MI reference implementation for the purpose of better understanding how things work (not to actually use as a base, no commercial purposes). CDI compatibility is confusing and not required. Accepts that connecting backend to DSF will require writing code. Finds a lot of value in debug discussions. Would like to export work done on CDT breakpoints to DSF.
• Darin: Has anyone evaluated Netbeans as a platform for building tools?
  • No hands.

Memory subgroup (Samantha Chan)