From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41249 invoked by alias); 15 Jul 2017 13:56:06 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 41233 invoked by uid 89); 15 Jul 2017 13:56:05 -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=-5.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy=association, Performance X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 15 Jul 2017 13:56:04 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 6531030272A0; Sat, 15 Jul 2017 15:56:01 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 55F3940E39E5; Sat, 15 Jul 2017 15:56:01 +0200 (CEST) Message-ID: <1500126960.14595.310.camel@klomp.org> Subject: Re: File index given line (libdw) From: Mark Wielaard To: Sasha Da Rocha Pinheiro Cc: "elfutils-devel@sourceware.org" Date: Sat, 15 Jul 2017 13:56:00 -0000 In-Reply-To: References: <1499937069.14595.215.camel@klomp.org> <1500026625.14595.238.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.12.11 (3.12.11-22.el7) Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00011.txt.bz2 On Sat, 2017-07-15 at 01:22 +0000, Sasha Da Rocha Pinheiro wrote: > >But why do you want to do that? >=20 > Performance and save memory space. >=20 > >If we would add int dwarf_line_index (Dwarf_Line *line, size_t *idx) how > >exactly would you use it? >=20 > I would get idx and save it in my data structure so I don't have to save = the file name repeatedly for each line. size_t and char * are the same size. Whether you use an index or a string pointer doesn't mean the underlying strings are identical or not. If you really need to know if they are equal you still need to compare the actual strings. > >A small example program would help to see what the exact semantics > >should be. > How it's currently being done : >=20 > 1. Dwarf_Files dfs <- dwarf_getsrcfiles > 2. for each file in dfs get name (with dwarf_filesrc) -> save in vector f= ilenames > 3. Dwarf_Lines dls <- dwarf_getsrclines > 4. for each line in dls get file name and "search this name in vector fil= enames" >=20 > We want to eliminate the "search this name in vector filenames", to > make it from L F log(F) to L, by getting the index and consulting the > file name of a line in the vector filenames directly. So you want to keep a vector with filenames for a particular CU. And then given Dwarf_Lines you want to associate each Dwarf_Line with a particular filename from that vector. Do you get the Dwarf_Line from dwarf_onesrcline() or dwarf_getsrc_die()? I assume you then use dwarf_linesrc() to get the filename associated with the Dwarf_Line. Why is it important to match this particular filename to one in the vector you created from the Dwarf_Files? There is indeed an association between the DwarfLines and the Dwarf_Files. But currently that is an implementation detail. If we expose the Dwarf_Line filename index associated with the Dwarf_Files then it becomes a public interface. I am not really that opposed to exposing this information. It might be fine. But I would like to understand why you need/want this information. Cheers, Mark