From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by sourceware.org (Postfix) with ESMTPS id 3365A381E5EF for ; Thu, 27 Oct 2022 15:39:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3365A381E5EF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb35.google.com with SMTP id i127so2536897ybc.11 for ; Thu, 27 Oct 2022 08:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q8OJcmAeniUhTy+Iz1+KWjwBaUwjhXV6+Xad1nmMr8o=; b=V91WUaPEsFBcCfiamilhRnkcvU8ini4PDrkS7cKY1sdHj+ABmwsarRzVDEI2EXwwmi 5FpmV7uBKoUDItyvlTUb/g9dNRJKOaasMqXIjqkM4S/sZpQpWAog90STU/ZRcuZQqTIx i8djzi9LyYVRoP4aRDZT4CQ0FlybVYkho8CBVcd5YxahetBVnQT5qEB234e2wNLukmwn f0zuGoSjRVtf2IHLV4G2MW+3XqDe/nnGXv/dTRl0A4ooP+cpzqFHBrYeaPGHezdygMFM 5C0Pa2dZmWvw2NPhm2PsaTP0wu5DNXL8cfzav58i8bsdp4qhOozzhDUGDQFFpGWIjKWB Drxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Q8OJcmAeniUhTy+Iz1+KWjwBaUwjhXV6+Xad1nmMr8o=; b=7Eo6p0F7dSwxHzIXeifOifhTKjXiBG7sSVIxj95RDeRzP2ewj6f0OgE1GfNvW/Pzs3 5eCL7CDSqPlm0KcQzXbIFRhhxBBFAK49gnEc3RGi6MW5siroPgsyi8xbLCC3PkgFCBoz nabYFsd6VDjAhLqlcTj1NvP2S4NhDwM8rBFH5GScJP15Z7rcuvAL28YrAMZmXQlFGwFY 30tXqlKRZuRdsY1Hy62+H4ObO1L+E3OtPuyG49bf2+DFhd5FJOe1Pv3rKce70HXWwuAg JqomEoyBDKLhQtCi5MyHi3VgREE0R/GZC/hv8YpgFmrFhbZML5DA8SJAzQUxtRKf3qLh Q0JQ== X-Gm-Message-State: ACrzQf3slO8lrEqcGcboV6gLrpIM45v+tB+BptxP2/NE4n/wdDYEi0BI iPbPsLy0ZVUPQweZRjObft2ZaWEn/YRtS+GByIiVXxmJ8Ng= X-Google-Smtp-Source: AMsMyM511qCAue/ijW3e7yjf80ycTAST86MnNw9uNzEjw1an142yajxlC0V1yqtZCAZ34BqoyP+9gt3yZbtVVt7+PlA= X-Received: by 2002:a25:c8a:0:b0:6be:3680:94ac with SMTP id 132-20020a250c8a000000b006be368094acmr46782326ybm.293.1666885187545; Thu, 27 Oct 2022 08:39:47 -0700 (PDT) MIME-Version: 1.0 References: <94fd668465b77e94f3c000982c694e7da8f828f1.camel@espressif.com> <986e64ece3a408ae81512f2c10484ea22c7d634f.camel@espressif.com> In-Reply-To: <986e64ece3a408ae81512f2c10484ea22c7d634f.camel@espressif.com> From: Max Filippov Date: Thu, 27 Oct 2022 08:39:36 -0700 Message-ID: Subject: Re: [PATCH 0/5] Add Xtensa ESP chips support To: Alexey Lapshin Cc: Alexey Gerenkov , Anton Maklakov , "binutils@sourceware.org" , Ivan Grokhotkov Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Alexey, On Tue, Oct 25, 2022 at 1:17 PM Alexey Lapshin wrote: > I uploaded changes to the github: > https://github.com/espressif/binutils-gdb/commits/feature/binutils-2_39-port-esp-chips Thank you. I have taken a look and have run a couple tests. It is nice to see an effort to improve the current state of the xtensa toolchain, however this series has a number of issues that I consider important and think that they must be addressed. First issue is that these changes break existing workflows for the xtensa toolchain customization. I believe that it is possible to add support for multiple xtensa cores without breaking the current configuration mechanism. Second issue is that these changes are not internally coherent. For example I would expect that choosing a core that we're assembling for would result in production of an object file with correct endianness for the chosen core, but this is not the case: xtensa-elf-as --isa-module=esp32 will produce an object file marked as elf32-xtensa-be. New switches that control endianness only do partial job, affecting literals and data, but not instructions (which they cannot do by design). There's an --isa-module switch for the assembler, but nothing matching it for the objdump. To experience the issue try to assemble the 'salt' instruction (available in esp32s3) and get it back from the disassembler. Recording core ID in the .xtensa.info section is a clever idea that could potentially help in this situation, but 1) AFAICT it is not used for that purpose now and 2) what's the option for disassembling code that lacks the .xtensa.info? Also, recording the sequential number in this section doesn't look like the right choice to me. The switches --[no-]booleans and --[no-]loops are not really documented and AFAICT they do nothing at this point. They don't control which code is accepted or generated, they only affect available relaxation transformations, but I don't see any transformations that depend on the presence of the boolean option or zero overhead loops. There are remaining core-specific macros, like XCHAL_HAVE_BE in the code that is only compiled once, which means that this code gets definitions for these macros from the default configuration, leaving the reader of this code with the question "how is it supposed to work for cores that define these macros differently"? Third issue is related to the second, this series adds support for the new cores meaning that other interested parties could follow suit, but since it's done incoherently it does not set the right example that could actually be followed. I still think that the series that I posted back in 2017 here https://sourceware.org/pipermail/binutils/2017-May/098159.html was a step in the right direction, providing basis for dynamic configuration, yet not excluding the opportunity to have core support built into the toolchain. It's a shame that I couldn't complete it back then, I guess I should try to do it this time. -- Thanks. -- Max