jcmvbkbc / gcc-xtensa Goto Github PK

gcc for xtensa

License: GNU General Public License v2.0

Makefile 2.65% C 44.27% C++ 18.10% Assembly 0.88% Shell 0.79% HTML 3.73% Awk 0.04% Perl 0.09% Python 0.07% Logos 0.14% Objective-C 0.76% Ada 20.80% OCaml 0.07% TeX 0.27% Scilab 0.11% PHP 0.01% Haskell 0.01% Fortran 1.97% Go 5.06% Objective-C++ 0.19%

gcc-xtensa's People

Contributors

Stargazers

Watchers

Forkers

a-l-e-x skptl emgab koson jclboz alrieckert jymaze emuxevans jaalfs sherckuith yoegg vivekpatra z3panyaoem wangyx0055 cokesme heikki-susi stone89son venkatarajasekhar sramos30 pergronroos gokmonk dinkin andrey700 mcu-esp12 boualimed vvivek1212 keolson26 earlephilhower zhj2232006 giorgiorovere tinskaysys fcsm25110 danonesl istorn danielprokopp sylvandb sandipparmar32 witsoft001 minimum-necessary-change esdrasemanuel mollyxdd wuhuaroubj siegezero ttw225 reynaldoluis honamlau tadryanom bilyhack12 rehankhan2306 kunta87 gits00 gscofano jason2866 fromgreg web-logs2 bytes0x0

gcc-xtensa's Issues

FYI, integration script to build complete ESP8266

Strictly FYI ;-). https://github.com/pfalcon/esp-open-sdk

How to build gcc-xtensa for Windows?

I have already donwloaded gcc-xtensa version 4.9.2 release version.
and I have already install MingW on my computer.

If I want to build for Windows platform , how to build them ?

Thank you.

Bad prologue generated for call0 ABI functions

call0 ABI functions that require 129 to 1024 bytes of stack frame and don't save any incoming registers on the stack don't get stack pointer adjustment prologue. This results in stack frame corruption in the calling functions and wrong stack pointer upon return from the function. And inevitable crash as a result.

Reproducer:

#include <stdarg.h>
long x;
void
f3 (int i, ...)
{ 
  va_list aps[10];
  va_start (aps[4], i);
  x = va_arg (aps[4], long);
  va_end (aps[4]);
}

Generated code:

0040069c <f3>:
  40069c:       216132          s32i    a3, a1, 132
  40069f:       226142          s32i    a4, a1, 136
  4006a2:       236152          s32i    a5, a1, 140
  4006a5:       246162          s32i    a6, a1, 144
  4006a8:       256172          s32i    a7, a1, 148
  4006ab:       80a022          movi    a2, 128
  4006ae:       212a            add.n   a2, a1, a2
  4006b0:       d129            s32i.n  a2, a1, 52
  4006b2:       c129            s32i.n  a2, a1, 48
  4006b4:       830c            movi.n  a3, 8
  4006b6:       e139            s32i.n  a3, a1, 56
  4006b8:       223a            add.n   a2, a2, a3
  4006ba:       fcc222          addi    a2, a2, -4
  4006bd:       0238            l32i.n  a3, a2, 0
  4006bf:       ffdf21          l32r    a2, 40063c <bar+0xa8>
  4006c2:       0239            s32i.n  a3, a2, 0
  4006c4:       a0a092          movi    a9, 160
  4006c7:       119a            add.n   a1, a1, a9
  4006c9:       f00d            ret.n

All gcc versions with call0 ABI support and the current gcc trunk are affected.

Support ASAN (-fsanitize=address) for xtensa target

Not sure what is involved, but I know that ASAN support on x86 is amazing for finding tricky bugs, and I'd love to run it on my ESP32 debug builds.

I'm not sure what is involved in adding it for a new target. The current state seems to be a compiler warning (after adding -fsanitize=address to CXXFLAGS):

