Re: [PATCH 0/5] Add Xtensa ESP chips support

[Max Filippov <jcmvbkbc@gmail.com>]

On Thu, Oct 27, 2022 at 12:39 PM Alexey Lapshin
<alexey.lapshin@espressif.com> 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