esp_http_client: Fix buffer overread, update https_request example to use HTTP/1.1
Closes IDFGH-4303 and IDFGH-4288
See merge request espressif/esp-idf!11864
SoC level exceptions such as watchdog timer and cache errors are now supported.
Such exceptions now triggers a panic, giving more information about how
and when it happened.
The previous approach was to allocate an array on the stack, and
have the array extend past the stack size. This worked by would
result in SP being moved near the end of the stack. If an interrupt
triggered at that time, interrupt prologue would try to save the
context to the stack, tripping the stack overflow watchpoint.
Replacing this with the approach which doesn't move the SP and simply
writes to decreasing addresses from SP, until stack overflow check
triggers.
riscv32-esp-elf toolchain (used for ESP32-C3) can also be used for
ESP32-S2 RISC-V ULP coprocessor.
This removes the riscv-none-embed-gcc toolchain which was originally
used for the ULP, and updates the docs and CMake files to use
riscv32-esp-elf.
Some flags are cleaned up and workarounds removed from CMake toolchain
file.
This adds support for the retargetable locking implementation in
newlib 3. This feature will be enabled in the future toolchain builds.
With the present version of the toolchain, this code doesn't get used.
When _RETARGETABLE_LOCKING gets enabled, newlib locking implementation
will be modified as follows:
- Legacy ESP-specific _lock_xxx functions are preserved. This is done
because ROM copies of newlib in ESP32 and ESP32-S2 rely on these
functions through the function pointer table. Also there is some
code in IDF which still uses these locking functions.
- New __retarget_lock_xxx functions are introduced. Newlib expects
these functions to be provided by the system. These functions work
pretty much the same way as the ESP-specific _lock_xxx functions,
except one major difference: _lock_acquire receives the lock pointer
by value, and as such doesn't support lazy initialization.
- Static locks used by newlib are now explicitly initialized at
startup. Since it is unlikely that these static locks are used at
the same time, all compatible locks are set to point to the same
mutex. This saves a bit of RAM. Note that there are still many locks
not initialized statically, in particular those inside FILE
structures.
the mDNS responder should not repeat questions when replying, however resolvers
must ignore these questions field if they are present. esp-idf mDNS
library does include questions in answering packets (thus not strictly
following the RFC6762) so the resolver did not correctly resolved
another instance host name.
Closes https://github.com/espressif/esp-idf/issues/6190
