1 / 34

How Debuggers Work

How Debuggers Work. Karl Rehmer. Failures Come in Flavors Michael Nygard. REST in Java Stefan Tilkov. EJB 3.1 vs Contexts and Dependency Injection (CDI) and Dependency Injection for Java in Java EE 6 Jacek Laskowski. How Debuggers Work. Dr. Karl Rehmer rehmerk@acm.org.

rainesv
Download Presentation

How Debuggers Work

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How Debuggers Work Karl Rehmer Failures Come in Flavors Michael Nygard REST in Java Stefan Tilkov EJB 3.1 vs Contexts and Dependency Injection (CDI) and Dependency Injection for Java in Java EE 6 Jacek Laskowski

  2. How Debuggers Work Dr. Karl Rehmer rehmerk@acm.org

  3. What is in this talk • Overview of debugger for embedded system • Story of debugger development • Architectural structure and motivation • How is a Java debugger different?

  4. What is a Debugger • A tool to remove bugs from a program • Used in program testing/inspection • Used to test a module or algorithm

  5. Current State of the Art • GUI debugger that may be part of a larger development environment • Many windows each of which supports different aspects of debugging • Should have a non-GUI, script-driven mode for batch testing

  6. Basic Principles • Debugging a program affects the program • Debugger is present an running • On cross systems this often means a debug monitor is running on the target • On cross systems, the debugger may be “in control” of the target. It controls interrupts, I/O, etc. • On native systems, the program is sharing resources with the debugger • Stopping a program affects timing.

  7. Basic Principles • Debuggers should be truthful • Sounds simple, but can be very difficult, especially when compiler optimizations are involved. • Examples: • Code motion • Variable sometimes in register, sometimes in memory (sometimes in cache)

  8. Basic Principles • Context is important • When stopped, show associated source code • Provide ability to see call stack • Provide tracing mechanism (source and machine level) • When multiple threads are involved, provide information on the state of the threads.

  9. Basic Debugger Division Target Debug Monitor In control of the target When program being debugged stops, control is given to the debug monitor Host debugger Provides user interface Provides lookup of debug information Communicates with target

  10. Basic Requirements for Debug Monitor • Set and delete breakpoints • Software breakpoints • Hardware breakpoints • Single step one machine instruction • Read and write memory • Read and write registers

  11. Debug Monitor Functionality • Software breakpoint • Usually write some specific instruction in memory. Attempt to execute causes a trap. Trap handler gives control to D.M. • Hardware breakpoint • Write an address in one of a number of special registers. When the instruction about to be executed is at an address in one of these registers, a Trap occurs.

  12. Debug Monitor Functionality • When trap occurs, D.M. must save context of program, so that its use of resources does not corrupt program. Probably needs to flush any data cache, invalidate instruction cache. • Now can read/write any memory. Read/write registers by manipulating the saved context.

  13. JTAG Debugging Target Program in control – no debug monitor present Host debugger Provides user interface Provides lookup of debug information Communicates with target JTAG Probe

  14. JTAG Probe • Provides direct access to the registers and memory of the target through the hardware. May be “smart enough” to know about cache. • Using JTAG means program being debugged runs more normally – no debug monitor.

  15. Host Debugger Components Utilities Expression Evaluation Debug Info Context Run Time Seq. Interface UICC Debugger Functions Target T.I.P. Msg. Breakpoints Execution Control Symbol Table Host-Target Protocol Debugger Types

  16. Setting Breakpoints • Find the address or addresses at which to set the breakpoint. • Breakpoint Handler keeps track of breakpoints (inc. conditions, associated commands, etc.) • Read memory at breakpoint address and save contents. • Write breakpoint instruction to address

  17. Evaluating an Expression • Find appropriate debug information for current context. • For each variable, look up. • Determine location, type info (for structs, this means finding offsets of each component) • Read appropriate location (reg or mem) from target. Create appropriate “object” • Perform appropriate operations on objects • Format and display result

  18. Modifying a Variable • As with expression, get context, find variable, get its “shape” and location. • If the location is not constant, create an appropriate “memory image” for the variable • Write the memory (or register) on the target.

  19. Showing Machine Code • Read a “chunk” of memory containing the address at which disassembly is to take place. • Invoke disassembler part of target subsystem. • For variable length instruction architectures, interesting problem to determine if address given is actual start of an instruction

  20. Showing a Call Stack • Need to determine return address for a call • Can use debug information that tells where to find the return address • Can use architecture knowledge of how generated code is supposed to behave (if there is a standard).

  21. Variable in a Caller • Need to determine caller context to find variable, location, and “shape” • Location may be modified by subsequent call • If in register, register may have been saved somewhere • If on stack, location may be relative to a “frame pointer”. What has subsequent frame done to the frame pointer?

  22. Continuing from a Breakpoint • If you continue from address, you will just trap again • Get saved instruction for that address. • Write that instruction to memory • Do a machine singlestep away from the break location. • Write the breakpoint instruction back.

  23. Machine Code SingleStep • Most modern architectures have a processor mode where continuing execution will cause a trap after one machine instruction is executed. • Machine step from a breakpoint involves writing back instruction, stepping, writing back break instruction.

  24. Source Code SingleStep • Find all locations where the execution can go next. (involves consulting debug information) • Set a temporary breakpoint at address for each location. • Go • Delete the temporary breakpoints • Report step completed

  25. Other interesting actions • Machine code tracing • Source code tracing • Breakpoints with conditions • Parameters for a procedure or function • Watching a set of registers • Watching a number of expressions • Watching memory

  26. Other interesting actions • Data access breakpoints • Debugging code in ROM • Supporting multiple languages

  27. Java Debugging • Much different • No addresses • No machine code • Use Java Debug Wire Protocol (JDWP) • Or Java Debug Interface (JDI)

  28. JDWP • Is a protocol to communicate between a debugger and the Java Virtual Machine (JVM) • Optional support in a JVM • Details format and layout of messages • Does not detail transport mechanism • The JVM may support various transport mechanisms (sockets, serial, …)

  29. JDWP • Three kinds of packet • Handshake • Command (from either debugger or JVM) • Examples: Ask for notification of an event (debugger to JVM) or notification of an event (JVM to debugger) • Response (response to a command) • Sometimes just success or fail status • Often contains data • Commands from JVM to debugger do not require response

  30. JDWP • Headers of messages are standard • Format is flexible • Different JVM may use different sizes for parts of messages. • Debugger must ask what these sizes are • Object ID, Reference ID Type, Field ID, … • There is a command message to ask this

  31. JDWP Some Kinds of Command • Reference Type Commands • Fields, Methods, Values, Source File of a type • Class Type Commands • Superclass, Set Values, Invoke Method • Method Commands • Line table, Variable Table

  32. JDWP Some Kinds of Command • Object Reference Commands • Reference type, Get Values, Set Values (note a value is often an object ID), Invoke Method • Thread Reference Commands • Suspend, Resume, Frames • Event Request Commands • Set, Clear, Clear All Breakpoints • Many kinds of event (i.e. breakpoint, single step, class loaded)

  33. JDWP Some Kinds of Command • Stack Frame Commands • Get Values, Set Values, This Object • Event Commands • Report that one or more events have happened

  34. How to solve unsolvable problems in projects Marcin Kokott, Martin Chmelar The Future of the Java Platform: Java SE 7 and Java SE 8 Simon Ritter Using Spring with non relational databases CostinLeau Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw. (Polish) Sławomir Sobótka

More Related