From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26602 invoked by alias); 30 Dec 2011 11:25:00 -0000 Received: (qmail 26594 invoked by uid 22791); 30 Dec 2011 11:25:00 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Dec 2011 11:24:42 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBUBOJNp031415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Dec 2011 06:24:19 -0500 Received: from host2.jankratochvil.net (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pBUBOFAc031507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 30 Dec 2011 06:24:17 -0500 Date: Fri, 30 Dec 2011 14:16:00 -0000 From: Jan Kratochvil To: Mark Kettenis Cc: brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 #3 Message-ID: <20111230112414.GB21767@host2.jankratochvil.net> References: <20111222202047.GA16110@host2.jankratochvil.net> <20111227045606.GE23376@adacore.com> <20111228161208.GB10556@host2.jankratochvil.net> <20111228180148.GA18057@host2.jankratochvil.net> <201112282009.pBSK9LHn029918@glazunov.sibelius.xs4all.nl> <20111229231251.GA27794@host2.jankratochvil.net> <20111230033020.GA20473@adacore.com> <201112301038.pBUAcxQS004801@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201112301038.pBUAcxQS004801@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00904.txt.bz2 On Fri, 30 Dec 2011 11:38:59 +0100, Mark Kettenis wrote: > I'm still a little bit worried that Jan's approach is making > additional assumptions. The chance that the 2nd instruction of the > program will be executed again as part of the normal flow is probably > not much higher than for the 1st instructions, The patched code does not use the original entry_point_address in any way, it passes to gdbarch_push_dummy_call already the adjusted address as bp_addr. This is also the reason why it no longer uses gdb_buffered_insn_length but just gdbarch_breakpoint_from_pc's bp_len is enough. We may place the breakpoint inside the first instruction ("corrupting" it) but as the first instruction is not used anywhere it does not matter. The inferior call will return right to our placed breakpoint address. > And I know Jan has checked his diff on ia64, but there might be other > architectures that have the concept of instruction bundles where jumping > into the middle of a bundle doesn't work. It is only important entry_point_address + bp_len is still a valid placement for a breakpoint. ia64 will place it to the next bundle (+16 bytes) which will work. Still I can imagine for example big endian architecture with 32-bit fixed lenght instructions where any opcode 0xFF?????? is a breakpoint and therefore its gdbarch_breakpoint_from_pc returns BP_LEN as 1. But we cannot place our breakpoint on entry_point_address + 1. Unaware if such arch exists. My patch would break such arch. It also means the current displaced_step_at_entry_point implementation for displaced stepping would not work on that arch, if one would try to implemented displaced stepping there. Thanks, Jan