From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21356 invoked by alias); 17 Jul 2017 04:11: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 21337 invoked by uid 89); 17 Jul 2017 04:11: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=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RP_MATCHES_RCVD,SPF_PASS 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: smtpauth4.wiscmail.wisc.edu Received: from wmauth4.doit.wisc.edu (HELO smtpauth4.wiscmail.wisc.edu) (144.92.197.145) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jul 2017 04:11:03 +0000 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) id <0OT700A00V53GG00@smtpauth4.wiscmail.wisc.edu> for elfutils-devel@sourceware.org; Sun, 16 Jul 2017 23:11:01 -0500 (CDT) X-Spam-Report: AuthenticatedSender=yes, SenderIP=216.32.181.19 X-Spam-PmxInfo: Server=avs-4, Version=6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.7.17.40017, AntiVirus-Engine: 5.38.0, AntiVirus-Data: 2017.6.22.5380000, SenderIP=216.32.181.19 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0019.outbound.protection.outlook.com [216.32.181.19]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPS id <0OT700LA4VMCQH10@smtpauth4.wiscmail.wisc.edu>; Sun, 16 Jul 2017 23:11:01 -0500 (CDT) Received: from CY1PR0601MB1691.namprd06.prod.outlook.com (10.163.232.29) by CY1PR0601MB1692.namprd06.prod.outlook.com (10.163.232.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 04:10:59 +0000 Received: from CY1PR0601MB1691.namprd06.prod.outlook.com ([10.163.232.29]) by CY1PR0601MB1691.namprd06.prod.outlook.com ([10.163.232.29]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 04:10:59 +0000 From: Sasha Da Rocha Pinheiro To: Mark Wielaard Cc: "elfutils-devel@sourceware.org" Subject: Re: File index given line (libdw) Thread-topic: File index given line (libdw) Thread-index: AQHS+25iE5CfcOrVI0yo3Q9kgzQif6JReRGAgACIteeAARhSgIAA+vQzgADYRQCAAoC2cg== Date: Mon, 17 Jul 2017 04:11:00 -0000 Message-id: References: <1499937069.14595.215.camel@klomp.org> <1500026625.14595.238.camel@klomp.org> <1500126960.14595.310.camel@klomp.org> In-reply-to: <1500126960.14595.310.camel@klomp.org> Accept-Language: en-US, pt-BR Content-language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [24.177.125.192] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;CY1PR0601MB1692;7:+1K1hl5gDclf0Dc65Qywli7Z1ga/0byhKEuLwCJSF3QDFGEIucOjVMkM3DM8x5olWIl48VJbouXHngrw/9CctrcEm9AbCAyK1pxLHHgsIfCARlxNtITCTLox5ZXEe7DOajOxPbpDSLlXF2sK8MAQBL7+B+Walkgtt7eaAszjFh+/moSZupZ5btHmpiJgqvsZ26p+g2YE5GmovVeTTOBplne+B3R1EoP3F1wX6voG11dnD6Qa6tD9v14XejBv/IQSDPbrdU1eijXDktOx5fogzXVTR56qQuDJqARlvcNlqjxARpNxFkyD0cNg+J+5bI6e5MT0jcVYqA5lpibufb9xN4m/75k8iUCo/V5n/It/JoFzFcJUj/EBV/bfk5BE3UpAYzHHevAm/+zCOnU1IU3T2mDXPNRMSswLPnxEfsJpZGmQeHwOU28QZhOTFjAnL9arnyj5UB6Gy9Lt1Ahm3z9Zy/8eDsgekAuK8xVyvjt1HGfBAkItym0OCLfrN2vFhGcMlpdCa5C16BYoPjzh2eqd0XQFyiQV+UDmbL9ZU6nch0fuUyGxbzYJ47O0f8yja7C1iAeulBCYmFEN2cO5Ra9OU18f/6I/4EI3inUmPp6z34M4/CDu63iE6DftkNw9mPmaByMgSeuHPgRIHSwkEGttghCe9sOtr/re6zmAQLx0fNMNyZ2AOz2ufjczskB/efPvlcM4BREWFAhKbmhjH5UssxuRtztd0F/6IhVRjjUkFZQwHC/jh5dn7y1ZDkPbd7QJwA+MNj7rwxBe4mRv9Wq7ALPISlxHuLdt8eNHVClwoy4= x-ms-office365-filtering-correlation-id: e405531d-f808-4993-ff61-08d4ccc9d46e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY1PR0601MB1692; x-ms-traffictypediagnostic: CY1PR0601MB1692: x-exchange-antispam-report-test: UriScan:(236129657087228)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR0601MB1692;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR0601MB1692; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39450400003)(39850400002)(39410400002)(39400400002)(39840400002)(39860400002)(377454003)(377424004)(24454002)(74316002)(77096006)(305945005)(33656002)(66066001)(2900100001)(2906002)(8676002)(81166006)(5660300001)(14454004)(3660700001)(75432002)(88552002)(6436002)(8936002)(7736002)(3280700002)(6916009)(6116002)(2950100002)(102836003)(3846002)(229853002)(93886004)(38730400002)(55016002)(6246003)(7696004)(53546010)(99286003)(110136004)(86362001)(53936002)(50986999)(76176999)(9686003)(6506006)(478600001)(54356999)(189998001)(4326008)(25786009);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR0601MB1692;H:CY1PR0601MB1691.namprd06.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-transfer-encoding: quoted-printable X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 04:10:58.7216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1692 X-SW-Source: 2017-q3/txt/msg00013.txt.bz2 [Resending cause it seems it didn't go] You understood what I need when you said: "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." I agree with this "But currently that is an implementation detail. " But I don't see why this would change. Deliberately sort the files names so= it doesn't match with the lines? I don't think so. What I need is direct access to the files I already have from a previous ca= ll to eliminate unnecessary search. "Why is it important to match this particular filename to one in the vector= you created from the Dwarf_Files?" Because Dyninst needs to make its own parsing and fill its own data structu= res in the most efficient way. From: Mark Wielaard Sent: Saturday, July 15, 2017 8:56 AM To: Sasha Da Rocha Pinheiro Cc: elfutils-devel@sourceware.org Subject: Re: File index given line (libdw) =A0=20=20=20 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 =20=20=20=20