From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) by sourceware.org (Postfix) with ESMTPS id 4A5DE3858D37 for ; Mon, 23 Oct 2023 13:15:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4A5DE3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4A5DE3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c36 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698066929; cv=none; b=q77g5TzYVYfLiyCS7TklxqYJMsMpTeDoZSPysDoXWeAVSD7viw2P3C9x8hv2+WO5Cjc+iGbzcp9fFXp4fUA4vPJpaDB11UCYAH8gHx/5CK1YjnWXzK/bi9ygwytBiVeUyxpoC2rHKV1RA31Jqai5Tl/otvj2X+33vuNHo6tJxZo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698066929; c=relaxed/simple; bh=xfVvem/+BIPqJKf92Ist74BXwhyz2kR6vPMYNbhQG9o=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Kb/ZptX47xlcZDOCdWlmE0aZViDwnep3aQRJKId4R97GN5214Ktw9wZLKvGnAjbj67TRINxT3Jgt4iadGmR6IOdO9gZp3E/bNWVUpPwkuoQcFmMMQZGWUuwVbvzmM6+HKw2sx5fLIsFcXGyJ+sPDQ2nw0sArcXxE/hxe6SnzrJE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc36.google.com with SMTP id 006d021491bc7-57de6e502fcso2080419eaf.3 for ; Mon, 23 Oct 2023 06:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698066925; x=1698671725; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BAMsyCRssy7jw0o+SdODC72c3QC5RNMofx4+/LV9MHw=; b=lVDokN3w2o+rqm/78s8VZwnoWAwwkpvVMmk5ADN83y88rtJHcq51PYizErAw8x+YOY ahEFwPAEqten4HAUMD4kwjKUpsk2YHyOUgRF+oUsE+Qq+4jj+5jNG4WeLO2AiEAGcedn D45KuYnYEgViEUJWjzoHbjRuMuysnOc4jHXjQkinfF5+/zUdKJCUeimsJY4e2U8/2U/D 0MCmYyfqKfAemZTNKXfc1iwnvduCY7GRKAuTCR5sp7S+/rgf89DYJEBZrMpYfO0X2omd dBXT5gby6jtcvQzO08q22PgTnb7S7MKSmAGoJOCbtiv6JKwpcrMtKE3n8S3uC7CuBhry rgBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698066925; x=1698671725; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BAMsyCRssy7jw0o+SdODC72c3QC5RNMofx4+/LV9MHw=; b=ZJulMlHcOX84F/V8R6Z3O+6vbMS3bmr+YO+6IyZCMvIVW5MY8+NohHGadcx9UmcRZB W6g7ZDUfpzCM3CMApnB9xkbbFCnBASpicSsIdRehQ1JgVvdKyxOk0huyhRaebez5c7y6 +4rSHcHh3IqKXjhKxjGeOBt5udYtILeuYx0KM8clTKgWaASR7+ySH3PgsTAKOADA96qR HX6jlfs2HUZa1FY+abTWsO9q/ShblQukCwhY+hTJuTFe4JpPF2njoQ3hxvGKb0EoGqfB 73WygRxL0l1ia7ldjQya3XpXwvJdfJiS+sBbPEWAur5HpMmE6p9k+OnRCZVdU9NCWjEp qZag== X-Gm-Message-State: AOJu0Yx03e249kl3XrbVW8jH3o0I/sDrZzKjcXbQ2qWr7buDlnuUFYXu 6Ub9UAq4vc7sKxHUeL+PAigulbejSgvij68Z1us= X-Google-Smtp-Source: AGHT+IFXwZIn4K465i/XRj8lMGZfj91e91RriBT3Fp4kmHJc+7qd8Eyqc/wqeGl1dszvlJZaRG77luVdkZZAJ+EoVkU= X-Received: by 2002:a4a:b406:0:b0:57b:6f5c:c90a with SMTP id y6-20020a4ab406000000b0057b6f5cc90amr8062220oon.8.1698066925447; Mon, 23 Oct 2023 06:15:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rishi Raj Date: Mon, 23 Oct 2023 18:45:14 +0530 Message-ID: Subject: Re: [PATCH][WIP] dwarf2out: extend to output debug section directly to object file during debug_early phase To: Jan Hubicka Cc: rguenther@suse.de, gcc-patches@gcc.gnu.org, Martin Jambor Content-Type: multipart/alternative; boundary="000000000000e56de006086203f0" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000e56de006086203f0 Content-Type: text/plain; charset="UTF-8" On Mon, 23 Oct 2023 at 18:18, Jan Hubicka wrote: > Hello, > thanks for the patch. > > Overall it looks in right direction except for the code duplication in > output_die and friends. > > +/* Given a die and id, produce the appropriate abbreviations > > + directly to lto object file */ > > + > > +static void > > +output_die_abbrevs_to_object_file(unsigned long abbrev_id, dw_die_ref > > abbrev) > > +{ > > + unsigned ix; > > + dw_attr_node *a_attr; > > + > > + output_data_uleb128_to_object_file(abbrev_id); > > + output_data_uleb128_to_object_file(abbrev->die_tag); > > + > > + > > + if (abbrev->die_child != NULL) > > + output_data_to_object_file(1,DW_children_yes); > > + else > > + output_data_to_object_file(1,DW_children_no); > > + > > + for (ix = 0; vec_safe_iterate (abbrev->die_attr, ix, &a_attr); ix++) > > + { > > + output_data_uleb128_to_object_file(a_attr->dw_attr); > > + output_value_format_to_object_file(a_attr); > > + if (value_format (a_attr) == DW_FORM_implicit_const) > > + { > > + if (AT_class (a_attr) == dw_val_class_file_implicit) > > + { > > + int f = maybe_emit_file (a_attr->dw_attr_val.v.val_file); > > + output_data_sleb128_to_object_file(f); > > + } > > + else > > + output_data_sleb128_to_object_file(a_attr->dw_attr_val.v.val_int); > > + } > > + } > > + > > + output_data_to_object_file (1, 0); > > + output_data_to_object_file (1, 0); > > So this basically renames dw2_asm_output_data to > output_data_to_object_file and similarly for other output functions. > > What would be main problems of making dw2_asm_* functions to do the > right thing when outputting to object file? > Either by conditionals or turning them to virtual functions/hooks as > Richi suggested? > I think it's doable via conditionals. Can you explain the second approach in more detail? > > It may be performance critical how quickly we sput out the bytecode. > In future we may templateize this, but right now it is likely premature > optimization. > Cool. > > > > +struct lto_simple_object > lto_simple_object is declared in lto frontend. Why do you need to > duplicate it here? > > It looks like adding relocations should be abstracted by lto API, > so you don't need to look inside this structure that is > lto/lto-object.cc only. > I should have taken this approach, but instead, I exposed simple objects to dwarf2out. That's the reason to duplicate the above struct. I will take care of this while refactoring and abstracting it by lto API > > > +/* Output one line number table into the .debug_line section. */ > > + > > +static void > > +output_one_line_info_table (dw_line_info_table *table) > It is hard to tell from the diff. Did you just moved these functions > earlier in source file? > Yeah. I will refactor the dwarf2out soon to clear these confusions. -- Rishi > > Honza > --000000000000e56de006086203f0--