warning: -fsanitize=address not supported for this target

Recent versions of GCC

Hello,

I've been spending the last several hours, trying to get the "xtensa-ctng-7.2.0" branch to work. I've been able to build the toolchain, however the only binaries I could get was big endian no matter how I compiled. I'm starting to think that branch isn't really ready to be used.

Is there a way to get a recent version of GCC (>=6) working with little endian lx106 binaries? Specifically for ESP8266 mcus.

I'm not using ct-ng and manually compiling everything. I may be using some incorrect versions of other stuff.

Q: how to apply mforce-l32 patch

can you give an advice how to apply this particular patch to crosstool-NG build environment?

Building for esp32s3: unsupported ABI?

Hi Max,
When I run the rebuild-esp32s3-linux.sh, it fails when building the toolchain. Looking at the log, it fails when compiling libgcc2.c, reporting error of "Unsupported ABI".
In the header file, it triggers the error when both FDPIC and XTENSA_WINDOWED_ABI are defined.
I think esp32s3 should support windowed abi, so a bit confused here.
build log attached and hope you could help. Thanks.
build.log

Best regards,

Newer versions as default

Hi, it looks like the branch based on gcc-4.8 is the default/recommended branch. This is for instance used in the toolchain that comes with Arduino core. However GCC 4.8 is quite old, about 4 years now.

I also find some branches for 4.9 and 5.1. What is the background for 4.8 still being default?

master seems to be tracking GCC master. Are there any plans of upstreaming the Xtensa backend to mainline GCC?

"register" directive not honored correctly.

Inside functions, I can declare a "register" directive to a variable. Amazingly, GCC sometimes follows it, but most of the time, it does not. Though it will usually generate code using the variable as a register, it doesn't always seem to work. Additionally, sometimes GCC will clobber my registers with its own code.

Furthermore, GCC does not seem to back up these registers inside a function call. Even if I list a register as clobbering in my volatile asm, it simply ignores that. I may clobber registers that could have serious consequences and GCC won't back them up. Ordinarily I'd just work around this, but the whole not saving registers thing is a pretty big annoyance.

gcc-xtensa appears to hardcode data alignment to 4

I'm investigating why project built for xtensa produces unexpectedly high data section size. Project is built with -fdata-sections (which is common for embedded projects; the issue likely manifests itself even without it still). In map file I see:

 .rodata.rule_yield_arg
                0x000000003ffe9cfc        0x6 build/py/parse.o
 *fill*         0x000000003ffe9d02        0x2
 .rodata.rule_yield_expr
                0x000000003ffe9d04        0x6 build/py/parse.o
 *fill*         0x000000003ffe9d0a        0x2

I.e. each 6-byte structure gets aligned on 4-byte boundary. Looking at structures, they consist only of short's, i.e. have natural alignment of 2.

The simplest testcase to reproduce the issue is:

struct foo {
    short a, b, c;
};

struct foo s1 = {1};
struct foo s2 = {2};

When build for both arm and x64, this produces following assembly:

    .global s1
    .data
    .align  2
    .type   s1, %object
    .size   s1, 6
s1:
    .short  1
    .space  4
    .global s2
    .align  2
    .type   s2, %object
    .size   s2, 6
s2:
    .short  2
    .space  4

with xtensa-lx106-elf-gcc the result is:

    .global s1
    .data
    .align  4
    .type   s1, @object
    .size   s1, 6
s1:
    .short  1
    .zero   4
    .global s2
    .align  4
    .type   s2, @object
    .size   s2, 6
s2:
    .short  2
    .zero   4

Note the difference in ".align" directives.

