From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2627 invoked by alias); 14 Apr 2008 18:59:06 -0000 Received: (qmail 2617 invoked by uid 22791); 14 Apr 2008 18:59:05 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Apr 2008 18:58:46 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id E076B983D9; Mon, 14 Apr 2008 18:58:44 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id C791098119; Mon, 14 Apr 2008 18:58:44 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JlTt6-00076h-0c; Mon, 14 Apr 2008 14:58:44 -0400 Date: Mon, 14 Apr 2008 19:02:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: 5/5 - handle glibc pointer mangling jmp_bufs (x86/x86_64) Message-ID: <20080414185843.GH1968@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org References: <200804070336.27192.pedro@codesourcery.com> <200804072325.50739.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200804072325.50739.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2007-12-11) 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: 2008-04/txt/msg00254.txt.bz2 On Mon, Apr 07, 2008 at 11:25:50PM +0100, Pedro Alves wrote: > A Monday 07 April 2008 03:36:27, Pedro Alves wrote: > > I'm not proposing this to go in, as it will brake glibc's where > > the pointer mangling is not implemented or is implemented > > differently. Maybe we could get around this 99% of the > > times by switching the unmangling algorithm based on glibc's > > version, although I don't know how to get at glibc's version. Darn, and you got my hopes up. I figured you'd come up with a clever solution to this when I saw the patch subject. Glibc stores the key in %fs:POINTER_GUARD, from whence we can retrieve it, as in this patch. It also stores it in __pointer_chk_guard_local (local to ld.so), and __pointer_chk_guard (exported, but only on platfroms which do not put it in the TCB). If you have an unstripped ld.so, you can retrieve it from that symbol. Maybe that is good enough for now, and we can seek a better long-term solution separately. Also, the location of the guard does not definitively answer the question of whether it is used to mangle jmp_bufs. ARM and MIPS don't use it at all. Perhaps we should manually call setjmp to determine if the pointer is mangled? Heck, from there we could deduce the canary and make this a single glibc-specific method! RMS asked us about a way to expose pointer mangling to gdb ages ago. I believe Jan made this work via libthread_db, which I would prefer to avoid (remote debugging, for instance). Failing that, I think we're stuck with the symbol table. -- Daniel Jacobowitz CodeSourcery