From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92195 invoked by alias); 8 Jun 2017 09:15:53 -0000 Mailing-List: contact infinity-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: infinity-owner@sourceware.org Received: (qmail 82727 invoked by uid 89); 8 Jun 2017 09:15:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=held X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients 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 09:15:43 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3C48BC0587C4; Thu, 8 Jun 2017 09:15:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3C48BC0587C4 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=gbenson@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3C48BC0587C4 Received: from blade.nx (unknown [10.33.36.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE16589C5C; Thu, 8 Jun 2017 09:15:45 +0000 (UTC) Received: from blade.com (localhost [127.0.0.1]) by blade.nx (Postfix) with ESMTP id 9225980F035C; Thu, 8 Jun 2017 10:15:44 +0100 (BST) From: Gary Benson To: gdb-patches@sourceware.org Cc: infinity@sourceware.org Subject: [RFC 0/5] New proc_service functionality for Infinity Date: Thu, 08 Jun 2017 09:15:00 -0000 Message-Id: <1496913338-22195-1-git-send-email-gbenson@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 08 Jun 2017 09:15:46 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00013.txt.bz2 Hi all, Infinity is a platform-independent system for executables and shared libraries to expose functionality to debug, monitoring, and analysis tooling. Executable and shared library files contain platform- independent debugging functions that tools like GDB can load and execute. I've written a prototype libthread_db that uses Infinity functions. Implementation-specific details such as structure offsets and other constants are held with the implementation (specifically, in libpthread.so and ld.so) which means that one libthread_db.so can support any correctly-annotated system, regardless of architecture or operating system, and without recompilation. You can, for example, debug a core file from an aarch64 system running Debian on your x86_64 laptop that's running Fedora. You can try this out right now, there's instructions at: https://infinitynotes.org/wiki/Third_Eye This series adds proc_service functionality that the Infinity libthread_db.so needs. The series isn't polished, but I'm mailing it now to get feedback on the two new proc_service functions I'm proposing in patch 4. Specifically I'd like feedback on the API, I'd like to know it's going to be acceptable and make any required changes now. The things Infinity needs that the existing proc_service API doesn't provide are: 1) The ability to get the contents of a registers in a cross-platform environment. proc_service has ps_lgetregs, but it's not suitable. proc_service has no way to determine the inferior's architecture, so there's no way to determine the size of the register set you're going to get, and no way to determine where in that register set the register values you want are. I've handled this by adding ps_get_register, which returns the contents of a single register, referenced by its DWARF register number. 2) The ability to fetch .note.infinity sections from the inferior's executable and shared libraries. With proc_service as it stands, you can sort of find the binaries in some cases, but you can't find them in all cases GDB supports: if they're in a sysroot, for example. The only way I could think of to reliably solve this in all cases GDB supports is to have GDB extract the sections itself and supply them to the library via a callback. It's further complicated by the fact that .note.infinity sections contain addresses that require relocation. I've handled this with the ps_foreach_infinity_note function. I'm not 100% happy with how complex this part of the API is, but I can't see a simpler way :/ Thanks, Gary -- https://infinitynotes.org/