From patchwork Mon Nov 9 18:12:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Brobecker X-Patchwork-Id: 9618 Received: (qmail 19948 invoked by alias); 9 Nov 2015 18:12:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 19937 invoked by uid 89); 9 Nov 2015 18:12:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 09 Nov 2015 18:12:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1E5EA2989F; Mon, 9 Nov 2015 13:12:29 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ueVNiJQmJ5m4; Mon, 9 Nov 2015 13:12:29 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id DF4B129720; Mon, 9 Nov 2015 13:12:28 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 6C97F405BA; Mon, 9 Nov 2015 10:12:27 -0800 (PST) From: Joel Brobecker To: gdb-patches@sourceware.org Cc: Tristan Gingold Subject: [RFA/commit] infinite loop stopping at "pop" insn on x64-windows Date: Mon, 9 Nov 2015 10:12:26 -0800 Message-Id: <1447092746-21120-1-git-send-email-brobecker@adacore.com> Hello, We noticed the following hang trying to run a program where one of the subroutines we built without debugging info (opaque_routine): $ gdb my_program (gdb) break opaque_routine (gdb) run [...hangs...] The problem comes from the fact that, at the breakpoint's address, we have the following code: => 0x0000000000401994 <+4>: pop %rbp At some point after hitting the breakpoint and stopping, GDB calls amd64_windows_frame_decode_epilogue, which then gets stuck in the following infinite loop: | /* We don't care about the instruction deallocating the frame: | if it hasn't been executed, the pc is still in the body, | if it has been executed, the following epilog decoding will work. */ | | /* First decode: | - pop reg [41 58-5f] or [58-5f]. */ | | while (1) | { | /* Read opcode. */ | if (target_read_memory (pc, &op, 1) != 0) | return -1; | | if (op >= 0x40 && op <= 0x4f) | { | /* REX prefix. */ | rex = op; | | /* Read opcode. */ | if (target_read_memory (pc + 1, &op, 1) != 0) | return -1; | } | else | rex = 0; | | if (op >= 0x58 && op <= 0x5f) | { | /* pop reg */ | gdb_byte reg = (op & 0x0f) | ((rex & 1) << 3); | | cache->prev_reg_addr[amd64_windows_w2gdb_regnum[reg]] = cur_sp; | cur_sp += 8; | } | else | break; | | /* Allow the user to break this loop. This shouldn't happen as the | number of consecutive pop should be small. */ | QUIT; | } Nothing in that loop updates PC, and therefore, because the instruction we stopped at is a "pop", we keep looping forever doing the same thing over and over! This patch fixes the issue by advancing PC to the beginning of the next instruction if the current one is a "pop reg" instruction. gdb/ChangeLog: * amd64-windows-tdep.c (amd64_windows_frame_decode_epilogue): Increment PC in while loop skipping "pop reg" instructions. Tested on x86_64-windows, using AdaCore's testsuite. Thanks! diff --git a/gdb/amd64-windows-tdep.c b/gdb/amd64-windows-tdep.c index 296bdb2..c04b730 100644 --- a/gdb/amd64-windows-tdep.c +++ b/gdb/amd64-windows-tdep.c @@ -488,6 +488,7 @@ amd64_windows_frame_decode_epilogue (struct frame_info *this_frame, cache->prev_reg_addr[amd64_windows_w2gdb_regnum[reg]] = cur_sp; cur_sp += 8; + pc += rex ? 2 : 1; } else break;