From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5366 invoked by alias); 18 Mar 2014 00:25:39 -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 5356 invoked by uid 89); 18 Mar 2014 00:25:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ve0-f180.google.com Received: from mail-ve0-f180.google.com (HELO mail-ve0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Mar 2014 00:25:36 +0000 Received: by mail-ve0-f180.google.com with SMTP id jz11so6141079veb.39 for ; Mon, 17 Mar 2014 17:25:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9bDjHekYAzm3O7SBlNwvpsAJ3N2RbTLy1pOiH9OUBvk=; b=LDJ7Vz0aicWoSmVWj99JGiX2Lcenk0gDSMWVrsd5IKOhLCUSSDHcvPDWl9sUcSCd1N vIXAMDXNcUxia2WKo/WUYdnyZsFshSQJ6RotK0T43nOT+wjlERejVClJoaMcdOZZc1sV KybTZOOwnOIagQrWtluWV6g2bj8k5JYSnQjBUajSQNsskUbnfPpZYfMRtKKfwOTEEkXQ GMC+jlBmcC8+k/xQRnU9Iowx/t7uUjdqJ5KDL5hPHs5Hrqo0q1kVVABS4t3mM1dTDQyl t1kkyALAmvAIAe7E7dr/ak8EAQbSnQf8eWz42oXo94WGH4iThfqaw1j6ci0qoOqB/SFw 0SAQ== X-Gm-Message-State: ALoCoQlfQf79BmEY1a62RqqpAFk4vvpXfkhYPDsCOhzWOLM/XqjOJSmJlwBo951/2g1GcQeBuYrZaXSZ5rXlcRYjVxsZYhhyCpNjPhArJI552Nju6CyW0ggIoGjRtRyk8L3D2N1tSNvu3CzZBeBeYZhxChI1c6uCe1dg8wiOLXp/o8refRsKw4FrgQqdjgKMZm3jjJyELFYbGTpSPPi7dtwm7pKFUQOFEA== MIME-Version: 1.0 X-Received: by 10.58.248.163 with SMTP id yn3mr1559248vec.0.1395102334489; Mon, 17 Mar 2014 17:25:34 -0700 (PDT) Received: by 10.52.13.101 with HTTP; Mon, 17 Mar 2014 17:25:34 -0700 (PDT) In-Reply-To: <2739108.yJ4Vgng9gv@ws-gergap> References: <7365721.BnaR1nHazz@lt-gergap> <10414444.6eOdp1cvY6@ws-gergap> <2739108.yJ4Vgng9gv@ws-gergap> Date: Tue, 18 Mar 2014 00:25:00 -0000 Message-ID: Subject: Re: New feature "source-id" From: Doug Evans To: Gerhard Gappmeier Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00403.txt.bz2 On Mon, Mar 17, 2014 at 12:01 PM, Gerhard Gappmeier wrote: >> > example vcsinfo.c: >> > /* this file was genarated, bla bla, don't modifiy */ >> > static const char vcs_type[] = "git"; >> > static const char vcs_url[] = "git@github.com:gergap/source-id.git" >> > static const char vcs_version[] = >> > "c2ec66e6a36451ba47422d186fd97311989ef278" >> I think its weird to store this in .rodata instead of somewhere it can >> be easily stripped, especially if you plan on adding the sha1 file >> hashes through this same mechanism, since that is a less constant >> size, though you did mention adding that to the debug info >> specifically. > I agree. That's a good point. I think we should stay with the original idea of > having a .note section. It is also more consistent with the build-id feature. I agree the consistency of .note is nice, but I wouldn't preclude people wanting something different. Getting something into a .note section may involve more build changes than some group may want to take on. > Another argument against adding this to the source might be code size. For > small programs on embedded devices memory matters, so saving these strings > would be a benefit. The .note section can be stripped and the feature would > still work with the "separate-debug-info" approach. Technically, even if the info was added to the source (so to speak), it needn't affect code size. I can imagine all of these (so called) global variables being put in a specific section which is put in a non-loadable segment. The solution in gdb needn't preclude any implementation, that is up to the script. So, assuming the community wants this feature, let's separate out how the source information is obtained from how gdb uses it. btw, If Python doesn't have a library for reading ELF files, it should. Thus we needn't hardcode anything about where the data lives into gdb - leave it to the externally supplied script.