Enable libstdc++ #144

Sermus · 2016-03-30T10:42:26Z

What was the goal?

The goal was letting developers use libstdc++ in esp-open-sdk environment

What had to be done?

The configuration of crosstool-NG (for the revision esp-open-sdk pulled in) was incorrect to some extent. Particularly newlib was built without -mlongcalls and with internal memory management routines, libstdc++ was built without -fno-exceptions and -fno-rtti. This caused STL-based code fail to compile and link. These issues had to be fixed prior to compiling any STL code.

What has been done?

In order to make STL code compilable and executable on esp8266 a handful of things were done. Many of them have their on value even boyond STL context. They are:

Switching crosstool-NG to the jcmvbkbc's xtensa-1.22.x branch where all the necessary fixes for newlib and libstdc++ are in.
Pulling in libnlport library bridging libc (newlib) and Espressif SDK by implementing (mostly stubbing) syscalls and memory management routines. Can be used with newlib in pure-C projects.
Pulling in libstdc++port library. It defines new/delete operators on top of Espressif memory manager.
Enabling libnlport and libstdc++port build in esp-open-sdk.
Switching esptool to original themadinventor repo to pull in the latest changes, particularly an ability to cook OTA images.
Cooking romized version of libstdc++ (named libstdc++irom) like it was done for libcirom
Patches for creating romized versions of eagle.app.v6.ld and eagle.app.v6.new.2048.ld linker scripts. Romized scripts force .literal.* and .text.* sections which contain most of libstdc++ go to irom.
Pulling in SGI STL tests ported to esp8266 as a test sample to demonstrate STL is working.

Doubts

There is a patch called 1000-mforce-l32.patch which initially was applied to GCC 4.8.2. I reaimed it to GCC 4.8.5 which is built by the new version of crosstool-NG, but since i don't know why this patch was initially applied to 4.8.2 i doubt if it's necessary for 4.8.5.

…ith crosstool-ng.xtensa-1.22.x. Added romized version of libstdc++

…anch

…GI STL tests port added

pfalcon · 2016-03-30T11:42:15Z

.gitmodules

@@ -7,7 +7,7 @@
 	url = https://github.com/tommie/lx106-hal
 [submodule "esptool"]
 	path = esptool
-	url = https://github.com/pfalcon/esptool
+	url = https://github.com/themadinventor/esptool.git


I don't plan to switch to upstream repo. See espressif/esptool#89 (comment) why.

Ok, i see the reason. Does this mean that your esptool fork stays where it is not pulling changes from the origin? What about quite useful ones like cooking OTA images?

Of course no, I pull changes in (from time to time, especially after prodding), maintain my own changes on top from time to time, and hope to never need to revert anything (but still reserve a room for). I just pulled bunch of changes, would like to test them first before pulling the rest.

Got it. Looking forward to other comments.

The "--version=2" changes are needed. Without them there is no way to create a >512KB image (like the one sgi tests produce). Of course we could create a linker script which would create canonical 0x00000/0x40000 image of 1MB+ size but using OTA images and 1/2/4MB linker scripts already provided by Espressif seems to be a better solution, doesn't it?

jcmvbkbc · 2016-03-30T15:38:10Z

Particularly newlib was built without -mlongcalls and with internal memory management routines, libstdc++ was built without -fno-exceptions and -fno-rtti.

-mlongcalls was missing from the libstdc++ build, newlib has always been built with that flag.

This caused STL-based code fail to compile and link.

IIRC there were only link failures.

jcmvbkbc · 2016-03-30T15:47:33Z

Makefile

@@ -164,7 +163,7 @@ _libhal:

 libnlport: $(TOOLCHAIN)/xtensa-lx106-elf/sysroot/usr/lib/libnlport.a

-$(TOOLCHAIN)/xtensa-lx106-elf/sysroot/usr/lib/libnlport.a: $(TOOLCHAIN)/bin/xtensa-lx106-elf-gcc
+$(TOOLCHAIN)/xtensa-lx106-elf/sysroot/usr/lib/libnlport.a: $(TOOLCHAIN)/bin/xtensa-lx106-elf-gcc sdk sdk_patch toolchain standalone
 	make -C esp_newlib_port -f ../Makefile _libnlport
 	cp -f esp_newlib_port/libnlport.a $(TOOLCHAIN)/xtensa-lx106-elf/sysroot/usr/lib/libnlport.a



