From patchwork Wed Mar 22 21:17:37 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 66773 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C0F5A385F014 for ; Wed, 22 Mar 2023 21:18:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C0F5A385F014 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679519892; bh=fGGIQu2gSfCMm7ghPG4KSQrXbRkEXvzTVvCjmyRWMgY=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Vhib2xikUjVxne8cUIW85qciFEQ3eD2143tP3o598uNm8XG2aKStCHdo6TCZWSIZ3 idV5bM2OvypCpynKh4QL8ZUWJgzH844RGwgMAOs1xgmqLPGfJjGnBk8GIc4FjXMnvb rQP28eViqIgPj485JwHsPaXNW3xg3UxdQy2y20Ac= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 0AA75385843D for ; Wed, 22 Mar 2023 21:17:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0AA75385843D Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-260-xNLLo0a2Nzaq_RpTMH93rg-1; Wed, 22 Mar 2023 17:17:44 -0400 X-MC-Unique: xNLLo0a2Nzaq_RpTMH93rg-1 Received: by mail-wm1-f70.google.com with SMTP id iv10-20020a05600c548a00b003ee112e6df1so4110100wmb.2 for ; Wed, 22 Mar 2023 14:17:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679519863; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fGGIQu2gSfCMm7ghPG4KSQrXbRkEXvzTVvCjmyRWMgY=; b=KU7ypsMnQLQqX8anWt7sRwlmn+vQQwGkIbW74xn84yhLvj5Odvdc6/rGqXJVRpYbeL l5J/JneGn36abxrn02Hy87iNOf59glNuQhKyXNAx5SAiZPV+fZO+N6jR51bY/L/b+VQz wlDPzYSKZ1YKN8Ho9RoCklO6afRDjN+6ULiFJBWkLlZ/mQfBCUKlc3IqSM+59SnbghyR 0cw5YZUcDLiACMnsdxfKmXn/zsQxF09HdeqZaYPohQ+gK+F3PbVHDY2Rw2YxfgxrDh4o iFScFZ1rHsvHMHNv+DJ6uWPGVGm+KiFlTWwkalkEXELqSPcY8x84IVFZoqR5YoZT4j+g +1RQ== X-Gm-Message-State: AAQBX9c1RvX9SpnZ5WObPDVqE8ENtgmkHsj+6ZU4aJCY3hr+3nAMObSl WAQRV41dDdUj8IY9qBYMCSxSt0O3oxv3TiGhGgzNngpjB0UV48eH3EtwlX9Nc5SDxAn7pf1VcbU F7EgHzMs1z3YfRCVQzVcEuls983unlNyJbH9AZ1wfTJ36/peBSur059Wd9p4c5znOEA/OgKc5cn 1+e0lZ7A== X-Received: by 2002:adf:f5c2:0:b0:2cf:f467:54d9 with SMTP id k2-20020adff5c2000000b002cff46754d9mr881949wrp.53.1679519862883; Wed, 22 Mar 2023 14:17:42 -0700 (PDT) X-Google-Smtp-Source: AKy350bUm4xvIThD3aZidrKCB81t+H6tg5nvhCC4zwyh8NN8VpT4rUnS4JzKh366JmQGhKsCL2gskg== X-Received: by 2002:adf:f5c2:0:b0:2cf:f467:54d9 with SMTP id k2-20020adff5c2000000b002cff46754d9mr881933wrp.53.1679519862434; Wed, 22 Mar 2023 14:17:42 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id y16-20020a056000109000b002c56013c07fsm14540721wrw.109.2023.03.22.14.17.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Mar 2023 14:17:42 -0700 (PDT) To: gdb-patches@sourceware.org Cc: Pedro Alves , Simon Marchi , Andrew Burgess Subject: [PATCHv2 1/2] gdb: more debug output for displaced stepping Date: Wed, 22 Mar 2023 21:17:37 +0000 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: <8473de37-fa6b-f7ec-e4b6-78b971324804@simark.ca> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Andrew Burgess via Gdb-patches From: Andrew Burgess Reply-To: Andrew Burgess Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" While investigating a displaced stepping issue I wanted an easy way to see what GDB thought the original instruction was, and what instruction GDB replaced that with when performing the displaced step. We do print out the address that is being stepped, so I can track down the original instruction, I just need to go find the information myself. And we do print out the bytes of the new instruction, so I can figure out what the replacement instruction was, but it's not really easy. Also, the code that prints the bytes of the replacement instruction only prints 4 bytes, which clearly isn't always going to be correct. In this commit I remove the existing code that prints the bytes of the replacement instruction, and add two new blocks of code to displaced_step_prepare_throw. This new code prints the original instruction, and the replacement instruction. In each case we print both the bytes that make up the instruction and the completely disassembled instruction. Here's an example of what the output looks like on x86-64 (this is with 'set debug displaced on'). The two interesting lines contain the strings 'original insn' and 'replacement insn': (gdb) step [displaced] displaced_step_prepare_throw: displaced-stepping 2892655.2892655.0 now [displaced] displaced_step_prepare_throw: original insn 0x401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 0x404018 [displaced] prepare: selected buffer at 0x401052 [displaced] prepare: saved 0x401052: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 [displaced] fixup_riprel: %rip-relative addressing used. [displaced] fixup_riprel: using temp reg 2, old value 0x7ffff7f8a578, new value 0x401036 [displaced] amd64_displaced_step_copy_insn: copy 0x401030->0x401052: ff a1 e2 2f 00 00 68 00 00 00 00 e9 e0 ff ff ff [displaced] displaced_step_prepare_throw: prepared successfully thread=2892655.2892655.0, original_pc=0x401030, displaced_pc=0x401052 [displaced] displaced_step_prepare_throw: replacement insn 0x401052: ff a1 e2 2f 00 00 jmp *0x2fe2(%rcx) [displaced] finish: restored 2892655.2892655.0 0x401052 [displaced] amd64_displaced_step_fixup: fixup (0x401030, 0x401052), insn = 0xff 0xa1 ... [displaced] amd64_displaced_step_fixup: restoring reg 2 to 0x7ffff7f8a578 0x00007ffff7e402c0 in puts () from /lib64/libc.so.6 (gdb) One final note. For many targets that support displaced stepping (in fact all targets except ARM) the replacement instruction is always a single instruction. But on ARM the replacement could actually be a series of instructions. The debug code tries to handle this by disassembling the entire displaced stepping buffer. Obviously this might actually print more than is necessary, but there's (currently) no easy way to know how many instructions to disassemble; that knowledge is all locked in the architecture specific code. Still I don't think it really hurts, if someone is looking at this debug then hopefully they known what to expect. Obviously we can imagine schemes where the architecture specific displaced stepping code could communicate back how many bytes its replacement sequence was, and then our debug print code could use this to limit the disassembly. But this seems like a lot of effort just to save printing a few additional instructions in some debug output. I'm not proposing to do anything about this issue for now. --- gdb/infrun.c | 85 +++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 68 insertions(+), 17 deletions(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index 5c9babb9104..8c56a9a4dfb 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -74,6 +74,7 @@ #include "gdbsupport/common-debug.h" #include "gdbsupport/buildargv.h" #include "extension.h" +#include "disasm.h" /* Prototypes for local functions */ @@ -1807,6 +1808,31 @@ displaced_step_prepare_throw (thread_info *tp) CORE_ADDR original_pc = regcache_read_pc (regcache); CORE_ADDR displaced_pc; + /* Display the instruction we are going to displaced step. */ + if (debug_displaced) + { + string_file tmp_stream; + int dislen = gdb_print_insn (gdbarch, original_pc, &tmp_stream, + nullptr); + + if (dislen > 0) + { + gdb::byte_vector insn_buf (dislen); + read_memory (original_pc, insn_buf.data (), insn_buf.size ()); + + std::string insn_bytes + = displaced_step_dump_bytes (insn_buf.data (), insn_buf.size ()); + + displaced_debug_printf ("original insn %s: %s \t %s", + paddress (gdbarch, original_pc), + insn_bytes.c_str (), + tmp_stream.string ().c_str ()); + } + else + displaced_debug_printf ("replacement insn %s: invalid length: %d", + paddress (gdbarch, original_pc), dislen); + } + displaced_step_prepare_status status = gdbarch_displaced_step_prepare (gdbarch, tp, displaced_pc); @@ -1845,6 +1871,48 @@ displaced_step_prepare_throw (thread_info *tp) paddress (gdbarch, original_pc), paddress (gdbarch, displaced_pc)); + /* Display the new displaced instruction(s). */ + if (debug_displaced) + { + string_file tmp_stream; + CORE_ADDR addr = displaced_pc; + + /* If displaced stepping is going to use h/w single step then we know + that the replacement instruction can only be a single instruction, + in that case set the end address at the next byte. + + Otherwise the displaced stepping copy instruction routine could + have generated multiple instructions, and all we know is that they + must fit within the LEN bytes of the buffer. */ + CORE_ADDR end + = addr + (gdbarch_displaced_step_hw_singlestep (gdbarch) + ? 1 : gdbarch_displaced_step_buffer_length (gdbarch)); + + while (addr < end) + { + int dislen = gdb_print_insn (gdbarch, addr, &tmp_stream, nullptr); + if (dislen <= 0) + { + displaced_debug_printf + ("replacement insn %s: invalid length: %d", + paddress (gdbarch, addr), dislen); + break; + } + + gdb::byte_vector insn_buf (dislen); + read_memory (addr, insn_buf.data (), insn_buf.size ()); + + std::string insn_bytes + = displaced_step_dump_bytes (insn_buf.data (), insn_buf.size ()); + std::string insn_str = tmp_stream.release (); + displaced_debug_printf ("replacement insn %s: %s \t %s", + paddress (gdbarch, addr), + insn_bytes.c_str (), + insn_str.c_str ()); + addr += dislen; + } + } + return DISPLACED_STEP_PREPARE_STATUS_OK; } @@ -2711,23 +2779,6 @@ resume_1 (enum gdb_signal sig) step = false; } - if (debug_displaced - && tp->control.trap_expected - && use_displaced_stepping (tp) - && !step_over_info_valid_p ()) - { - struct regcache *resume_regcache = get_thread_regcache (tp); - struct gdbarch *resume_gdbarch = resume_regcache->arch (); - CORE_ADDR actual_pc = regcache_read_pc (resume_regcache); - gdb_byte buf[4]; - - read_memory (actual_pc, buf, sizeof (buf)); - displaced_debug_printf ("run %s: %s", - paddress (resume_gdbarch, actual_pc), - displaced_step_dump_bytes - (buf, sizeof (buf)).c_str ()); - } - if (tp->control.may_range_step) { /* If we're resuming a thread with the PC out of the step From patchwork Wed Mar 22 21:17:38 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 66774 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 60C003854811 for ; Wed, 22 Mar 2023 21:18:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60C003854811 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679519899; bh=gLz+JduIp+jzmvnb/nqG/1KckidE0UjPlDkDTbF33rM=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=N5GGqxTRJe9jvPMft05EIQf/yg4NQJbtNzrjhbG8fpANCAJLfDlrWeLDj4tHgpkjt 0dsVyC2GC0lKSmqu9eh+3hsco3Qn35TFPRRS0bevipq4hSMhfDnqdF4JegTTH068X4 r5WPKVxP2CeydMrRnQEIMkCp007MUtbFImfCT0eY= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 5AAB5385802F for ; Wed, 22 Mar 2023 21:17:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AAB5385802F Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-573-oOxhO8c8PrqpFYSWB9XwMA-1; Wed, 22 Mar 2023 17:17:45 -0400 X-MC-Unique: oOxhO8c8PrqpFYSWB9XwMA-1 Received: by mail-wm1-f72.google.com with SMTP id fl22-20020a05600c0b9600b003ed26ca6206so12204862wmb.2 for ; Wed, 22 Mar 2023 14:17:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679519864; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gLz+JduIp+jzmvnb/nqG/1KckidE0UjPlDkDTbF33rM=; b=KcM+Aw3NKLFIZvhHLYVM9YTVQ9IVspTYo07ZqSxvYf5vJQl9MQ18ZtHJ9jvjVLOtAK jGQi2z5NcT3PxLKgP/loVidZTCXWuWwET6GPV2tYB/HLJR/U0w5ezsVc07U1KxKCDiuq RCEzVTR8jnWH/CyZdXYhHlAEOUmtO+Pg1BELkoYbwB1oZizJSWXK06Vj6kY8hoshKOHb glR38akDfwBK7MtmVzlvHGmsvluncejmx8ZHqbMDyKsnrwCztgIQadUPUVFijo2SVbnt 6OvvV3U4+XJ/7Pki7C6ZeE31/R6HDP0fzwnsqJb8xRBq3bil8LfxgneQuNEDiNkOxSKp Bzig== X-Gm-Message-State: AO0yUKXicQIBi7bYpnJWpxzSkhX+kcUdLdZuX1mqJBC7B5uqqfkL9MNv Il2sAAal9OwiWKIm1ZTgekE9MxPLroWRcfL7UJVfuZNvCcnRxaK52nB4OjcTZ2kRpPieQ55Ng9b XL0pGG2rsSxOYIMwajSMQmTGlN8e9eLuWg2omUcsVfyLsPlf50btBZoBu1Qb1C1PI1eoKKsP9Ai v2CFtpPA== X-Received: by 2002:a1c:f418:0:b0:3ed:ea48:cd92 with SMTP id z24-20020a1cf418000000b003edea48cd92mr717465wma.15.1679519864335; Wed, 22 Mar 2023 14:17:44 -0700 (PDT) X-Google-Smtp-Source: AK7set8cTYP43lFGhLnv8wqqSQvyWXCduHl6t0IQRgjbw3fi9VMnCHKiVQ9sft+aPNz6YEPKoeoUAw== X-Received: by 2002:a1c:f418:0:b0:3ed:ea48:cd92 with SMTP id z24-20020a1cf418000000b003edea48cd92mr717451wma.15.1679519863987; Wed, 22 Mar 2023 14:17:43 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id p7-20020a1c7407000000b003ee6c54b0bcsm2149942wmc.48.2023.03.22.14.17.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Mar 2023 14:17:43 -0700 (PDT) To: gdb-patches@sourceware.org Cc: Pedro Alves , Simon Marchi , Andrew Burgess Subject: [PATCHv2 2/2] gdb: move displaced_step_dump_bytes into gdbsupport (and rename) Date: Wed, 22 Mar 2023 21:17:38 +0000 Message-Id: <0d897dde8989669fccbcca675f403ae5a3914bb5.1679519312.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: <8473de37-fa6b-f7ec-e4b6-78b971324804@simark.ca> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Andrew Burgess via Gdb-patches From: Andrew Burgess Reply-To: Andrew Burgess Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" It was pointed out during review of another patch that the function displaced_step_dump_bytes really isn't specific to displaced stepping, and should really get a more generic name and move into gdbsupport/. This commit does just that. The function is renamed to bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}. The function implementation doesn't really change. Much... ... I have updated the function to take an array view, which makes it slightly easier to call in a couple of places where we already have a gdb::bytes_vector. I've then added an inline wrapper to convert a raw pointer and length into an array view, which is used in places where we don't easily have a gdb::bytes_vector (or similar). Updated all users of displaced_step_dump_bytes. There should be no user visible changes after this commit. --- gdb/amd64-tdep.c | 2 +- gdb/displaced-stepping.c | 3 +-- gdb/i386-tdep.c | 2 +- gdb/infrun.c | 24 ++---------------------- gdb/infrun.h | 3 --- gdb/rs6000-tdep.c | 2 +- gdb/s390-tdep.c | 2 +- gdbsupport/array-view.h | 1 + gdbsupport/common-utils.cc | 18 ++++++++++++++++++ gdbsupport/common-utils.h | 15 +++++++++++++++ 10 files changed, 41 insertions(+), 31 deletions(-) diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c index 81665e52d29..228b7518cb0 100644 --- a/gdb/amd64-tdep.c +++ b/gdb/amd64-tdep.c @@ -1526,7 +1526,7 @@ amd64_displaced_step_copy_insn (struct gdbarch *gdbarch, displaced_debug_printf ("copy %s->%s: %s", paddress (gdbarch, from), paddress (gdbarch, to), - displaced_step_dump_bytes (buf, len).c_str ()); + bytes_to_string (buf, len).c_str ()); /* This is a work around for a problem with g++ 4.8. */ return displaced_step_copy_insn_closure_up (dsc.release ()); diff --git a/gdb/displaced-stepping.c b/gdb/displaced-stepping.c index 9f98ea8c35b..534e031a88e 100644 --- a/gdb/displaced-stepping.c +++ b/gdb/displaced-stepping.c @@ -122,8 +122,7 @@ displaced_step_buffers::prepare (thread_info *thread, CORE_ADDR &displaced_pc) displaced_debug_printf ("saved %s: %s", paddress (arch, buffer->addr), - displaced_step_dump_bytes - (buffer->saved_copy.data (), len).c_str ()); + bytes_to_string (buffer->saved_copy).c_str ()); /* Save this in a local variable first, so it's released if code below throws. */ diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c index 96c04c1a3d6..e93479c35a3 100644 --- a/gdb/i386-tdep.c +++ b/gdb/i386-tdep.c @@ -830,7 +830,7 @@ i386_displaced_step_copy_insn (struct gdbarch *gdbarch, displaced_debug_printf ("%s->%s: %s", paddress (gdbarch, from), paddress (gdbarch, to), - displaced_step_dump_bytes (buf, len).c_str ()); + bytes_to_string (buf, len).c_str ()); /* This is a work around for a problem with g++ 4.8. */ return displaced_step_copy_insn_closure_up (closure.release ()); diff --git a/gdb/infrun.c b/gdb/infrun.c index 8c56a9a4dfb..b021f40ae6e 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1725,24 +1725,6 @@ displaced_step_reset (displaced_step_thread_state *displaced) using displaced_step_reset_cleanup = FORWARD_SCOPE_EXIT (displaced_step_reset); -/* See infrun.h. */ - -std::string -displaced_step_dump_bytes (const gdb_byte *buf, size_t len) -{ - std::string ret; - - for (size_t i = 0; i < len; i++) - { - if (i == 0) - ret += string_printf ("%02x", buf[i]); - else - ret += string_printf (" %02x", buf[i]); - } - - return ret; -} - /* Prepare to single-step, using displaced stepping. Note that we cannot use displaced stepping when we have a signal to @@ -1820,8 +1802,7 @@ displaced_step_prepare_throw (thread_info *tp) gdb::byte_vector insn_buf (dislen); read_memory (original_pc, insn_buf.data (), insn_buf.size ()); - std::string insn_bytes - = displaced_step_dump_bytes (insn_buf.data (), insn_buf.size ()); + std::string insn_bytes = bytes_to_string (insn_buf); displaced_debug_printf ("original insn %s: %s \t %s", paddress (gdbarch, original_pc), @@ -1902,8 +1883,7 @@ displaced_step_prepare_throw (thread_info *tp) gdb::byte_vector insn_buf (dislen); read_memory (addr, insn_buf.data (), insn_buf.size ()); - std::string insn_bytes - = displaced_step_dump_bytes (insn_buf.data (), insn_buf.size ()); + std::string insn_bytes = bytes_to_string (insn_buf); std::string insn_str = tmp_stream.release (); displaced_debug_printf ("replacement insn %s: %s \t %s", paddress (gdbarch, addr), diff --git a/gdb/infrun.h b/gdb/infrun.h index 5219063586d..9b3c8962939 100644 --- a/gdb/infrun.h +++ b/gdb/infrun.h @@ -270,9 +270,6 @@ extern void update_signals_program_target (void); $_exitsignal. */ extern void clear_exit_convenience_vars (void); -/* Dump LEN bytes at BUF in hex to a string and return it. */ -extern std::string displaced_step_dump_bytes (const gdb_byte *buf, size_t len); - extern void update_observer_mode (void); extern void signal_catch_update (const unsigned int *); diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c index 52dcc89b2df..8e37c3d5183 100644 --- a/gdb/rs6000-tdep.c +++ b/gdb/rs6000-tdep.c @@ -940,7 +940,7 @@ ppc_displaced_step_copy_insn (struct gdbarch *gdbarch, displaced_debug_printf ("copy %s->%s: %s", paddress (gdbarch, from), paddress (gdbarch, to), - displaced_step_dump_bytes (buf, len).c_str ()); + bytes_to_string (buf, len).c_str ()); /* This is a work around for a problem with g++ 4.8. */ return displaced_step_copy_insn_closure_up (closure.release ()); diff --git a/gdb/s390-tdep.c b/gdb/s390-tdep.c index cab1757c5ab..081a8b68867 100644 --- a/gdb/s390-tdep.c +++ b/gdb/s390-tdep.c @@ -469,7 +469,7 @@ s390_displaced_step_copy_insn (struct gdbarch *gdbarch, displaced_debug_printf ("copy %s->%s: %s", paddress (gdbarch, from), paddress (gdbarch, to), - displaced_step_dump_bytes (buf, len).c_str ()); + bytes_to_string (buf, len).c_str ()); /* This is a work around for a problem with g++ 4.8. */ return displaced_step_copy_insn_closure_up (closure.release ()); diff --git a/gdbsupport/array-view.h b/gdbsupport/array-view.h index 3d8248b08b7..d07c8bc53fc 100644 --- a/gdbsupport/array-view.h +++ b/gdbsupport/array-view.h @@ -21,6 +21,7 @@ #include "traits.h" #include #include +#include "gdbsupport/gdb_assert.h" /* An array_view is an abstraction that provides a non-owning view over a sequence of contiguous objects. diff --git a/gdbsupport/common-utils.cc b/gdbsupport/common-utils.cc index e382fb28d8f..8e13d2f218b 100644 --- a/gdbsupport/common-utils.cc +++ b/gdbsupport/common-utils.cc @@ -445,3 +445,21 @@ hex2bin (const char *hex) return bin; } + +/* See gdbsupport/common-utils.h. */ + +std::string +bytes_to_string (gdb::array_view bytes) +{ + std::string ret; + + for (size_t i = 0; i < bytes.size (); i++) + { + if (i == 0) + ret += string_printf ("%02x", bytes[i]); + else + ret += string_printf (" %02x", bytes[i]); + } + + return ret; +} diff --git a/gdbsupport/common-utils.h b/gdbsupport/common-utils.h index 97dcb9fa8ce..8ee4549a43d 100644 --- a/gdbsupport/common-utils.h +++ b/gdbsupport/common-utils.h @@ -24,6 +24,7 @@ #include #include "gdbsupport/byte-vector.h" #include "gdbsupport/gdb_unique_ptr.h" +#include "gdbsupport/array-view.h" #include "poison.h" #include "gdb_string_view.h" @@ -194,6 +195,20 @@ extern int hex2bin (const char *hex, gdb_byte *bin, int count); /* Like the above, but return a gdb::byte_vector. */ gdb::byte_vector hex2bin (const char *hex); +/* Build a string containing the contents of BYTES. Each byte is + represented as a 2 character hex string, with spaces separating each + individual byte. */ + +extern std::string bytes_to_string (gdb::array_view bytes); + +/* See bytes_to_string above. This takes a BUFFER pointer and LENGTH + rather than an array view. */ + +static inline std::string bytes_to_string (gdb_byte *buffer, size_t length) +{ + return bytes_to_string ({buffer, length}); +} + /* A fast hashing function. This can be used to hash data in a fast way when the length is known. If no fast hashing library is available, falls back to iterative_hash from libiberty. START_VALUE can be set to