Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>,
	       gdb-patches@sourceware.org
Subject: Re: [PATCH v2 4/7] Support breakpoint kinds for software breakpoints in GDBServer.
Date: Fri, 16 Oct 2015 16:06:00 -0000	[thread overview]
Message-ID: <56212081.5090703@redhat.com> (raw)
In-Reply-To: <561FEA3A.5020801@ericsson.com>

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


  reply	other threads:[~2015-10-16 16:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-05 16:44 [PATCH v2 0/7] Software breakpoints support for ARM linux " Antoine Tremblay
2015-10-05 16:44 ` [PATCH v2 2/7] Add breakpoint_from_kind target_ops for software breakpoints " Antoine Tremblay
2015-10-15  9:04   ` Yao Qi
2015-10-15 10:50     ` Antoine Tremblay
2015-10-15  9:10   ` Yao Qi
2015-10-15 10:37     ` Antoine Tremblay
2015-10-15 15:34   ` Pedro Alves
2015-10-15 17:07     ` Antoine Tremblay
2015-10-05 16:44 ` [PATCH v2 4/7] Support breakpoint kinds " Antoine Tremblay
2015-10-15 15:51   ` Pedro Alves
2015-10-15 18:02     ` Antoine Tremblay
2015-10-16 16:06       ` Pedro Alves [this message]
2015-10-16 18:08         ` Antoine Tremblay
2015-10-16 19:04           ` Pedro Alves
2015-10-16 19:23             ` Antoine Tremblay
2015-10-16 19:44               ` Antoine Tremblay
2015-10-16 19:48                 ` Antoine Tremblay
2015-10-19  9:35                 ` Pedro Alves
2015-10-19 11:48                   ` Antoine Tremblay
2015-10-05 16:44 ` [PATCH v2 3/7] Implement breakpoint_from_kind for supported architectures " Antoine Tremblay
2015-10-15  9:19   ` Yao Qi
2015-10-15 10:57     ` Antoine Tremblay
2015-10-15 17:13       ` Antoine Tremblay
2015-10-05 16:44 ` [PATCH v2 6/7] Refactor the breakpoint definitions in linux-arm-low.c Antoine Tremblay
2015-10-15 16:07   ` Pedro Alves
2015-10-16 12:14     ` Yao Qi
2015-10-05 16:44 ` [PATCH v2 1/7] Add breakpoint_from_pc target_ops for software breakpoints in GDBServer Antoine Tremblay
2015-10-15  8:27   ` Yao Qi
2015-10-15 15:33   ` Pedro Alves
2015-10-15 15:58     ` Antoine Tremblay
2015-10-15 17:05       ` Antoine Tremblay
2015-10-05 16:44 ` [PATCH v2 7/7] Support software breakpoints for ARM linux " Antoine Tremblay
2015-10-05 17:00   ` Eli Zaretskii
2015-10-15 16:07   ` Pedro Alves
2015-10-15 18:24     ` Antoine Tremblay
2015-10-15 18:33       ` Pedro Alves
2015-10-15 18:59         ` Antoine Tremblay
2015-10-16  9:33     ` Yao Qi
2015-10-16 12:11       ` Pedro Alves
2015-10-16 12:24   ` Yao Qi
2015-10-16 12:21     ` Yao Qi
2015-10-05 16:44 ` [PATCH v2 5/7] Implement breakpoint_from_pc for ARM " Antoine Tremblay
2015-10-15 16:07   ` Pedro Alves
2015-10-15 18:06     ` Antoine Tremblay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56212081.5090703@redhat.com \
    --to=palves@redhat.com \
    --cc=antoine.tremblay@ericsson.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox