From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4375 invoked by alias); 22 Aug 2007 21:43:33 -0000 Received: (qmail 4245 invoked by uid 22791); 22 Aug 2007 21:43:32 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Aug 2007 21:43:30 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l7MLhPsX001384; Wed, 22 Aug 2007 17:43:25 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l7MLhOSh013314; Wed, 22 Aug 2007 17:43:24 -0400 Received: from localhost.localdomain (vpn-14-253.rdu.redhat.com [10.11.14.253]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l7MLhO2p019443; Wed, 22 Aug 2007 17:43:24 -0400 Message-ID: <46CCADFB.40407@redhat.com> Date: Wed, 22 Aug 2007 21:43:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 CC: Mark Wielaard , frysk@sourceware.org Subject: Re: Roundtable, breakpoints and lots of unwinding (Was: meeting 2007-08-15 9:30 us east coast time) References: <46C257B2.5030903@redhat.com> <46C2FDB9.2090800@redhat.com> <1187688075.3852.32.camel@dijkstra.wildebeest.org> In-Reply-To: <1187688075.3852.32.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00327.txt.bz2 Mark Wielaard wrote: >> mjw: bug fixes for stepping; >> > > - Currently we hook into this new unw_get_unwind_table through > UnwindH.hxx (createProcInfoFromElfImage), this is called indirectly > through the libunwind find_proc_info callback which wants to see the > unwind_info filled in. The ElfImage used is created in > UnwindAddressSpace.findProcInfo() through the private method > getElfImage(long address) by getting the MemoryMap of the address from > the Task and either mapping the map from the elf file into memory or if > the section is the VDSO by creating an anonymous mmap and filling that > through reading the address map and then passing it to the libunwind > dwarf reader. Directly mmapping these sections seems wrong here since > the sections should already be available through the memory buffers of > the proc we are inspecting (which might already have mapped in those > sections). So it would be better to use the libunwind addressspace > accessors that go through the ByteBuffers also for this. This might mean > another change in the libunwind interface so all remote memory accesses > go through the same hooks (although unw_get_unwind_table already > provides an unw_address_space as argument, so I might be missing > something). > > This strikes me as especially worry-some in core file unwinding. Why would you want to mmap at all anything? All access to any memroy/maps in a core file case should be done via .getMemory(). It should be left to the CorefileByteBuffer to arbitrate whether it can find the memory address in the core file and return that, or go to the relevant solib and get it for you. It is the only thing that has the sufficient meta-data, and thus smarts to make that decision. Maybe I misunderstood, but other than the initial "beginning" of the unwind, the unwind code might be mmap'ing the library in directly? Nice write up, by the way. This is ideal blogging material. Regards Phil