This patch should probably be folded into the "Build procedure for libnlport.a. esp_newlib_port switched to lx106 branch".

Sermus · 2016-03-31T06:38:42Z

Guys, please let me know if there are more comments to come. If not i'll prepare another pull request taking into account the hints you've already made.

Sermus · 2016-03-31T06:41:00Z

What about 1000-mforce-l32.patch? Do we still need it in GCC 4.8.5?

jcmvbkbc · 2016-03-31T06:53:33Z

What about 1000-mforce-l32.patch? Do we still need it in GCC 4.8.5?

It adds a switch to compiler that forces it to read 8- and 16-bit wide data with aligned 32-bit wide loads. May be used to access char/short data in FLASH/IRAM without source code changes. See SuperHouse/esp-open-rtos#11
I guess @pfalcon found use cases for it, so it should probably be kept.
There should be no issues applying it to gcc-4.8.5, but it will conflict with 870-xtensa-add-mauto-litpools-option.patch from gcc-4.9.3 and gcc-5.2.0

I don't have other review comments, and those that I made are of course just suggestions based on personal maintenance habits.

jcmvbkbc · 2016-03-31T07:03:50Z

Sorry, one more note: libnl is a well-known name for netlink library, you should probably choose a different name for newlib glue.

Sermus · 2016-03-31T07:07:08Z

ok, let me rename it to libnewlibport, no better naming i can suggest )

Sermus · 2016-04-05T04:01:17Z

Closing this one down since I raised a refined pull request #146

Sermus added 12 commits March 28, 2016 12:02

Switched crosstool-ng to xtensa-1.22.x branch

a0319ba

GCC patches retargetted from 4.8.2 to 4.8.5 to make them compatible w…

fa85e2a

…ith crosstool-ng.xtensa-1.22.x. Added romized version of libstdc++

Build procedure for libnlport.a. esp_newlib_port switched to lx106 br…

f930fb2

…anch

libnlport is compiled after the combined toolchain is ready

bbb55ab

esptool was switched to original themadinventor repo

a26206b

Added romized versions of ld scripts

11ae0d0

Romized linked script patch added. Submodule esp_stdcpp_port added. S…

64dfb5e

…GI STL tests port added

Added building libstdc++port lib into Makefile

cdf2aa3

esp_stdcpp_port submodule switched to lx106 branch

87a96e4

Esptool retargetted to the original repo

3f0057b

Completeing retargetting submodules

7a1b990

Completeing retargetting submodules

7773422

pfalcon reviewed Mar 30, 2016
View reviewed changes

jcmvbkbc reviewed Mar 30, 2016
View reviewed changes

Sermus mentioned this pull request Apr 1, 2016

Enable libstdc++ v2 #146

Open

Sermus closed this Apr 5, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable libstdc++ #144

Enable libstdc++ #144

Sermus commented Mar 30, 2016

pfalcon Mar 30, 2016

Sermus Mar 30, 2016

pfalcon Mar 30, 2016

Sermus Mar 30, 2016

Sermus Mar 31, 2016

jcmvbkbc commented Mar 30, 2016

jcmvbkbc Mar 30, 2016

Sermus commented Mar 31, 2016

Sermus commented Mar 31, 2016

jcmvbkbc commented Mar 31, 2016

jcmvbkbc commented Mar 31, 2016

Sermus commented Mar 31, 2016

Sermus commented Apr 5, 2016

Enable libstdc++ #144

Enable libstdc++ #144

Conversation

Sermus commented Mar 30, 2016

What was the goal?

What had to be done?

What has been done?

Doubts

pfalcon Mar 30, 2016

Choose a reason for hiding this comment

Sermus Mar 30, 2016

Choose a reason for hiding this comment

pfalcon Mar 30, 2016

Choose a reason for hiding this comment

Sermus Mar 30, 2016

Choose a reason for hiding this comment

Sermus Mar 31, 2016

Choose a reason for hiding this comment

jcmvbkbc commented Mar 30, 2016

jcmvbkbc Mar 30, 2016

Choose a reason for hiding this comment

Sermus commented Mar 31, 2016

Sermus commented Mar 31, 2016

jcmvbkbc commented Mar 31, 2016

jcmvbkbc commented Mar 31, 2016

Sermus commented Mar 31, 2016

Sermus commented Apr 5, 2016