The expect behavior is that structure alignment should be its natural alignment (which is defined as maximum alignment of any structure field). Is current xtensa-lx106-elf-gcc behavior grounded in any Xtensa ABI or something? Even if it is, the behavior like above is detrimental for embedded usage, where ABI issues are not relevant, but losses from overzealous alignment are noticeable (for example, in the original case, there're hundreds of such structures; if structures/variables are just single short's, there's 50% loss of space in 4-byte alignment).

How to build toolchain for FreeBSD 13

Hello, i try to run ESPHome, it need platformio, but i can build any of esp firmware.
I need to update xtensa, and i try to build it under FreeBSD. Any hint how i can make it ?

Best.

ICE, insn does not satisfy its constraints

Recently we ran into this issue on a couple of programs, when compiling code which uses floating point at -O2 optimization level:

$ xtensa-esp32-elf-gcc -c test.c  -mlongcalls -O2 -Wall -Werror -Wextra -Wpedantic -fdump-rtl-all
test.c: In function 'd':
test.c:15:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 74 27 19 4 (set (reg:SF 19 f0 [orig:43 iftmp$0_6 ] [43])
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32])) "test.c":11 47 {movsf_internal}
     (nil))
during RTL pass: postreload
dump file: test.c.279r.postreload
test.c:15:1: internal compiler error: in extract_constrain_insn, at recog.c:2210

test.c (as minimal as i could c-reduce it):

extern unsigned char a();
extern float b;
extern unsigned char c, h;

void d(signed char unused)
{
  (void) unused;
  const unsigned char e = a();
  for (unsigned char f = c; f; f++) {
    for (unsigned char g = 0; g <= h; g++) {
      b = e ? b : 0;
      d(f);
    }
  }
}

I'm slowly learning my way through the RTL dumps, hoping to find the cause, but wanted to post just in case there is any obvious issue here.

GCC branch I'm using is https://github.com/espressif/gcc/tree/esp_based_on_8_4_0 (a few patches on top of GCC 8.4).

error: can't find a register in class 'RL_REGS' while reloading 'asm'

