From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30606 invoked by alias); 1 Mar 2013 14:08:16 -0000 Received: (qmail 30587 invoked by uid 22791); 1 Mar 2013 14:08:14 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RP_MATCHES_RCVD,TW_EG X-Spam-Check-By: sourceware.org Received: from usmamail.tilera.com (HELO USMAMAIL.TILERA.COM) (12.216.194.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Mar 2013 14:08:03 +0000 Received: from localhost.localdomain (218.11.179.44) by USMAExch2.tad.internal.tilera.com (10.3.0.33) with Microsoft SMTP Server (TLS) id 14.0.722.0; Fri, 1 Mar 2013 09:08:02 -0500 Message-ID: <5130B63A.1060304@tilera.com> Date: Fri, 01 Mar 2013 14:08:00 -0000 From: Jiong Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Pedro Alves CC: Yao Qi , Joel Brobecker , , Walter Lee Subject: Re: [RFC/TileGX 2/6] simplify the handling of skip prologue for plt stub References: <50F91516.6010204@tilera.com> <20130118131511.GF3564@adacore.com> <50F9664D.2090008@tilera.com> <511F0FE9.8030300@codesourcery.com> <51243991.4040304@tilera.com> <51244CBA.4000009@codesourcery.com> <512623BE.2030608@tilera.com> <51309167.5050608@redhat.com> In-Reply-To: <51309167.5050608@redhat.com> Content-Type: multipart/mixed; boundary="------------030602010207020803050505" 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: 2013-03/txt/msg00017.txt.bz2 --------------030602010207020803050505 Content-Type: text/plain; charset="gb18030"; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1763 On 03/01/2013 07:30 PM, Pedro Alves wrote > I do agree that trying to find the end of the prologue of a plt stub is futile. We know plt stubs > aren't "normal" functions, and don't have prologues. > > But, I do think the prologue analyzer still has a problem. You should see this > same issue with any small normal function (with no debug info) that happens to > end up close enough to the end of its section. I agree, but normally there will be crtn* files which will placed after the noraml function, so that the distance to the section with different alignment, for example .eh_frame_hdr, will be long enough to prevent this happen. > > I suggest limiting the end address of the analysis with something like > in tilegx_skip_prologue > > + /* Don't straddle a section boundary. */ > + s = find_pc_section (start_pc); > + end_pc = start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES; > + if (s != NULL) > + end_pc = min (end_pc, obj_section_endaddr (s)); > > return tilegx_analyze_prologue (gdbarch, > start_pc, > - start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES, > + end_pc, > > and also, make tilegx_analyze_prologue never touch memory > over end_addr. It doesn't seem to take that care currently? I think this fix make sense, and tilegx_analyze_prologue has glitch, it will ignore "end_pc" to some extent. the prefetch buffer in tilegx_analyze_prologue should consider the end_pc. I have tested the new patch by rerun dejagnu, please review, thanks. gdb/ChangeLog: * tilegx-tdep.c (tilegx_analyze_prologue): Improve the evaluation of "instbuf_size". (tilegx_skip_prologue): Improve the evaluation of the end address for prologue analyze. -- Regards, Jiong. Wang Tilera Corporation. --------------030602010207020803050505 Content-Type: text/x-patch; name="new.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="new.patch" Content-length: 1471 --- gdb/tilegx-tdep.c | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/gdb/tilegx-tdep.c b/gdb/tilegx-tdep.c index f45c20f..b398507 100644 --- a/gdb/tilegx-tdep.c +++ b/gdb/tilegx-tdep.c @@ -433,6 +433,8 @@ tilegx_analyze_prologue (struct gdbarch* gdbarch, if (instbuf_size > size_on_same_page) instbuf_size = size_on_same_page; + + instbuf_size = min (instbuf_size, (end_addr - next_addr)); instbuf_start = next_addr; status = safe_frame_unwind_memory (next_frame, instbuf_start, @@ -745,7 +747,8 @@ tilegx_analyze_prologue (struct gdbarch* gdbarch, static CORE_ADDR tilegx_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc) { - CORE_ADDR func_start; + CORE_ADDR func_start, end_pc; + struct obj_section *s = NULL; /* This is the preferred method, find the end of the prologue by using the debugging information. */ @@ -758,10 +761,16 @@ tilegx_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR start_pc) return max (start_pc, post_prologue_pc); } + /* Don't straddle a section boundary. */ + s = find_pc_section (start_pc); + end_pc = start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES; + if (s != NULL) + end_pc = min (end_pc, obj_section_endaddr (s)); + /* Otherwise, try to skip prologue the hard way. */ return tilegx_analyze_prologue (gdbarch, start_pc, - start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES, + end_pc, NULL, NULL); } --------------030602010207020803050505--