From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102451 invoked by alias); 13 Dec 2016 21:30:21 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 102330 invoked by uid 89); 13 Dec 2016 21:30:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:M9OyzkeyLB, H*i:sk:kj5UpgA, H*f:M9OyzkeyLB, H*i:sk:CAGDihe X-HELO: mail-io0-f174.google.com Received: from mail-io0-f174.google.com (HELO mail-io0-f174.google.com) (209.85.223.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Dec 2016 21:30:05 +0000 Received: by mail-io0-f174.google.com with SMTP id h30so6798808iod.2 for ; Tue, 13 Dec 2016 13:30:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9ZhFerHMQdP84RaQ/08WO7k+sjoeZKVmH+0xPjE0Cmc=; b=S8fraQUnBFmFWcwt2MOtFYFtWEevkSeHNI35Yxa/wlXCb4fZabs1Mxeh6vtTZP4rnG T7d8lugs/KQ8hQCdTFkbAKK4/WhgVSwsO4URBS3P+6A5zZQEtG69N3pEvPlDWkljM1Fe YnU1phZpLOCYx1VYvXwgiV3wiUQuvYDvE/bN2hmLeKb2SAdjQ5ymynQzkWTqUcmGcrO7 srnoHFv+xVOHXQV1qm2i7YM4Lqkryrgc1RKCYWoc79nbSH10I/rg37dGFQIAtFwvlWxc 5OmN9IZFHV0UdRGB61Fit4ta8l3sBydN3p6AF/POs2BtCq6EG6fWM3yEQH9SVwrYqhqF eoOw== X-Gm-Message-State: AKaTC02BLbEycOpPslq7fdr9mzlveU9k4COkopGF6+OzxYCPUNUaYl6upkSY/xUv9f0JQNmpnIRKmuyCKoZblg== X-Received: by 10.36.111.208 with SMTP id x199mr4468285itb.52.1481664603374; Tue, 13 Dec 2016 13:30:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.173.17 with HTTP; Tue, 13 Dec 2016 13:30:02 -0800 (PST) In-Reply-To: References: From: Tim Newsome Date: Tue, 13 Dec 2016 21:30:00 -0000 Message-ID: Subject: Re: read target register to decide breakpoint size To: Antoine Tremblay Cc: gdb Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00019.txt.bz2 Actually, this seems to work inside breakpoint_kind_from_pc(): ``` struct frame_info *frame = get_current_frame (); uint32_t misa = get_frame_register_unsigned (frame, RISCV_CSR_MISA_REGNUM); ``` Is that kosher? If so, is there any reason for me to implement breakpoint_kind_from_current_state? Thanks, Tim On Tue, Dec 13, 2016 at 12:58 PM, Tim Newsome wrote: > 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=, lenptr=0x7fffffffde64) > at arch-utils.c:847 > #2 0x00000000004b40b3 in program_breakpoint_here_p > (gdbarch=, 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 > , 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 > , from_tty=1, enabled=1, flags=0, > display_canonical=0, internal=, 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 , 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 , 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=, > 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 , from_tty=1, enabled=1, > internal=0, flags=0) at breakpoint.c:9912 > #10 0x00000000004bc099 in break_command_1 (arg=0xda3ad6 "", > flag=, 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 wrote: >> Thanks, Antoine! That's exactly what I was looking for. >> >> Tim >> >> On Mon, Nov 21, 2016 at 8:36 AM, Antoine Tremblay >> 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