I found a very interesting I2C master implementation written in assembly language for the ESP8266 (https://github.com/pasko-zh/brzo_i2c). However, as the author mentions, the library is written for the Arduino toolchain.

I made some slight changes in order to compile it with the newest SDK from espressif: ESP8266_NONOS_SDK_V2.0.0_16_07_19.

However, I haven't been able to get past this compiler error:

brzo_i2c.c: In function 'brzo_i2c_read':
modules/brzo_i2c.c:413:2: error: can't find a register in class 'RL_REGS' while reloading 'asm'
  asm volatile (
  ^
modules/brzo_i2c.c:413:2: error: 'asm' operand has impossible constraints
make: *** [build/modules/brzo_i2c.o] Error 1

14:46:16 Build Finished (took 162ms)

The CFLAG variable in my Makefile looks like this:

# compiler flags using during compilation of source files
CFLAGS      =   -g          \
                -Wpointer-arith     \
                -Wundef         \
                -Wl,-EL         \
                -fno-inline-functions   \
                -nostdlib       \
                -mlongcalls \
                -mtext-section-literals \
                -ffunction-sections \
                -fdata-sections \
                -fno-builtin-printf\
                -DICACHE_FLASH \
                -DBUID_TIME=\"$(DATETIME)\" \
                -std=gnu89

This is the inline assembler code that it points to:

asm volatile (
        // Disable all interrupts, i.e. interrupts up to the highest interrupt level of 15
        //   the current level is saved in %[r_temp1] but we will not use that value again,
        //   instead we will just enable all interrupt levels at the end of this routine
        "RSIL   %[r_temp1], 15;"
        "MOVI   %[r_set], 0x60000304;"

        // Check if bus is free and send START
        "OR     %[r_temp1], %[r_sda_bitmask], %[r_scl_bitmask];"
        "L16UI  %[r_in_value], %[r_set], 20;" // offset is 20d = 14h = > in: 0x60000318
        "MEMW;"
        "MOVI.N %[r_error], 1;"
        // If either SDA or SCL is low, then bus is not free and thus jump to l_exit
        "BNALL  %[r_in_value], %[r_temp1], l_exit;"
        // Bus is free, so we can send START
        "MOVI.N %[r_error], 0;"
        "MOV.N  %[r_temp1], %[r_iteration_scl_halfcycle];"
        // Set SCL = 1
        "S16I   %[r_scl_bitmask], %[r_set], 0;"
        "MEMW;"
        // Set SDA = 0
        // Delay for tHD;STA  >= 4.0 usec for standard mode, 0.6 usec for fast or 0.26 usec fast mode plus
        //  => a delay of one half cycle is enough to meet those timings
        "S16I   %[r_sda_bitmask], %[r_set], 4;"  // clear: 0x60000308
        "l_w01:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w01;"
        // Post Condition: SDA = 0, SCL = 1

        // The outer loop, sending 1...n data bytes
        "l_send_byte:"
        // select the MSB of byte_to_send
        "MOVI   %[r_bit_index], 128;"
        // The inner loop, sending 1...8 bits
        "l_send_bit:"
        "MOV.N  %[r_temp1], %[r_iteration_scl_halfcycle];"
        // check if the bit of byte_to_send at bit_index is 0 or 1
        "BALL   %[r_byte_to_send], %[r_bit_index], l_sda1_scl0;"
        // SDA = 0, SCL = 0
        "S16I   %[r_scl_bitmask], %[r_set], 4;" // clear: 0x60000308
        "MEMW;"
        "S16I   %[r_sda_bitmask], %[r_set], 4;" // clear: 0x60000308
        "l_w02:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w02;"
        "j l_sdax_scl1;"

        "l_sda1_scl0:"
        // SDA = 1, SCL = 0
        "S16I   %[r_scl_bitmask], %[r_set], 4;" // clear: 0x60000308
        "MEMW;"
        "S16I   %[r_sda_bitmask], %[r_set], 0;"
        "l_w03:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w03;"

        "l_sdax_scl1:"
        // SDA = leave unchanged and set SCL = 1
        // Check for clock stretching
        // Delay is little bit shorter, i.e. half_cycle - delta
        "ADDI   %[r_temp1], %[r_iteration_scl_halfcycle], -5;"
        // Let SCL raise
        "S16I   %[r_scl_bitmask], %[r_set], 0;"
        "MEMW;"
        "l_w04:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        // Explicitly BGEZ instead of BNEZ
        "BGEZ   %[r_temp1], l_w04;"

        // Sample SCL value
        "L16UI  %[r_in_value], %[r_set], 20;" // offset is 20d = 14h = > in: 0x60000318
        "MEMW;"
        // r_temp1 holds the number of iterations for clock stretch timeout
        "MOV.N  %[r_temp1], %[r_iteration_scl_clock_stretch];"
        // Branch if SCL = 1, i.e. no stretching
        "BALL   %[r_in_value], %[r_scl_bitmask], l_no_stretch;"
        // SCL = 0, i.e. stretching by the slave, i.e. it pulls SCL low
        "l_stretch:"
        // Sample SCL value
        "L16UI  %[r_in_value], %[r_set], 20;" // offset is 20d = 14h = > in: 0x60000318
        "MEMW;"
        // Branch if SCL = 1, i.e. no more stretching
        "BALL   %[r_in_value], %[r_scl_bitmask], l_scl_high_by_slave;"
        // SCL is still low
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        // Did we reach the clock stretch timeout?
        // Branch if we have not yet reached the timeout
        "BNEZ   %[r_temp1], l_stretch;"
        // We have reached the clock stretch timeout, i.e. SCL is still pulled low by the slave
        // Error: Bus is not free, since SCL is still low AND clock stretch timeout reached
        "MOVI.N %[r_error], 8;"
        // We explicitly do not send a STOP instead we exit, i.e. jump to l_exit and not to l_send_stop
        "j l_exit;"

        "l_scl_high_by_slave:"
        // SCL was set high by the slave
        // We have to make sure that SCL = 1 for a complete half cycle
        "MOV.N  %[r_temp1], %[r_iteration_scl_halfcycle];"
        "l_w041:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w041;"

        "l_no_stretch:"
        // Postcondition: SCL = 1 for a half cycle
        // Are there bits left that we need to send?
        "SRLI   %[r_bit_index], %[r_bit_index], 1;"
        // When the LSB of the byte_to_send was sent, i.e. bit index was 1 before SRLI, it will now be zero
        // As long as the LSB was not sent keep on sending bits, i.e. jump
        "BNEZ   %[r_bit_index], l_send_bit;"
        // we have sent 8 Bits

        // check for ACK by slave
        // Precondition
        // SDA = LSB (i.e. SDA = 0, since we have an i2c write), SCL = 1
        // SCL = 0
        // Spike reducing waits here
        "S16I   %[r_scl_bitmask], %[r_set], 4;"  // clear : 0x60000308
        "MOV.N  %[r_temp1], %[r_iteration_minimize_spike];"
        "l_w05:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w05;"
        // Reduce number of iterations by the ones we've already used
        "SUB    %[r_temp1], %[r_iteration_scl_halfcycle], %[r_iteration_minimize_spike];"
        // Now we let SDA raise.
        // In case of an ACK the i2c slave is pulling SDA down
        // In case of an NACK, SDA raises
        "S16I   %[r_sda_bitmask], %[r_set], 0;"
        "MEMW;"
        "l_w06:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BGEZ   %[r_temp1], l_w06;"

        // Delay is little bit shorter, i.e. half_cycle - delta
        // Because we will have a L16UI after in this half cycle
        "ADDI   %[r_temp1], %[r_iteration_scl_halfcycle], -5;"
        // Set SCL = 1, i.e. start of the second half cycle of the 9th SCL cycle
        "S16I   %[r_scl_bitmask], %[r_set], 0;"
        "MEMW;"
        // Delay for the second half cycle of the 9th SCL cycle
        "l_w07:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BGEZ   %[r_temp1], l_w07;"
        // Sample SDA at the end of the 9th clock cycle
        // In the case of an NACK we want to leave enough time that SDA can raise
        // If sda_value AND sda_bitmask == 0 => ACK else we have an NACK
        "L16UI  %[r_in_value], %[r_set], 20;" // offset is 20d = 14h = > in: 0x60000318
        "BNALL  %[r_in_value], %[r_sda_bitmask], l_slave_ack;"
        "MOVI.N %[r_error], 2;"
        // NACK by slave
        // Postcondition:
        //   SDA = 1 (NACK) and SCL = 1
        //   9th Clock Cycle is finished
        "j l_send_stop;"

        "l_slave_ack:"
        // ACK
        // Precondition: SDA = 0 (still pulled low by the slave) and SCL = 1
        // The slave will pull SDA low as long as SCL = 1
        // We have to set SDA = 0 by the master
        // clear : 0x60000308
        "S16I   %[r_sda_bitmask], %[r_set], 4;"
        // Postcondition:
        //   SDA = 0 and SCL = 1
        //   9th Clock Cycle is finished

        "BEQZ   %[r_no_of_bytes], l_send_stop;"
        // Branch if there are no more Data Bytes to send
        // Load the corresponding element of array data[.] into byte_to_send
        "L8UI   %[r_byte_to_send], %[r_adr_array_element], 0;"
        // Move the pointer to the next array element (since we have an array of bytes, the increment is 1)
        "ADDI.N %[r_adr_array_element], %[r_adr_array_element], 1;"
        // Decrement the number of bytes to send
        "ADDI.N %[r_no_of_bytes], %[r_no_of_bytes], -1;"
        "j l_send_byte;"

        "l_send_stop:"
        // Send Stop
        // We have to make sure that SDA = 0 and SCL = 1, before we send the STOP sequence,
        //   i.e. "A LOW to HIGH transition on the SDA line while SCL is HIGH"
        // In order to achieve this econdition, we have to distinguish between
        //   1) NACK: SDA = 1, SCL = 1
        //   2) ACK: SDA = 0, SCL = 1
        //      SDA is still pulled low by the slave, so we have to signal the slave to release it.
        //      We will do this by letting SCL go low.
        "MOV.N  %[r_temp1], %[r_iteration_scl_halfcycle];"
        // if we had a NACK then r_error = 2
        // if we had an ACK then r_error = 0
        "BNEZ.N %[r_error], l_stop_after_NACK;"
        // Send stop after ACK
        // Precondition: SDA = 0, SCL = 1

        // We are at the beginning of the 10th cycle (if there was no clock stretching)
        // Set SCL = 0
        // During the first half cycle the slave should release SDA...
        "S16I   %[r_scl_bitmask], %[r_set], 4;" // clear : 0x60000308
        "MEMW;"
        "l_w08:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w08;"

        // Check for a repeated start
        // Branch if r_repeated is 0, i.e. is no repeated start, just send stop
        "BEQZ.N %[r_repeated], l_no_repeated_start;"
        // Make sure that the precondition for the next command (i.e. the start) will be met
        // Currently, SCL = 0 and SDA is starting to raise, since the slave has released it
        // To be on the safe side, we set both SCL = 1 _and SDA = 1
        // SDA  = 1
        "S16I   %[r_sda_bitmask], %[r_set], 0;"
        "MEMW;"
        // SCL = 1;
        "S16I   %[r_scl_bitmask], %[r_set], 0;"
        // Postcondition: SCL = 1 and SDA = 1, now the next i2c command send start
        "j l_exit;"

        "l_no_repeated_start:"
        // For the second half cycle, we set SDA = 0, SCL = 1
        "MOV.N  %[r_temp1], %[r_iteration_scl_halfcycle];"
        "S16I   %[r_sda_bitmask], %[r_set], 4;" // clear : 0x60000308
        "MEMW;"
        "S16I   %[r_scl_bitmask], %[r_set], 0;"
        "l_w09:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w09;"

        // For the first half cycle of the 11th cycle, we set SDA = 1 and leave SCL = 1
        "MOV.N  %[r_temp1], %[r_iteration_scl_halfcycle];"
        // SDA = 1 (SCL is already high, we don't need to change it)
        "S16I   %[r_sda_bitmask], %[r_set], 0;"
        "MEMW;"
        "l_w10:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w10;"
        "j l_exit;"

        "l_stop_after_NACK:"
        // Send stop after NACK
        // Precondition: SDA = 1, SCL = 1

        // SDA = 0
        // SCL = 1 : In "normal" cycles we woud set SCL to 0
        "S16I   %[r_sda_bitmask], %[r_set], 4;"  // clear: 0x60000308
        "S16I   %[r_scl_bitmask], %[r_set], 0;"
        // Delay for the first half cycle of 10th cycle
        "MEMW;"
        "l_w11:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w11;"
        // Postcondition: SDA = 0 and SCL = 1

        // Now we set SDA = 1 and leave SCL = 1 : This ist the STOP condition,
        //   i.e. the "A LOW to HIGH transition on the SDA line while SCL is HIGH"
        "MOV.N  %[r_temp1], %[r_iteration_scl_halfcycle];"
        "S16I   %[r_sda_bitmask], %[r_set], 0;"
        // SDA = 1 (SCL is already high, we don't need to change it)
        "MEMW;"
        "l_w12:"
        "ADDI.N %[r_temp1], %[r_temp1], -1;"
        "NOP;"
        "BNEZ   %[r_temp1], l_w12;"

        "l_exit:"
        // Enable all interrupts again, i.e. interrupts with interrupt level >= 1
        "RSIL   %[r_temp1], 0;"

        : [r_set] "+r" (a_set), [r_repeated] "+r" (a_repeated), [r_temp1] "+r" (a_temp1), [r_in_value] "+r" (a_in_value), [r_error] "+r" (i2c_error), [r_bit_index] "+r" (a_bit_index), [r_adr_array_element] "+r" (&data[0]), [r_byte_to_send] "+r" (byte_to_send), [r_no_of_bytes] "+r" (no_of_bytes)
        : [r_sda_bitmask] "r" (sda_bitmask), [r_scl_bitmask] "r" (scl_bitmask), [r_iteration_scl_halfcycle] "r" (iteration_scl_halfcycle), [r_iteration_minimize_spike] "r" (iteration_remove_spike), [r_iteration_scl_clock_stretch] "r" (iteration_scl_clock_stretch)
        : "memory"
    );

I would really appreciate if you could help me understand what it is that is going wrong and what options there are to solve it. Thanks in advance.

bsdtar: Invalid central directory signature

When unpacking https://github.com/jcmvbkbc/gcc-xtensa/archive/master.zip with bsdtar on Linux I get the following error message:

bsdtar: Invalid central directory signature

'unzip' works without error.

For me, 'bsdtar' has the advantage of being independent of the file format (.tar, .tar.gz, tar.bz2 or .zip).

I found no problem with Cygwin, minGW or MacOS.

For testing, I ran a small repo under travis-ci, the results can be seen here:
https://travis-ci.org/Juppit/Check-Zip

It would be nice if this 'error' could be fixed.

error: 'uint_least32_t' is already declared in this scope

While compiling I've this error:

In file included from /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/bits/char_trait
                 from /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/ios:40,
                 from /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/istream:38,
                 from /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/sstream:38,
                 from /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/complex:45,
                 from /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/ccomplex:38,
                 from /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/include/precompiled/stdc++.h:52:
/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/cstdint:78:11: error: 'uint_least32_t
   using ::uint_least32_t;

It's generated by this call:
/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc/xgcc -shared-libgcc -B/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc -nostdinc++ -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src/.libs -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/libsupc++/.libs -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/bin/ -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/lib/ -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/include -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/sys-include -x c++-header -nostdinc++ -g -O2 -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/xtensa-lx106-elf -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/include/precompiled/stdc++.h -o xtensa-lx106-elf/bits/stdc++.h.gch/O2ggnu++0x.gch

But I saw the same this call which works (only difference: no gnu++0x):
/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc/xgcc -shared-libgcc -B/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc -nostdinc++ -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src/.libs -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/libsupc++/.libs -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/bin/ -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/lib/ -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/include -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/sys-include -x c++-header -nostdinc++ -g -O2 -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/xtensa-lx106-elf -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/libsupc++ -O2 -g /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/include/precompiled/stdc++.h -o xtensa-lx106-elf/bits/stdc++.h.gch/O2g.gch

Any idea ?

Xtensa ELF info/hints?

Another support request regarding Xtensa stuff:

Is there formal Xtensa ELF ABI references, which described what R_XTENSA_SLOT0_OP and friends are? I saw such stuff e.g. for PowerPC, but googling for "R_XTENSA_SLOT0_OP pdf" gives nothing, and for "R_XTENSA_SLOT0_OP" only noise.
Does Xtensa arch support linker-relocated, non-PIC shared libraries? E.g. old good x86 supports that, while x86_64 explicitly don't. Quick try for Xtensa gives: "dangerous relocation: invalid relocation for dynamic symbol: memset", "dangerous relocation: dynamic relocation in read-only section", etc. I still wonder if there's a definitive, formal answer.

Thanks.

Context: well, if you make things like https://github.com/jcmvbkbc/esp-elf-rom yourself, you shouldn't be surprised someone else asks such questions ;-). And did a "@jcmvbkbc" in another project's ticket, so just leaving it here: https://github.com/pfalcon/ScratchABit