From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12879 invoked by alias); 12 Jun 2009 16:43:28 -0000 Received: (qmail 12871 invoked by uid 22791); 12 Jun 2009 16:43:27 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Jun 2009 16:43:18 +0000 Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id n5CGhELv032604 for ; Fri, 12 Jun 2009 17:43:15 +0100 Received: from an-out-0708.google.com (anac38.prod.google.com [10.100.54.38]) by spaceape10.eur.corp.google.com with ESMTP id n5CGhCww013530 for ; Fri, 12 Jun 2009 09:43:13 -0700 Received: by an-out-0708.google.com with SMTP id c38so1174670ana.14 for ; Fri, 12 Jun 2009 09:43:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.4.8 with SMTP id 8mr5093153and.180.1244824992611; Fri, 12 Jun 2009 09:43:12 -0700 (PDT) In-Reply-To: <20090612005149.GA4987@caradoc.them.org> References: <200906080310.58102.vladimir@codesourcery.com> <200906111229.04020.vladimir@codesourcery.com> <8ac60eac0906111014y67049cb9vb5048acf2939373b@mail.gmail.com> <20090612005149.GA4987@caradoc.them.org> Date: Fri, 12 Jun 2009 16:43:00 -0000 Message-ID: Subject: Re: Registering pretty-printers From: Doug Evans To: Paul Pluzhnikov , Vladimir Prus , tromey@redhat.com, gdb@sources.redhat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00121.txt.bz2 On Thu, Jun 11, 2009 at 8:51 PM, Daniel Jacobowitz wrote: > In my opinion, anything that increases the size of the executable is a > non-starter. =A0I don't think there's any reliable way to create a > non-allocatable section, and it would have other problems, like > duplicate elimination. Reliable in what sense? [I realize the term is pretty unambiguous. I'm guessing I'm missing something as it doesn't seem to be excessively hard for many important targets.] Or did you mean portable? As for duplicate elimination, I'm reminded of the new comdat types support in DWARF 4: Type debug info is put in comdat sections with a signature computed from the type. The linker removes all duplicates and the result ends up in the .debug_types section. Employing a similar thing here would solve that it seems. It might even be cool to use the same signature. It avoids wheel re-invention, and uses something documented and well-vetted. And maybe the pretty-printer registration could be based on the type signature. OTOH the signature wasn't really intended for anything else so hijacking it may be problematic. [Just thinking out loud ...] Not saying there aren't other problems though. OTOH, I wouldn't mind seeing a couple of paradigms for registering pretty printers if it means targets that can handle better solutions aren't left to suffer to the lowest common denominator.