From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3964 invoked by alias); 16 Feb 2013 04:50:58 -0000 Received: (qmail 3940 invoked by uid 22791); 16 Feb 2013 04:50:56 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_EG X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 16 Feb 2013 04:50:53 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1U6Zjf-00063C-DD from Yao_Qi@mentor.com ; Fri, 15 Feb 2013 20:50:51 -0800 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Feb 2013 20:50:51 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Fri, 15 Feb 2013 20:50:50 -0800 Message-ID: <511F0FE9.8030300@codesourcery.com> Date: Sat, 16 Feb 2013 04:50:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jiong Wang CC: 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> In-Reply-To: <50F9664D.2090008@tilera.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 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: 2013-02/txt/msg00428.txt.bz2 On 01/18/2013 11:12 PM, Jiong Wang wrote: > this is because tilegx skip_prologue will invoke > tilegx_analyze_prologue, which > will prefetch 32*8 bytes. > > while for when the address is in plt stub, you can see it near the > eh_frame_hdr section > > [14] .plt 0000000000010a00 000a00 0000a0 28 > AX 0 0 64 > ... > [16] .eh_frame_hdr 0000000000010ac0 000ac0 000024 00 A 0 0 4 > [17] .eh_frame 0000000000010ae8 000ae8 0000b4 00 A 0 0 8 > > the .eh_frame_hdr aligns to 4, there is a hole between .eh_frame_hdr and > .eh_frame, and this > will cause trouble for section_table_xfer_memory_partial. > > after fetch memory starting from 0x10ac0 to 0x10ae4, then the memaddr > will be 0x10ae4 in section_table_xfer_memory_partial, > while this function did not consider this hole situation, so goes to > line 666, error occured. Wang Jiong, AFAICT, the root cause of this problem is GDB prefetches too much contents in one time that exceeds the boundary of a section. At the beginning of tilegx_analyze_prologue, I notice this comment /* To cut down on round-trip overhead, we fetch multiple bundles at once. These variables describe the range of memory we have prefetched. */ Can't we fetch one bundle in one time? Fetching multiple bundles causes this problem, so we have to disable it. Even we still decide to use fetching multiple bundle in one time, we should take care of the boundary and existing code does this, see this comment, /* Figure out how many bytes to fetch. Don't span a page boundary since that might cause an unnecessary memory error. */ Looks existing code takes care of not crossing the page boundary, similarly, we should also take care of not crossing the section boundary. What do you think? -- Yao (齐尧)