d979b57d76
* Upgrade to GCC 9.1 toolchain
* Rebuilt using pure GNU binutils and GCC
Remove dependencies on earlier forked GNU utilities (gcc-xtensa,
binutils-gdb-xtensa) and just use GCC sources, unmodified (except for
patches in the esp-quick-toolchain directories).
* Rebuild bearssl using new toolchain
* Fix GDBstub linkage options
GDB works with pure GNU GCC and pure GNU binutils now. Still warnings
galore, but tested with the example sketch in the docs.
* Fix digitalRead alias warning
* Remove gdb stub warnings w/a pragma
* Fix deprecated implicit copy ctors in IP code
Fix some warnings present in GCC8/9 in the IPAddress code
In AddressListIterator there was a copy constructor which simply copied
the structure bit-for-bit. That's the default operation, so remove it
to avoid the warning there.
IPAddress, add a default copy constructor since the other copy
constructors are simply parsing from one format into a native ip_addr_t.
@d-a-v, can you give these a look over and see if they're good (since
IP stuff is really your domain).
* Fix AxTLS alias function defs to match real code
* Fix WiFiClientSecure implicit default copy ctor
These both use shared-ptrs to handle refcnts to allocated data, so using
the default copy constructor is fine (and has been in use for a long
time).
* Dummy size for heap to avoid GCC 8/9 warnings
Make GCC think _heap_start is large enough to avoid the basic (and
incorrect) bounds-checking warnings it produces. The size chosen is
arbitrary and does not affect the actual size of the heap in any way.
* Make heap an undefined extend array
Instead of a bogus size, use an indefinite size for the heap to avoid
GCC warnings
* Trivial tab to space fix
* Update SDFat to remove FatFile warnings
* Fix ticker function cast warnings in GCC 9
The callback function is defined to take a (void*) as parameter, but our
templates let users use anything that fits inside sizeof(void*) to be
passed in. Add pragmas to stop GCC warnings about this, since we
already check the size of the type will fit in the allocated space.
* Remove GCC support fcn that's in ROM
Manually delete the divdi3.so from the libgcc.a library by running the
updated EQT's 9.1-post script.
* Make exceptions work again, get std::regex up
Exceptions are broken on all builds (GCC4.8-9.1) due to the removal of
the PROGMEM non-32b read exception handler (added in the unstable
pre3.0.0).
Build the exception code with -mforce-l32 and patch
accordingly to avoid LoadStore errors.
Apply patches to select portions of the regex lib which use _stype_
(which is now in flash).
* Rebuild Bearssl using latest GCC push
* Automate building of BearSSL and LWIP w/new toolchain
* Workaround g++ template section problem for exception strings
G++ seems to throw out the section attributes for templates. This means
that the __EXCSTR(a synonym for "PSTR()") is ignored and exception.what
strings are stored in RODATA, eating up RAM.
Workaround by using the linker to place the strings keying off their name
("*__exception_what__*").
* Rebuild moving exception.what to unique names
Exception.whats are now all in __exception_what__ and can be moved by
the linker to flash. Works aroung G++ issue with segments being lost in
templates.
* Rebuild with new LWIP locking
* Update to latest libs, save iram
Move two GCC FP support routines out of iram since they are in ROM
already, saving some add'l IRAM. Same list as gcc 4.8.
* Update BearSSL to latest release
* Fix umm_perf reference to ROM function
* Fix "reinterpret_case is not a constexpr" error
In GCC 9 (and 8 from what I read on SO), a cast of a const int to a
function pointer (via explicit or implicit reinterpret_cast) is not a
constexpr.
````
/home/earle/Arduino/hardware/esp8266com/esp8266/cores/esp8266/umm_malloc/umm_performance.cpp:45:36: error: a reinterpret_cast is not a constant expression
45 | int constexpr (*_rom_putc1)(int) = (int (*)(int))(void*)0x40001dcc;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
````
Remove the constexpr, potentially increasing heap usage by 4 bytes in
debug mode.
* Update libc.a to latest rev
* Full rebuild of toolchain and libs
* Upgrade to GCC 9.2, released in August 2019
Add builds for all 5 cross-compiles to pass CI
* Move to --std=gnu++14 (C++14 + GNU extensions)
* Fix Ticker merge conflict
* Fix json merge conflict
* One more merge diff fix
* Reapply Ticker.h casting warning fixes for gcc9
* Update with fixes from Sming repo for PSTR and ASM
* Upgrade to -gnu4 toolchain
* Move to gnu5 build with add'l softFP from ROM
* Move add'l softFP from IRAM to flash
Per @mikee47, we miss sone add'l soft-FP routined in the linker which
makes them end up in IRAM. Move them explicitly into flash, like a
couple others we have already done this for.
* Move to std=c++17/c17 in platform, remove abs/round
Move to C++17 and C17 standards on the compiler options.
Remove "register" from core since it is deprecated.
Remove the #define abs() and #define round() which a) overwrote the
C stdlib definitions, poorly, and b) broke the GCC core code which used
"abs" as an internal function name.
Now abs() returns an integer, and not whatever was being absoluted.
fabs() etc. can be used if users need fload/double suport.
round() returns a double now, which is basically what it was returning
in the original case since adding/subtracting by a FP.
* Use std::abs/round to replace the macro definitions
Per discussion w/@devyte, preserve the abs() and round() functionality
via the using statement.
* Remove using std::abs which conflicted with C lib headers
* Add 2nd arg (exception handler) to ets_isr_t
Disassembly of the ROM shows there are 2 params to the ets_isr_t
callback. The first is the arg passed in, the second is a pointer to an
exception frame where you can get info about when the IRQ happened.
* Move the gdbstub example to a subdir
The Arduino IDE and the build CI don't build it without a subdir, so
make one for gdbstub's example so it's visible and tested.
* Fix ets_irq_arratch redefinition and core IRQ handlers
Remove a duplicated, different declaration for ets_irq_attach from
ets_sys.h. It never really even matched the other declaration in the
same header.
Update the core to IRQ handlers to fix the prototype and include the
2nd, unused frame parameter.
* Actually rebuild the libc.a using GCC 9.2
* Fix SPISlave interrupt attach's 2nd parameter
* Rebuild eboot.elf with GCC 9
* Update to latest SoftwareSerial for Delegate fix
* Upgrade to GCC 9.3
* Rebuild all arch toolchains
* Move to GCC 10.1
* Merge master and fix eboot build
GCC10 now uses `-fno-common` so the eboot global variables were being
placed in IRAM. Adjust the makefile and rebuild to fix.
* Built complete toolchain for all archs
* Pull in latest PSTR changes and fix GCC10.1 build
Somehow the prior GCC build's -mforce32 patch wasn't applying correctly,
but I was still able to get a binary. Fixed. Also pulled in latest
PSTR changes in progmem.h
* Update platform.io to platform C/C++ standards
* Use PR's toolchain in platformio build
* Fix several asm warnings in PIO build
* Optional stack smash protection -fstack-protector
Add a menu to enable GCC's built-in stack smash protection. When a
subroutine goes past its end of stack, generate a crashdump on function
exit like:
````
GCC detected stack overrun
Stack corrupted, stack smash detected.
>>>stack>>>
ctx: cont
sp: 3fffff20 end: 3fffffc0 offset: 0000
3fffff20: 40202955 00000001 0000001c 4020287e
3fffff30: feefeffe 000000fd 00000000 00000000
...
<<<stack<<<
````
Disabled by default because there is a small per-function code overhead
(and CPU time if the function is called very frequently and is very
small).
BearSSL and LWIP are not built using stack smash detection, yet.
* Fix duplicated stc=gnu99/c17 in build
* Dump faulting function PC in stack overflow
Report a fake exception to have the exception decoder print the actual
faulting function. This won't tell you where in the function the issue
happened, but it will tell you the function name first and foremost.
* Rebuild with Platform.io JSON tag in release tgzs
Release tools
Release model
The release model is linear. That means that there is only one main code branch, and releases are snapshots of that branch at specific points in the sequence of commits. The advantage of this model is that the maintenance effort is greately reduced compared to other release models, such as a branched model. The disadvantage is that progress is ever only forward, and fixes can't be backported to prior releases. this means there is no such thing as a "stable" release (however, see Sub releases below).
There are 4 types of releases:
Major releases
These contain breaking changes, such as big API changes, both in function signature and data representation. When this happens, user apps will require changes to continue to work, and those changes could be significant. Major releases happen seldom, e.g.: every few years. In addition, a Major can contain changes from Minor releases.
Minor releases
These contain new features and bug fixes. Breaking changes should not be included here. The one exception is breaking changes for a feature that is too broken and is not worth fixing, especially if that feature is causing maintenance overhead. Minor releases happen maybe 1-3 times per year. In addition, a Minor release can contain changes from Sub releases.
Sub releases
Sub releases are mostly meant for stabilization purposes. Once a Major or Minor release is out, it is possible that critical bugs or issues are found. Given that fixes can't be backported, a sub release is made that includes such critical bug fixes. Sub releases happen a few weeks after a Major or Minor release.
Beta releases
Depending on the number of changes that have been merged since the last release, and on how big and disruptive those changes are, a beta release could be done prior to a Major or Minor. Beta releases are meant to provide an outlook of what the upcoming release will look like, in order to allow users to do early testing and provide feedback. This helps in identifying big issues early on, thereby allowing time to fix them before the final Major or Minor release. Beta releases should not be done for Sub releases.
Overview
This directory contains scripts used to automate the release process of esp8266/Arduino project. The purpose of the release process is to generate the following outputs from the repository:
-
Boards manager package index for Arduino IDE (i.e.
package_esp8266_index.json). See specification of package index file for more info. -
Boards manager package for Arduino IDE. This is a .zip file which contains source code of esp8266/Arduino project, platform.txt, boards.txt and a few other supporting files. See 3-rd party hardware specification for more info about the layout of the boards manager package.
-
Github Release for esp8266/Arduino project. This is used to host the boards manager package mentioned above, and also contains the release notes.
Here is a rough overview of the effective release process. See the section below for detailed instructions.
-
Release process effectively starts when a maintainer pushes a tag into the repository.
-
Travis CI runs a build for this tag, and one of the jobs (with
BUILD_TYPE=package) is used to prepare the boards manager package. This job runsbuild_boards_manager_package.sh. -
build_boards_manager_package.shdoes a few things to build the boards manager package (.zip) file and the json index:- Pack source files into a zip file, excluding some files and tweaking platform.txt.
- Download current latest package index json file from Github Releases. This file contains descriptions of all previous releases.
- Generate package index for the new release.
- Combines new release with previous releases in one json file (using
merge_packages.pyscript).
-
Travis CI uploads boards manager package (.zip file) and package index (.json file) to Github Releases, creating a draft release at the same time.
-
Travis CI also uploads package index .json file to
https://arduino.esp8266.com/stable/package_esp8266_index.json, i.e. well-known URL used by most users. -
When the draft release is created, maintainer edits release description and inserts changelog into the description field, unmarks the release as draft, and publishes the release.
-
Housekeeping is performed in Github issue tracker to close the completed milestone, update issue tags, etc.
Creating a release (for maintainers)
-
Open a new issue to track activities, which will be closed after the release is done. Copy the checklist below into it, and check the steps one by one as they get completed.
-
Make sure that no issues or PRs are assigned to the milestone to be released. If there are any Issues/PRs assigned to the relevant milestone, they should either be addressed, pushed back to a future milestone, or closed.
-
Assemble release notes.
-
Since most changes are integrated into master using squash-rebase policy (i.e. one commit per PR),
git log --onelinegives a good overview of changes in the release. -
Prepare release notes in Markdown format.
-
For changes that are breaking, duplicate those changes and put the duplicate lines into a separate group called Breaking Changes. That group should go at the top of the Changelog. The original lines for the breaking changes should be marked by appending "(Breaking change)" to the line. Example:
Breaking Changes ================ API xyz changed #1234 ... Library - xyz ============= API xyz changed #1234 (Breaking change) ...-
Combine related changes into the following categories, in that order, including breaking changes with the appended mark:
- Breaking Changes
- Core
- Libraries — one section per library that received changes. If library only had a single change or a few changes, it is also okay to combine changes to a few such libraries under single "Other Libraries" entry.
- Upstream dependencies
- Documentation
- Boards
-
Not all commit descriptions which come from
git logwill explain changes well. Reword items as necessary, with the goal that a general user of this project should be able to understand what the change is related to. Preserve references to PRs or issues (#XXXX). -
Aggregate minor fixes (e.g. typos, small documentation changes) in a few items. Focus on preparing a good overview of the release for the users, rather than mentioning every change.
-
When done, put release notes into a private Gist or firepad and send the link to other maintainers for review.
-
The following points assume work in a direct clone of the repository, and not in a personal fork.
-
Make a PR with the following, wait for Travis CI, and merge.
-
platform.txt and package.json: update
versionto the release E.g.3.0.0, -
cores/esp8266/TZ.h: import the latest database with the following shell command:
$ cd tools; sh TZupdate.sh.
-
-
Wait until the release notes have been checked by other maintainers
-
Navigate to Travis CI options, enable ´Build pushed branches´ (before tagging in next step)
-
Tag the latest commit on the master branch. In this project, tags have form
X.Y.Z, e.g.3.0.0, orX.Y.Z-betaNfor release candiate versions. Notice that there's novat the beginning of the tag. Tags must be annotated, not lightweight tags. To create a tag, use git command (assuming that the master branch is checked out):git tag -a -m "Release 3.0.0" 3.0.0navigate to Travis CI options, enable
Build pushed branches,then push the tag created above to esp8266/Arduino Github repository:
git push origin 3.0.0In case something goes wrong, release can be canceled at any time:
-
Tag must be removed (
git tag -d X.Y.Z; git push --delete origin X.Y.Z) -
Release must be deleted: github > releases > edit x.y.z > remove all files > delete button appears
-
-
Wait for Travis CI build for the tag to pass, see https://travis-ci.org/esp8266/Arduino/builds,
-
Check that the new (draft) release has been created (no editing at this point!), see https://github.com/esp8266/Arduino/releases.
-
Check that the boards manager package .zip file has been successfully uploaded as a release artifact.
-
Check that the package index downloaded from https://arduino.esp8266.com/stable/package_esp8266com_index.json contains an entry for the new version (it may not be the first one).
-
Return to the Travis CI options and disable
Build pushed branches. -
Navigate to release list in Github here https://github.com/esp8266/Arduino/releases, press "Edit" button to edit release description, paste release notes, and publish it.
-
In the issue tracker, remove "staged-for-release" label for all issues which have it, and close them. Close the milestone associated with the released version (the milestone should be empty per point 2 above)
-
Check that https://arduino-esp8266.readthedocs.io/en/latest/ has a new doc build for the new tag, and that "stable" points to that build. If a new build did not trigger, log into readthedoc's home here https://readthedocs.org/ (account must have been added to project as maintainer) and trigger it manually.
-
Create a commit to the master branch, updating:
-
The version in platform.txt and package.json files. This should correspond to the version of the next milestone, plus
-devsuffix. E.g.3.1.0-dev. -
In main README.md go to "Latest release" section, change version number in the readthedocs link to the version which was just released, and verify that all links work.
-
Checklist helper, copy-paste into Release Process issue
--------------COPY BELOW THIS LINE--------------
[Reference](https://github.com/esp8266/Arduino/tree/master/package#creating-a-release-for-maintainers) for details.
- [ ] 1. Open a new issue to track activities.
- [ ] 2. Make sure that no issues or PRs are assigned to the milestone to be released.
- [ ] 3. Assemble release notes.
- [ ] 4. Make a PR with the following, [wait for Travis CI](https://travis-ci.org/github/esp8266/Arduino/builds/), and merge.
* [platform.txt](https://github.com/esp8266/Arduino/blob/master/platform.txt)
* [package.json](https://github.com/esp8266/Arduino/blob/master/package.json)
* [cores/esp8266/TZ.h](https://github.com/esp8266/Arduino/blob/master/cores/esp8266/TZ.h)
- [ ] 5. Wait until the release notes have been checked by other maintainers
- [ ] 6. Navigate to [Travis CI options](https://travis-ci.org/esp8266/Arduino/settings), enable ´Build pushed branches´ (before tagging in next step)
- [ ] 7. Tag the latest commit on the master branch, then push it to esp8266/Arduino
- [ ] 8. Wait for Travis CI build for the tag to pass, see https://travis-ci.org/esp8266/Arduino/builds,
- [ ] 9. Check that the new (draft) release has been created (no editing at this point!), see https://github.com/esp8266/Arduino/releases.
- [ ] 10. Check that the boards manager package .zip file has been successfully uploaded as a release artifact.
- [ ] 11. Check that the package index downloaded from https://arduino.esp8266.com/stable/package_esp8266com_index.json contains an entry for the new version (it may not be the first one).
- [ ] 12. Return to the [Travis CI options](https://travis-ci.org/esp8266/Arduino/settings) and disable `Build pushed branches`.
- [ ] 13. Navigate to [release list in Github](https://github.com/esp8266/Arduino/releases), press "Edit" button to edit release description, paste release notes, and publish it.
- [ ] 14. In the issue tracker, remove "staged-for-release" label for all issues which have it, and close them. Close the milestone associated with the released version (the milestone should be empty per point 2 above)
- [ ] 15. Check that https://arduino-esp8266.readthedocs.io/en/latest/ has a new doc build for the new tag, and that "stable" points to that build. If a new build did not trigger, log into readthedoc's home here https://readthedocs.org/ (account must have been added to project as maintainer) and trigger it manually.
- [ ] 16. Create a commit to the master branch, updating:
* The version in platform.txt and package.json files. This should correspond to the version of the *next* milestone, plus `-dev` suffix. E.g. `3.1.0-dev`.
* In main README.md go to "Latest release" section, change version number in the readthedocs link to the version which was just released, and verify that all links work.
--------------COPY ABOVE THIS LINE--------------