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 v2 4/7] Support breakpoint kinds for software breakpoints in GDBServer.


On 10/15/2015 07:02 PM, Antoine Tremblay wrote:
> 
> 
> On 10/15/2015 11:51 AM, Pedro Alves wrote:
>> On 10/05/2015 05:44 PM, Antoine Tremblay wrote:
>>> This patch teaches GDBServer to:
>>>
>>>   - choose the right breakpoint instruction for its own breakpoints, through API
>>>     set_breakpoint_at.
>>>
>>>   - choose the right breakpoint instruction for breakpoints requested by GDB,
>>>    according to the information in Z packets, through API set_gdb_breakpoint.
>>>
>>> New fields are introduced in struct raw_breakpoint:
>>>
>>> pcfull: The PC including possible arch specific flags encoded in it.
>>
>> "full" as opposed to "empty"?  Can we find a clearer term?
>>
> 
> full as opposed to incomplete, meaning it includes all it could include. 
> Other then that I would see :
> 
> pcencoded ?
> 
> pcflaged ?
> 
> pcwithflags ?
> 
> Not an easy one..

GDB calls them "placed address" and "requested address":

struct bp_target_info
{
...
  /* Address at which the breakpoint was placed.  This is normally
     the same as REQUESTED_ADDRESS, except when adjustment happens in
     gdbarch_breakpoint_from_pc.  The most common form of adjustment
     is stripping an alternate ISA marker from the PC which is used
     to determine the type of breakpoint to insert.  */
  CORE_ADDR placed_address;

  /* Address at which the breakpoint was requested.  */
  CORE_ADDR reqstd_address;


> 
>>> @@ -100,6 +98,16 @@ struct raw_breakpoint
>>>        breakpoint for a given PC.  */
>>>     CORE_ADDR pc;
>>>
>>> +  /* The breakpoint's insertion address, possibly with flags encoded in the pc
>>> +     (e.g. the instruction mode on ARM).  */
>>> +  CORE_ADDR pcfull;
>>> +
>>> +  /* The breakpoint's data */
>>> +  const unsigned char *data;
>>> +
>>> +  /* The breakpoint's kind.  */
>>> +  int kind;
>>> +
>>>     /* The breakpoint's size.  */
>>>     int size;
>>
>> Can't we always find the size from pcfull and kind ?
>>
> 
> We could but then we would have to call breakpoint_from_kind in a lot of 
> places basically everywhere bp->size is referenced like :
> 
> check_mem_read
> check_mem_write
> insert_memory_breakpoint
> remove_memory_breakpoint
> set_raw_breakpoint_at
> validate_inserted_breakpoint
> delete_raw_breakpoint
> uninsert_raw_breakpoint
> reinsert_raw_breakpoint
> find_raw_breakpoint_at

See below.

> 
> Also since these functions can be called in a stack one would have to be 
> careful to call breakpoint_from_kind at the right level and pass it 
> down.. and then size/kind becomes confusing.
> 
> Also, this is a bit what I did in v1 but changed based on discussions 
> with Yao see :
> 
> https://sourceware.org/ml/gdb-patches/2015-09/msg00597.html
> 
> I think it's more clear to call the function once and set the variable.

I don't see why my comment conflicts with Yao's.  But I think we
could simplify the interfaces and entry points, and get rid of the
duplication, like this:

Replace the breakpoint_from_pc method with a breakpoint_kind_from_pc
method.  This adjusts the PC (if necessary) and returns the
breakpoint _kind_ instead of the breakpoint opcode / data.

enum arm_breakpoint_kinds
{
   ARM_BP_KIND_THUMB = 2,
   ARM_BP_KIND_THUMB2 = 3,
   ARM_BP_KIND_ARM = 4,
};

static int
arm_breakpoint_kind_from_pc (CORE_ADDR *pcptr, int len)
{
  if (IS_THUMB_ADDR (*pcptr))
    {
      gdb_byte buf[2];

      *pcptr = UNMAKE_THUMB_ADDR (*pcptr);

      /* Check whether we are replacing a thumb2 32-bit instruction.  */
      if ((*the_target->read_memory) (*pcptr, buf, 2) == 0)
	{
	  unsigned short inst1 = 0;

	  (*the_target->read_memory) (*pcptr, (gdb_byte *) &inst1, 2);
	  if (thumb_insn_size (inst1) == 4)
            return ARM_BP_KIND_THUMB2;
	}

      return ARM_BP_KIND_THUMB;
    }
  else
    return ARM_BP_KIND_ARM;
}

Then the breakpoints functions and structures always work
with the already-adjusted PC, and with a breakpoint-kind.

for internal breakpoints, we have:

  set_breakpoint_at (breakpoint_kind_from_pc, to find bp kind,
                     rest the same as today)
  set_gdb_breakpoint_1 (same as today)
     |
     `--> set_breakpoint (address, kind)
             |
             `-->set_raw_breakpoint_at (address, kind)
                    |
                    `--> the_target->insert_point (address, kind)

Everything thinks in terms of breakpoint kind.  Then the only
places that need to know the real breakpoint instruction opcode
and opcode size can query the breakpoint_from_kind target method
you already added.

About:

> We could but then we would have to call breakpoint_from_kind in a lot of
> places basically everywhere bp->size is referenced like :
>
> check_mem_read
> check_mem_write
> insert_memory_breakpoint
> remove_memory_breakpoint
> set_raw_breakpoint_at
> validate_inserted_breakpoint
> delete_raw_breakpoint
> uninsert_raw_breakpoint
> reinsert_raw_breakpoint
> find_raw_breakpoint_at

Minimizing the patch size is less important than making sure the
resulting code is clear

Sounds like that's manageable with a trivial replace of bp->size
with a call to something like:

static int
bp_size (struct raw_breakpoint *bp)
{
   int size = bp->kind;

   breakpoint_from_kind (&size);
   return size;
}

Likewise for the opcode data:

static const gdb_byte *
bp_opcode (struct raw_breakpoint *bp)
{
   int size = bp->kind;

   return breakpoint_from_kind (&size);
}

Doesn't seem to me like the end result would be any less clear.

Thanks,
Pedro Alves


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