This size is primarily for ARM and Thumb breakpoints. The NativeProcessProtocol and NativeThreadProtocol protocol will be "I will do exactly what you tell me" and they shouldn't need to know how to dig through the object files to find the CPU map that shows exactly which addresses are ARM and which are Thumb. Sending the size field of 2 (for Thumb) and 4 (for ARM) helps the protocol to do its job. Most architectures will only have 1 size that is used (1 byte for x86 and x86_64 and 4 for PowerPC, etc). So this can mostly be ignored for non ARM targets.
In debugserver, the Z packets that set the breakpoints specify the size. Greg On Mar 24, 2014, at 10:33 AM, Todd Fiala <[email protected]> wrote: > Hey Greg, > > For this method in NativeProcessProtocol: > > virtual Error > SetBreakpoint (lldb::addr_t addr, size_t size, bool hardware); > > What exactly is the size meant to represent? > > Also, is this method meant to be able to succeed if the breakpoint address > isn't yet loaded, or should it fail if the address isn't loaded yet and > assume that the caller would be watching for module load events and handle > buffering breakpoints until the address is available? > > Can you point me to where debugserver implements the equivalent? > > Thanks! > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
