From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by sourceware.org (Postfix) with ESMTPS id 1C85A385D0D0 for ; Fri, 28 Oct 2022 15:48:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1C85A385D0D0 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-xb31.google.com with SMTP id 63so6584258ybq.4 for ; Fri, 28 Oct 2022 08:48:27 -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=p/g6Cqh5HTpwQSsTTLc6BlzzU4R1+umVLrV94lZT2pY=; b=mSJ7xW9nWJkQ7mqsg4xwOYFDHiiuOMkRxDX6HTELoi+LtjfL19aYXM64N87ZsHdvF3 qWh40oPHlHq7b7D99AJ14xRKsJPYIzffSrDTH+BDbKMaHpGJHC+r0ZZiEwPJoigd2nGG 5XJVUNU5PW/1ybR/4fDBGnFcgJDTwdoOJWyq72zQx/0AMuBf3n2W/56mRE5BH9sYyvaV +yUN0g2RGW6RcrX3Dzrvngqzdnqe/pHJOy53FinWHy44mubske7Z5uIE112w7vIrVRlJ zkIbm9YX99p6gpqs63mbvAJdGSteBLZkN+Bp8vLMfJXYm8L0YEF87nHvEmK3YgR8IrHA 0sJA== 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=p/g6Cqh5HTpwQSsTTLc6BlzzU4R1+umVLrV94lZT2pY=; b=b9nJUysvwZwRSWZZhVIr9nw7LNM+YEW7VH3YDP2gjSZH3Qph7EiDU9MK8UYkXwIFmZ erC9WdqTqN5MPyJp2TDrQD9ufkdgX4YubD57v7e3Or4Gssmh2cjWNx+OYbuTaZZiEBcZ VGYtfWEREkVih3w7b30XRG2VAb4/pMJcGXaFip9dqJY8l2DyoeSNmhW6Ip0OiufG1sDW dF/ksLx3vOyCb94mbhkHlJeSHC0C31eY5J3wMJjAS/aqsaFKtGO3sxc/g3CVk3lls8+M PZRS86oyKv1zQk/LwWFMGOxSsK6OSaDEdO/vzUCgdbQcVWH2KVjRZ2MAHvD6fWhkL+XT zSoA== X-Gm-Message-State: ACrzQf1T7gQ/rOHVks485AZS39lAhcdacWNybnc0AGngmW3xCo6Pw8P0 OsTNhoYB0CwjaKUqTCaZA3QMqPbOLmWe/IC5Su8= X-Google-Smtp-Source: AMsMyM4O2mLvTmU1m6pggMuyV6qEkq/iu9mp3Dp3hZ8h4/5mJrLTTdT9aptNSoCNqAxabR3CiLsHhqCqwwMymz/e3C4= X-Received: by 2002:a25:9b43:0:b0:6b3:9cc2:a651 with SMTP id u3-20020a259b43000000b006b39cc2a651mr49100117ybo.485.1666972106340; Fri, 28 Oct 2022 08:48:26 -0700 (PDT) MIME-Version: 1.0 References: <94fd668465b77e94f3c000982c694e7da8f828f1.camel@espressif.com> <986e64ece3a408ae81512f2c10484ea22c7d634f.camel@espressif.com> In-Reply-To: From: Max Filippov Date: Fri, 28 Oct 2022 08:48:14 -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.5 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: On Thu, Oct 27, 2022 at 12:39 PM Alexey Lapshin wrote: > > I still think that the series that I posted back in 2017 here > > https://sourceware.org/pipermail/binutils/2017-May/098159.html > > FYI we already use your approach in GDB (with some improvements and > modifications). Wow, cool. I didn't know about that. > Only the difference is that we pass chip name over command-line option, > not through ENV variable. Is there any advantage to it? I know that IDF requires some environment setup and choosing the target core anyway. > https://github.com/espressif/esp-xtensaconfig-lib > Line in GDB to use it: > https://github.com/espressif/binutils-gdb/commit/add3053905e646af67692ae1a67fd5ee76e84723#diff-a4fc3be128b23679672d7d28616e553d81c0631f38e9205774721678bbabfcb7R102 > The main disadvantage of this is that we need to have duplicated source > files from binutils inside this library. I'm curious why? IIRC I got rid of all such dependencies in my version, but then I could have missed something as I haven't been using it a lot. Certainly I paid very little attention to the gdb. > > 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. > > Could you elaborate on this? I'm very new here and do not fully > understand the existing workflow and what was broken. Sure, it's the replacement of the binutils overlay files that wouldn't work with this change. Description is available here: http://wiki.linux-xtensa.org/index.php/Toolchain_Overlay_File and overlay application is a part of toolchain build systems like crosstool-NG: https://github.com/crosstool-ng/crosstool-ng/blob/crosstool-ng-1.25.0/scripts/functions#L2413 and buildroot: https://github.com/buildroot/buildroot/blob/2022.08/package/binutils/binutils.mk#L115 > > what's the option for disassembling code that lacks the .xtensa.info? > > Another option could be to write cpu to the elf's e_flags. The initial > code exists. Needs just to add another machines: > https://github.com/bminor/binutils-gdb/blob/1eeb0316304f2d4e2c48aa8887e28c936bfe4f4d/include/elf/xtensa.h#L104 Any kind of numbering means that there must be an authority that will at least make sure that the numbers are unique. I think we're much better off recording core name in the .xtensa.info while also providing a fallback mechanism for the case this information is missing or there's a need to override it. I think that I need to research why Tensilica hasn't done anything like that, neither here nor in its internal toolchain. > What if I redo this patch with removing the most definitions from > xtensa-config.h? XCHAL_HAVE_BE, XCHAL_HAVE_ABS, XCHAL_HAVE_ADDX, ..., > and most all other hardcoded definitions could be gotten from xtensa- > modules.c That will not remove these definitions from the existing overlays. And also there's a copy of this header in the gcc tree, which I'd like to keep in sync. xtensa-dynconfig series was able to deal with these names by redefining the X?HAL_* macros. I think that we first need to complete getting rid of the macro use in preprocessor conditionals inside the toolchain source code. And then provide these macros as compiler built-ins for the target libraries. -- Thanks. -- Max