From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14705 invoked by alias); 2 May 2012 21:28:40 -0000 Received: (qmail 14692 invoked by uid 22791); 2 May 2012 21:28:38 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Wed, 02 May 2012 21:28:20 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q42LSG5Q017989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 17:28:16 -0400 Received: from host2.jankratochvil.net (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q42LSCpJ032668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 May 2012 17:28:15 -0400 Date: Wed, 02 May 2012 21:28:00 -0000 From: Jan Kratochvil To: "Maciej W. Rozycki" Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFA] MIPS16 FP manual call/return fixes Message-ID: <20120502212811.GA22285@host2.jankratochvil.net> References: <87mx5y70mv.fsf@fleche.redhat.com> <20120501140457.GA1691@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 2012-05/txt/msg00034.txt.bz2 On Tue, 01 May 2012 19:21:20 +0200, Maciej W. Rozycki wrote: > OK, so let me put this another way. Here we have just returned from a > function that we called. Obviously that function does exist somewhere no > matter if symbol tables have been unloaded or whatever. How can we > determine the address of that function? We can no longer reliably do so. > -- in a different way, presumably. > We must have somehow established its address previously or we couldn't > have called it. Is it possible to cache it somehow for example? Yes, we could. In set_breakpoint_location_function is created bp_gnu_ifunc_resolver, so cache it into 'struct bp_location' there (or even into 'struct breakpoint', I do not see too much difference there).. Then transfer this info when bp_gnu_ifunc_resolver_return is created from that bp_gnu_ifunc_resolver. I would be fine also with just some error there. > Thanks for raising the issue of unloading symbol tables, that's an > important point as to how MIPS16 and microMIPS symbols should be treated > in general -- here I think it will only matter in the asynchronous mode. No, even in synchronous mode. If you still do "stepi", "stepi", "stepi"... you will get something like: (gdb) start (gdb) b strcmp Breakpoint 2 at gnu-indirect-function resolver at 0x7ffff7aaa3d0: file ../sysdeps/x86_64/multiarch/strcmp.S, line 87. (gdb) b *strcmp Note: breakpoint 2 also set at pc 0x7ffff7aaa3d0. Breakpoint 3 at 0x7ffff7aaa3d0: file ../sysdeps/x86_64/multiarch/strcmp.S, line 87. (gdb) c Continuing. warning: Breakpoint 2 address previously adjusted from 0x004003c6 to 0x7ffff7aaa3d0. Breakpoint 2, strcmp () at ../sysdeps/x86_64/multiarch/strcmp.S:87 87 cmpl $0, __cpu_features+KIND_OFFSET(%rip) (gdb) maintenance info breakpoints Num Type Disp Enb Address What [...] 2 STT_GNU_IFUNC resolver keep y 0x00007ffff7aaa3d0 ../sysdeps/x86_64/multiarch/strcmp.S:87 inf 1 breakpoint already hit 1 time 3 breakpoint keep y 0x00007ffff7aaa3d0 ../sysdeps/x86_64/multiarch/strcmp.S:87 inf 1 breakpoint already hit 1 time 0 STT_GNU_IFUNC resolver return keep y 0x00007ffff7deb3be <_dl_fixup+446> inf 1 thread 1 stop only in thread 1 So you can see anything can happen now before we hit that breakpoint #0. I can for example unload the glibc symbol file by 'nosharedlibrary' (which has led to unrelated PR 14054 now). Thanks, Jan