From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6LcAMxXgPWBtNwAAWB0awg (envelope-from ) for ; Tue, 02 Mar 2021 01:49:57 -0500 Received: by simark.ca (Postfix, from userid 112) id C22941EF78; Tue, 2 Mar 2021 01:49:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=MAILING_LIST_MULTI,RDNS_NONE autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1D5711E789 for ; Tue, 2 Mar 2021 01:49:57 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 789F83857C48; Tue, 2 Mar 2021 06:49:56 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id ECB683857C48 for ; Tue, 2 Mar 2021 06:49:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ECB683857C48 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 04F32AC24; Tue, 2 Mar 2021 06:49:54 +0000 (UTC) Subject: Re: [RFC][gdb/symtab] Add DW_IDX_GNU_main_subprogram To: Tom Tromey References: <20210129154749.GA15479@delia> <87k0rm5ygc.fsf@tromey.com> <063bff26-f377-6e50-b1ce-d9e74b2d37cf@suse.de> <87r1kyfhwz.fsf@tromey.com> From: Tom de Vries Message-ID: Date: Tue, 2 Mar 2021 07:49:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <87r1kyfhwz.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 3/2/21 2:44 AM, Tom Tromey wrote: > Tom> Fix this by adding a GNU extension DW_IDX_GNU_main_subprogram to the name > Tom> index attributes, encoded using a number in the DW_IDX_lo_user-DW_IDX_hi_user > Tom> range. > > I had a hilarious idea for this tonight, which is to stuff the main name > into the augmentation string. Right now the augmentation string is just > "GDB", but we could do something like "GDB:name_of_main"; then extract > that when reading. That's a fun idea indeed. I wonder though about backward compatibility. We have: ... /* DWARF-5 augmentation string for GDB's DW_IDX_GNU_* extension. */ static const gdb_byte dwarf5_augmentation[] = { 'G', 'D', 'B', 0 }; ... /* augmentation_string_size - The size in bytes of the augmentation string. This value is rounded up to a multiple of 4. */ uint32_t augmentation_string_size = read_4_bytes (abfd, addr); addr += 4; map.augmentation_is_gdb = ((augmentation_string_size == sizeof (dwarf5_augmentation)) && memcmp (addr, dwarf5_augmentation, sizeof (dwarf5_augmentation)) == 0); ... So as soon as we use this idea, the augmentation_string_size will be bigger, and the index will no longer be recognized by older gdb as being a gdb index, so DW_IDX_GNU_internal/external will be ignored. [ There's also a use in create_cus_from_debug_names_list, but that doesn't look like any functionality will be broken. ] One might say though that this is an actual gdb bug. The dwarf standard says that the "string _begins_ with a 4-character vendor ID". So the code should not check for augmentation_string_size == sizeof (dwarf5_augmentation). Anyway, to support any older reader that does the right thing, we'd need to use "GDB\0name_of_main" or some such. For future extensibility, we might consider encoding the type of data using a char, like so "GDB\0M:name_of_main". Thanks, - Tom