From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8001 invoked by alias); 28 Dec 2016 19:48:38 -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 7133 invoked by uid 89); 28 Dec 2016 19:48:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Gnu, frees, scarce, extremely X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wj0-f196.google.com Received: from mail-wj0-f196.google.com (HELO mail-wj0-f196.google.com) (209.85.210.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Dec 2016 19:48:27 +0000 Received: by mail-wj0-f196.google.com with SMTP id j10so55530005wjb.3; Wed, 28 Dec 2016 11:48:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fJ74Gd0dwwX4vqR9VvoKElw5YSH8zQOK8sJfUfNLlBc=; b=KBSQWjCKecLhncTPqQsExwICOizCxalyIYruOHzdHpVNV9Ng1vtkHY4OKKa5LtqyIq PjQiUnn9Z+PZfvNbVOcuxkP1h9HISTHCKajbJoKVHwHtfBnCP4wpxM2a1fk+tIGFL9dj D+UXkdo0LQs66+hWMbZosebWtHwjA1zfg/DVrrncfjFhStuvLTOajIjjpNrA+wutCoFX rArXFEn/CsVgfLXi/vLiIdN3b61D0fKM8COl3bJ0EuPuKRRACt/y5vpIhpVX8k7Nln5s KfJCpiTYjUM3HJ5vqvaTvjaCbCnDe4yXKCMuAJ6oFxUqvSZ1ndXT6/xYNG54fFvwe5Rs VRNQ== X-Gm-Message-State: AIkVDXIfOsvzXA1oSAsw1mO3F4rr4GzpLThcb9p/IC1uQ4yy0JbRnx3lkbhs+qGYjPRLbK643KKTrbXN0RoUKA== X-Received: by 10.194.141.98 with SMTP id rn2mr33729182wjb.1.1482954504758; Wed, 28 Dec 2016 11:48:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.185.10 with HTTP; Wed, 28 Dec 2016 11:48:23 -0800 (PST) In-Reply-To: <20161111193859.GJ3541@tucnak.redhat.com> References: <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> <20161111193859.GJ3541@tucnak.redhat.com> From: Cary Coutant Date: Wed, 28 Dec 2016 19:48:00 -0000 Message-ID: Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space To: Jakub Jelinek Cc: Jiong Wang , gcc-patches , GDB , Binutils , "Richard Earnshaw (lists)" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00436.txt.bz2 > I'd like to point out that especially the vendor range of DW_OP_* is > extremely scarce resource, we have only a couple of unused values, so taking > 3 out of the remaining unused 12 for a single architecture is IMHO too much. > Can't you use just a single opcode and encode which of the 3 operations it is > in say the low 2 bits of a LEB 128 operand? > We'll likely need to do RSN some multiplexing even for the generic GNU > opcodes if we need just a few further ones (say 0xff as an extension, > followed by uleb128 containing the opcode - 0xff). > In the non-vendor area we still have 54 values left, so there is more space > for future expansion. Most of the Gnu extensions have been adopted into the standard as of DWARF 5: /* GNU extensions. */ DW_OP (DW_OP_GNU_push_tls_address, 0xe0) /* The following is for marking variables that are uninitialized. */ DW_OP (DW_OP_GNU_uninit, 0xf0) DW_OP (DW_OP_GNU_encoded_addr, 0xf1) /* The GNU implicit pointer extension. See http://www.dwarfstd.org/ShowIssue.php?issue=100831.1&type=open . */ DW_OP (DW_OP_GNU_implicit_pointer, 0xf2) /* The GNU entry value extension. See http://www.dwarfstd.org/ShowIssue.php?issue=100909.1&type=open . */ DW_OP (DW_OP_GNU_entry_value, 0xf3) /* The GNU typed stack extension. See http://www.dwarfstd.org/doc/040408.1.html . */ DW_OP (DW_OP_GNU_const_type, 0xf4) DW_OP (DW_OP_GNU_regval_type, 0xf5) DW_OP (DW_OP_GNU_deref_type, 0xf6) DW_OP (DW_OP_GNU_convert, 0xf7) DW_OP (DW_OP_GNU_reinterpret, 0xf9) /* The GNU parameter ref extension. */ DW_OP (DW_OP_GNU_parameter_ref, 0xfa) /* Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFission. */ DW_OP (DW_OP_GNU_addr_index, 0xfb) DW_OP (DW_OP_GNU_const_index, 0xfc) Of these, I think only DW_OP_GNU_uninit and DW_OP_GNU_encoded_addr remain as Gnu extensions. The rest could be deprecated as of DWARF 5, and, if necessary, reused for other purposes in DWARF 6 and later. Depending on how aggressive we want to be with deprecation, we could even declare that they are available for reuse in DWARF 5 and later, as long as the Gnu toolchain uses only the new standard values when generating DWARF 5. That frees up 11 more opcodes. -cary