From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16914 invoked by alias); 15 Sep 2012 22:03:45 -0000 Received: (qmail 16895 invoked by uid 22791); 15 Sep 2012 22:03:44 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_XF X-Spam-Check-By: sourceware.org Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 15 Sep 2012 22:03:26 +0000 Received: by daks35 with SMTP id s35so3192420dak.20 for ; Sat, 15 Sep 2012 15:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=kjn3t9husDYrC72L/cJV9f4XW3NnW44+jbffKzW781s=; b=Xk+0AxTweWALln1uUDq14Mv9IkjnUxB/TmldUYWe575DXz1WuaLE7qW1c+6VPZNWIC R7lSdhhLao6AQXciFmiy4ZD1Nr/2yWUpe1mnAIDIYoArGaP2A9r+Z/YERCH6IBKO+txP dfymyh8ZLKMdFf2HuwnW9f9Fi/gsNkvxHOxuvmd32GpTrPVoJJQpYsOYU7AB/qeHpxH9 RTQbVyxuBq09T5VCQDUYl3Pct2J66kpexMHhwa8ZJR9d+pMG3aXpwzI7i6jijEBDxQmM cwSphCsgLuUeSX0IprnjLQxzZV/4XmNeiRubSeKBPpS8aBhS9IREtbOEgQJfJC30g3FT R05w== Received: by 10.66.85.167 with SMTP id i7mr10963852paz.8.1347746605581; Sat, 15 Sep 2012 15:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.85.167 with SMTP id i7mr10963828paz.8.1347746605356; Sat, 15 Sep 2012 15:03:25 -0700 (PDT) Received: by 10.68.200.41 with HTTP; Sat, 15 Sep 2012 15:03:24 -0700 (PDT) In-Reply-To: References: <50243480.7090803@redhat.com> <50254A50.8070208@redhat.com> <50255B35.9020705@redhat.com> <50258712.4070002@redhat.com> <502E6774.8050609@redhat.com> <503F7876.7030606@redhat.com> <503F84A9.8010504@redhat.com> <503F95D8.5010506@redhat.com> <50463661.1020303@redhat.com> <1346839095.9368.1.camel@springer.wildebeest.org> Date: Sat, 15 Sep 2012 22:03:00 -0000 Message-ID: Subject: Re: [PATCH] Set correct source location for deallocator calls From: Dehao Chen To: "H.J. Lu" Cc: Andrew Pinski , Mark Wielaard , Bryce McKinlay , Andrew Haley , Richard Henderson , Jason Merrill , Richard Guenther , GCC Patches , David Li , java@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmObO5Y/VPXjgmMtggPBC/6gKVlkwk34LU9yZHV/Zzv8UVp8JPT4nHLzIShavz1X0QFkOEQAUz0gY2nDja9HoDXIXMv766Nhu660/bl4hukAOn6nrGYi5VqWgZCyQPBq1YbN2Wq42i63OLv9Mqcew68VhgKXXvjRQPpUOkKTmGWW8o25GsFjB67GWVEU6YJkeDt+tc0 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2012-09/txt/msg00023.txt.bz2 Yeah, in dwarf2out.c: 4590 add_AT_low_high_pc (dw_die_ref die, const char *lbl_low, const char *lbl_high, ...... 4604 if (dwarf_version < 4) 4605 attr.dw_attr_val.val_class = dw_val_class_lbl_id; 4606 else 4607 attr.dw_attr_val.val_class = dw_val_class_high_pc; . dw_val_class_lbl_id is handled: 7984 case dw_val_class_lbl_id: 7985 dw2_asm_output_addr (DWARF2_ADDR_SIZE, AT_lbl (a), "%s", name); 7986 break; dw_val_class_high_pc is handled: 8027 case dw_val_class_high_pc: 8028 dw2_asm_output_delta (DWARF2_ADDR_SIZE, AT_lbl (a), 8029 get_AT_low_pc (die), "DW_AT_high_pc"); 8030 break; The dwarf4 specification says: If the value of the DW_AT_high_pc is of class address, it is the relocated address of the first location past the last instruction associated with the entity; if it is of class constant, the value is an unsigned integer offset which when added to the low PC gives the address of the first location past the last instruction associated with the entity. However, I'm not sure how to tell how the DW_AT_high_pc's class is represented... Maybe it's the bug in the gcc dwarf implementation? Dehao On Sun, Sep 16, 2012 at 2:06 AM, H.J. Lu wrote: > On Sat, Sep 15, 2012 at 9:09 AM, Dehao Chen wrote: >> I tried the up-to-date addr2line on any "gcc -g" generated code, it >> does not work either. This is because in the new dwarf, the >> DW_AT_high_pc now actually means the size. e.g. >> >> <1><9b>: Abbrev Number: 2 (DW_TAG_subprogram) >> <9c> DW_AT_external : 1 >> <9c> DW_AT_name : bar >> DW_AT_decl_file : 1 >> DW_AT_decl_line : 8 >> DW_AT_linkage_name: (indirect string, offset: 0x7b): _Z3barv >> DW_AT_type : <0x8d> >> DW_AT_low_pc : 0x400583 >> DW_AT_high_pc : 0x37 0x0 >> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) >> DW_AT_GNU_all_call_sites: 1 >> DW_AT_sibling : <0xff> >> >> However, addr2line still thinks DW_AT_high_pc means "high_pc". I think >> we should wait for binutil to catch up with gcc. >> > > So, the meaning of DW_AT_high_pc in DWARF4 is different > from DWARF3? > > -- > H.J.