From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67202 invoked by alias); 8 Jun 2017 12:16:57 -0000 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 Received: (qmail 67189 invoked by uid 89); 8 Jun 2017 12:16:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:2259 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Jun 2017 12:16:56 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 421AA734; Thu, 8 Jun 2017 12:16:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 421AA734 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 421AA734 Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id B37CE8D2C2; Thu, 8 Jun 2017 12:16:49 +0000 (UTC) Subject: Re: [PATCH] TLS access support in cross- Linux GDB To: Gary Benson , Djordje Todorovic References: <593529D1.7040206@rt-rk.com> <20170608102003.GA24047@blade.nx> Cc: gdb-patches@sourceware.org, nemanja.popov@rt-rk.com, nikola.prica@rt-rk.com, petar.jovanovic@rt-rk.com, asowda@cisco.com, ibaev@cisco.com From: Pedro Alves Message-ID: <86cbd96e-d8c8-57f5-5951-2b19592425cd@redhat.com> Date: Thu, 08 Jun 2017 12:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170608102003.GA24047@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00209.txt.bz2 On 06/08/2017 11:20 AM, Gary Benson wrote: > I really don't think this approach is right for mainline GDB. It's > embedding glibc implementation details into GDB, things like alignment > and structure offsets which may change at any time. I'm mainly > looking at the code in init_target_dep_constants, but there's other > stuff e.g. the definition of TLS_PRE_TCB_SIZE in tls.h. You're > relying on *so* much stuff not changing, but glibc makes no such > guarantees. I agree. My own take on this: The whole point of libthread_db is to insulate debuggers from libc's internals. If the idea of a single libthread_db build that can be used to cross debug multiple architectures (and a range of glibc versions, I suppose) makes sense, then I think you should be pushing it to glibc/nptl_db upstream directly. I.e., what would need to change in libthread_db.so and gdb that would make it possible for GDB to just load libthread_db.so and have it be usable in cross core debugging scenarios? Presumably, some decisions made at libthread_db's compile time would have to be adjusted to be deferred to run time? It is my understanding that the current libthread_db.so implementation was actually designed with this run-time selection in mind, and that's why it has things like: /* The method of locating a thread's th_unique value. */ enum { ta_howto_unknown, ta_howto_reg, ta_howto_reg_thread_area, ta_howto_const_thread_area } ta_howto; and then uses if/switch around enums like that at run time, instead of selecting the right methods at compile time. Maybe what's there is only usable currently in biarch scenarios, though, I'm not sure. By largely copying over libthread_db into gdb and tweaking it, we'd effectively be stating that gdb is going to take care of libthread_db's maintenance, and taking care of making our version workable against perhaps a range of different glibc versions when glibc internals change. That doesn't seem like a good approach to me. If handling multiple archs and versions in a single source copy of libthread_db makes sense, then I think it'd make much more sense to do that in glibc/libthread_db proper, than in gdb. Was that option considered? Thanks, Pedro Alves