This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: read target register to decide breakpoint size
- From: Tim Newsome <tim at sifive dot com>
- To: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- Cc: gdb <gdb at sourceware dot org>
- Date: Tue, 13 Dec 2016 12:58:26 -0800
- Subject: Re: read target register to decide breakpoint size
- Authentication-results: sourceware.org; auth=none
- References: <CAGDihemd3g3_ropX=Y-wWSeyWBbH-sCA6FDX2FaTwKP8e-3Nng@mail.gmail.com> <wwok1sy4zt6d.fsf@ericsson.com> <CAGDihe=cyG646+D1POAaBSiWYAxH_ap+C0j=+hxVBdZq1N0LBA@mail.gmail.com>
I finally got around to implementing this, but gdb still insists on
calling breakpoint_kind_from_pc, where I don't have access to a
regcache object (I think). Eg.
```
#0 riscv_breakpoint_kind_from_pc (gdbarch=0xcc8a90,
pcptr=0x7fffffffde68) at riscv-tdep.c:184
#1 0x0000000000541301 in default_breakpoint_from_pc
(gdbarch=0xcc8a90, pcptr=<optimized out>, lenptr=0x7fffffffde64)
at arch-utils.c:847
#2 0x00000000004b40b3 in program_breakpoint_here_p
(gdbarch=<optimized out>, address=2147550320) at breakpoint.c:9113
#3 0x00000000004b424c in bp_loc_is_permanent (loc=0xdd57b0) at
breakpoint.c:9156
#4 add_location_to_breakpoint (b=b@entry=0xda9aa0,
sal=sal@entry=0x7fffffffdf70) at breakpoint.c:9093
#5 0x00000000004b5169 in init_raw_breakpoint (ops=0xb4d200
<bkpt_breakpoint_ops>, bptype=bp_breakpoint, sal=...,
gdbarch=0xcc8a90, b=0xda9aa0) at breakpoint.c:7586
#6 init_breakpoint_sal (b=b@entry=0xda9aa0,
gdbarch=gdbarch@entry=0xcc8a90, location=location@entry=0xda8f30,
filter=filter@entry=0x0, cond_string=0x0, extra_string=0x0,
type=bp_breakpoint, disposition=disp_donttouch,
thread=-1, task=0, ignore_count=0, ops=0xb4d200
<bkpt_breakpoint_ops>, from_tty=1, enabled=1, flags=0,
display_canonical=0, internal=<optimized out>, sals=...) at
breakpoint.c:9300
#7 0x00000000004bb490 in create_breakpoint_sal (display_canonical=0,
flags=0, internal=0, enabled=1, from_tty=1,
ops=0xb4d200 <bkpt_breakpoint_ops>, ignore_count=0, task=0,
thread=-1, disposition=disp_donttouch,
type=bp_breakpoint, extra_string=0x0, cond_string=0x0, filter=0x0,
location=0xda8f30, gdbarch=0xcc8a90, sals=...)
at breakpoint.c:9436
#8 create_breakpoints_sal (gdbarch=0xcc8a90,
canonical=0x7fffffffe170, cond_string=0x0, extra_string=0x0,
type=bp_breakpoint, disposition=disp_donttouch, thread=-1, task=0,
ignore_count=0,
ops=0xb4d200 <bkpt_breakpoint_ops>, from_tty=1, enabled=1,
internal=0, flags=0) at breakpoint.c:9490
#9 0x00000000004bbbfc in create_breakpoint (gdbarch=0xcc8a90,
location=location@entry=0xda3af0,
cond_string=cond_string@entry=0x0, thread=-1, thread@entry=0,
extra_string=<optimized out>,
extra_string@entry=0xda3ad6 "", parse_extra=parse_extra@entry=1,
tempflag=0, type_wanted=bp_breakpoint,
ignore_count=0, pending_break_support=AUTO_BOOLEAN_AUTO,
ops=0xb4d200 <bkpt_breakpoint_ops>, from_tty=1, enabled=1,
internal=0, flags=0) at breakpoint.c:9912
#10 0x00000000004bc099 in break_command_1 (arg=0xda3ad6 "",
flag=<optimized out>, from_tty=1) at breakpoint.c:10020
...
```
Is there some way I can check the misa register of my target from
default_breakpoint_from_pc, or have gdb not call
default_breakpoint_from_pc and use breakpoint_kind_from_current_state
instead?
Thank you,
Tim
On Mon, Nov 21, 2016 at 10:00 AM, Tim Newsome <tim@sifive.com> wrote:
> Thanks, Antoine! That's exactly what I was looking for.
>
> Tim
>
> On Mon, Nov 21, 2016 at 8:36 AM, Antoine Tremblay
> <antoine.tremblay@ericsson.com> wrote:
>>
>>
>> Tim Newsome writes:
>>
>> > I'm still working on RISC-V support for gdb. Any given RISC-V core may
>> > support a compressed instruction set (2 bytes per instruction as
>> > opposed to 4). There are corresponding 2-byte and 4-byte breakpoint
>> > instructions. On cores that support the compressed instruction set it
>> > is safe to just always use the 2-byte version, and there is a register
>> > I can read to tell me whether the compressed instruction set is
>> > supported. What I would like to do is read (and cache) that register
>> > when breakpoint size is determined. That seems more robust than making
>> > a decision based on ELF info, which may not reflect what is actually
>> > being executed.
>> >
>> > Is that a good idea? Are there examples of operations that read target
>> > registers to complete?
>>
>> Yes actually you can check how ARM does it, it has the same kind of
>> problem with 3 breakpoints you can set for thumb, thumb2 and arm
>> instruction sets.
>>
>> See arm-tdep.c:arm_sw_breakpoint_from_kind and
>> arm_breakpoint_kind_from_current_state
>>
>> This is called in breakpoint.c:breakpoint_kind and it can use a register
>> to make the decision from the current state of that register.
>>
>> So possibly just implementing the sw_breakpoint_from_kind and
>> breakpoint_kind_from_current state would be ok your you.
>>
>> Regards,
>> Antoine Tremblay