From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E817D395BC6C for ; Wed, 16 Nov 2022 17:22:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E817D395BC6C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668619378; 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=lZM8npDDM8kEjPFJ0WWWLpbvyYFLTgVFupnK4MkiPRQ=; b=OaDO+m+AAd8Pd6u120w8LkKNugt6S/y8PtkvB7LV92xIDpT6TkkkAIrNN1mN9wlUFp2wey rLRv9RphBAlHa9MulOc2z/Zpf3L3bjHXrk6jGktwqDrzNB6dx7Uxwm4HHrtmaSittjslAL qUA7eDOEOy220NuJwe2DTa/faECaO3c= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-90-bkPW_XTdOba2bAPxethOxw-1; Wed, 16 Nov 2022 12:22:55 -0500 X-MC-Unique: bkPW_XTdOba2bAPxethOxw-1 Received: by mail-qk1-f199.google.com with SMTP id u5-20020a05620a0c4500b006fb30780443so15843305qki.22 for ; Wed, 16 Nov 2022 09:22:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :organization:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lZM8npDDM8kEjPFJ0WWWLpbvyYFLTgVFupnK4MkiPRQ=; b=g9EdaEJG00T6WA1Xf5WMkQNBuLHIj+P1UVZQm6gGY8IoLkJYtpz5652fwXBg+ev198 Z8FQe8fyu9fLR4B3BIlwvHBtYH47I13aBzRmg88sKG3SPoCpzpiWeFpNwO8k4DZpoZrP DDQvXZkN3HYpNrhSxdQqXY+RM0ebRD1czgH0jAokHvwjayy0B+yVRFdQkvNJ4GLn1Agg se/MMLvsg/B6Nn3UAl4ugI3SX0ueadI33fPITgZNtKBQhxH3KoaVDqHbZg978cPKsCxz Pr67x+gNNQYiSpWJkxFHv7V4SRCPoMq1P3G0jkQe+rES9jEM+957KAqjqVUQ+V2vi4MU 81Fw== X-Gm-Message-State: ANoB5pk3Kj3afQqLufy5z3vuGhQUwO/8ECWG/DXGxVydUjq/LT/s6Adq SiS+iVvr8wJ+POvep9+ef8WbXtFEtSKw87t9VPoi2eaMcj83/HJy7PxjcaLhRAm7vk9VDoUWUnx Kr1JkBpPQVO/WdBUbcM2B X-Received: by 2002:a05:622a:4295:b0:3a5:82a6:5b4f with SMTP id cr21-20020a05622a429500b003a582a65b4fmr22311929qtb.392.1668619374451; Wed, 16 Nov 2022 09:22:54 -0800 (PST) X-Google-Smtp-Source: AA0mqf69bFbuM7wUtlp4X0Cx2JH9ybqiepX1G1kYfapaa32vRXZJgVUb7Anicn3pCvVUavwtfug3yw== X-Received: by 2002:a05:622a:4295:b0:3a5:82a6:5b4f with SMTP id cr21-20020a05622a429500b003a582a65b4fmr22311910qtb.392.1668619374230; Wed, 16 Nov 2022 09:22:54 -0800 (PST) Received: from localhost ([88.120.130.27]) by smtp.gmail.com with ESMTPSA id t6-20020a05622a180600b00343057845f7sm9088375qtc.20.2022.11.16.09.22.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Nov 2022 09:22:53 -0800 (PST) Received: by localhost (Postfix, from userid 1000) id 111EE581D10; Wed, 16 Nov 2022 17:53:07 +0100 (CET) From: Dodji Seketeli To: Ben Woodard Cc: Dodji Seketeli , libabigail@sourceware.org Subject: Re: [PATCH 1/1, RFC] Make Front Ends first class citizens Organization: Red Hat / France References: <87lep4os22.fsf@redhat.com> <87h6zsorrf.fsf@redhat.com> <4ea03406-a9c9-7bc8-aeaf-cdcba82ef42a@redhat.com> X-Operating-System: Fedora 38 X-URL: http://www.redhat.com Date: Wed, 16 Nov 2022 17:53:07 +0100 In-Reply-To: <4ea03406-a9c9-7bc8-aeaf-cdcba82ef42a@redhat.com> (Ben Woodard's message of "Mon, 31 Oct 2022 09:02:09 -0700") Message-ID: <87o7t6on7w.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: Ben Woodard writes: > Overall sounds like a good logical design. Thanks! [...] >> That class provides properties and behaviours that are shared by all >> front-ends that libabigail supports today. Namely, that class >> provides access to (properties of) the ABI corpus, corpus groups, > > I follow you up to to the point where you get to corpus groups. It is > not immediately obvious to me why corpus groups are included there. To > me corpus groups are some sort of container of corpuses (or corpora - > if you speak latin) not something that lives inside corpus fe_iface. That paragraph is poorly worded, at least. I have updated it in the newer version of the patch that I'll be posting soon. What I wanted to say is that the ABI being built by the front-end is accessible from the front end interface. That ABI being built is either a corpus or a corpus group, depending on the binary we are looking at. In general, we are only interested in an ABI corpus. Corpus groups are for cases where we are looking at, for instance, an application that loads plugins, like the Xorg server, the Gimp application or something like the Apache web server or, the Linux Kernel (vmlinux + modules). [...] >> Lastly, there is an ABIXML front-end which class is named >> abigail::abixml_reader::reader. It inherits the abigail::fe_iface >> class directly. Note that unlike the two previous front-ends, this >> one doesn't inherit the elf_based_reader base class, for reasons that >> should be obvious to the astute reader by now. So, this front-end >> implements the abigail::fe_iface::load_corpus() abstract interface to >> load the properties for the ABI corpus represented in the ABIXML >> format, construct the internal representation and pass it to the >> middle-end for further analysis. > > How about just calling it just abigail::abixml. I ended up putting it into the abigail::abixml namespace, indeed. It's called abigail::abixml::reader now, in the next version of the patch. > There is also a abixml writer backend, and I think that having all > that code in in one place would be good. I haven't re-organized backends, as I haven't thought about those yet. I guess when people come up with, for instance, another ABI serialization format that is worth supporting, the question of supporting several of those will arise. Thank you for mentioning that topic. > Furthermore, abixml isn't always the most handy format. It is > certainly not very compact. If CTF or BTF are all that they claim to > be, then maybe having a binary file format using them would be more > compact. The thing is to make CTF and BTF stand alone and usable by > other tools you would need to have a simple ELF wrapper around them > similar to the .gnu_reflink split DWARF format for debuginfo. So it > would probably make sense to have abigail::elf_based_handler (renamed > from elf_based_reader) and then have the classes which can write > multiple inherit from another abstract class like abigail::be-iface > which contained the writing functions. Having the reading and writing > code in the same class would be a clean design. Yeah, we will see. [...] Thanks a lot for your review. I'll be sending out a new version of the patchset with the update; Cheers, -- Dodji