From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-40356-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 21340 invoked by alias); 11 Jan 2012 08:44:04 -0000
Received: (qmail 21330 invoked by uid 22791); 11 Jan 2012 08:44:03 -0000
X-SWARE-Spam-Status: No, hits=0.9 required=5.0	tests=AWL,BAYES_00,BOTNET,RCVD_IN_DNSWL_NONE,RDNS_NONE
X-Spam-Check-By: sourceware.org
Received: from Unknown (HELO smtp-vbr18.xs4all.nl) (194.109.24.38)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jan 2012 08:43:45 +0000
Received: from webmail.xs4all.nl (dovemail19.xs4all.nl [194.109.26.21])	by smtp-vbr18.xs4all.nl (8.13.8/8.13.8) with ESMTP id q0B8hfob095326;	Wed, 11 Jan 2012 09:43:42 +0100 (CET)	(envelope-from mark.kettenis@xs4all.nl)
Received: from 62.48.30.1        (SquirrelMail authenticated user sibelius)        by webmail.xs4all.nl with HTTP;        Wed, 11 Jan 2012 09:43:42 +0100
Message-ID: <4e8cbd44794a5d98bc46a882c1379405.squirrel@webmail.xs4all.nl>
In-Reply-To: <4F0C9AD3.2000807@eagerm.com>
References: <4F0C9AD3.2000807@eagerm.com>
Date: Wed, 11 Jan 2012 08:44:00 -0000
Subject: Re: gdbarch_skip_solib_resolver question
From: "Mark Kettenis" <mark.kettenis@xs4all.nl>
To: "Michael Eager" <eager@eagerm.com>
Cc: gdb@sourceware.org
User-Agent: SquirrelMail/1.4.18
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2012-01/txt/msg00038.txt.bz2

>  I noticed that gdbarch_skip_solib_resolver() invokes
>  glibc_skip_solib_resolver() on x86, mips, and sh to identify
>  that gdb is stepping into _dl_runtime_resolve.
>
>  On PowerPC, gdbarch_skip_solib_resolver() always returns a zero.
>
>  I don't see any problem with gdb stopping in _dl_runtime_resolve
>  or not stepping over the routine.
>
>  So, what does this mean?  Is calling glibc_skip_solib_resolver()
>  optional?  Or is the handle_inferior_event() code so convoluted
>  or intelligent that it works even when pieces are missing?
>

If I remember correctly, gdbarch_skip_solib_resolver() is just an
optimization.  If it returns an address where GDB can set a breakpoint
that gets hit upon return from the dynamic linker.  If
gdbarch_skip_solib_resolver() returns zero GDB just single-steps through
the dynamic linker, which works, but is a bit slower.