From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id 492493858D1E for ; Wed, 11 Oct 2023 16:07:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 492493858D1E Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id D26A02859B0; Wed, 11 Oct 2023 18:07:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1697040442; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iDlG8v0HQAAZtap50fp0ihy9KEgdCfSfg4w9DXvsuNY=; b=DkIZAXFpPmNFgWzmMvogGTReXzO4hccXzwxRmuzxIr6Yt11TDppoohKOCw+80HZlpHxdD1 ea5/M0i8TmFCCJwNNsXJHBUxGBQ9H1OyQ9VJAqxAIElAWfg3TqXHA1OrJrXQOtPNISgG3H IBWUpt71AsDWLr4V9Y0DHjQWgRxf6Zs= Date: Wed, 11 Oct 2023 18:07:22 +0200 From: Jan Hubicka To: Rishi Raj Cc: Martin Jambor , Richard Biener , gcc@gcc.gnu.org Subject: Re: Clarification regarding various classes DIE's attribute value class Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Hello, > I am working on a project to produce the LTO object file from the compiler > directly. So far, we have > correctly outputted .symtab along with various .debug sections. The only > thing remaining is to > correctly output attribute values and their corresponding values in the > .debug_info section. This is done by the output_die function in > dwarf2out.cc based on the value's class. However, the same > function is used in dwarf2out_finish as well as dwarf2out_early_finish, so > I suspect that not every value class is being used in dwarfout_early_finish > (mainly I am interested in -flto mode). As there is little documentation on > the same, I experimented by commenting out the various cases of value class > in output die. I found that the classes such as dw_val_class_addr, > dw_val_class_high_pc, and dw_val_class_vms_delta aren't being used during > the early_finish of LTO mode. I might be wrong, as my observation is based > on commenting out and testing a few pieces of code that might need to be > completed. So, can anyone please tell out of these 30 classes that are > relevant to dwarf2out_early_finish in LTO mode or at least point out some > documentation if it exists? You can probably do gcc_assert (!in_lto_p && flag_lto && !flag_fat_lto_objects) on parts of output_die which you think are unused and then do make check and if it passes also make bootstrap. That should probably catch all relevant cases. Honza > enum dw_val_class > { > dw_val_class_none, > dw_val_class_addr, > dw_val_class_offset, > dw_val_class_loc, > dw_val_class_loc_list, > dw_val_class_range_list, > dw_val_class_const, > dw_val_class_unsigned_const, > dw_val_class_const_double, > dw_val_class_wide_int, > dw_val_class_vec, > dw_val_class_flag, > dw_val_class_die_ref, > dw_val_class_fde_ref, > dw_val_class_lbl_id, > dw_val_class_lineptr, > dw_val_class_str, > dw_val_class_macptr, > dw_val_class_loclistsptr, > dw_val_class_file, > dw_val_class_data8, > dw_val_class_decl_ref, > dw_val_class_vms_delta, > dw_val_class_high_pc, > dw_val_class_discr_value, > dw_val_class_discr_list, > dw_val_class_const_implicit, > dw_val_class_unsigned_const_implicit, > dw_val_class_file_implicit, > dw_val_class_view_list, > dw_val_class_symview > }; > > -- > Rishi