search

earlephilhower / newlib-xtensa

newlib-xtensa fork intended for esp8266
GNU General Public License v2.0
5 stars 7 forks source link

Symbol stripping #6

Closed mikee47 closed 4 years ago

mikee47 commented 4 years ago

I note that memcpy, memset, etc. are still present in the generated libc.a. Is the intention to remove these or handle symbol stripping separately?

mikee47 commented 4 years ago

Wrong repo. Sorry.

earlephilhower commented 4 years ago

esp-quick-toolchain removes this as part of the repo release packaging.

.stage.LINUX.install:
        echo STAGE: $@
        rm -rf $(ARDUINO)
        git clone https://github.com/$(GHUSER)/Arduino $(ARDUINO)
        (cd $(ARDUINO) && git checkout $(INSTALLBRANCH) && git submodule init && git submodule update)
        echo "-------- Building installable newlib"
        rm -rf arena/newlib-install; mkdir -p arena/newlib-install
        cd arena/newlib-install; $(call setenv,$@); $(REPODIR)/newlib/configure $(CONFIGURENEWLIBINSTALL); $(MAKE); $(MAKE) install
        echo "-------- Removing routines present in ROM"
        ar dv $(ARDUINO)/tools/sdk/libc/xtensa-lx106-elf/lib/libc.a lib_a-strcmp.o lib_a-strlen.o lib_a-strncmp.o lib_a-strstr.o lib_a-memcmp.o lib_a-memcpy.o lib_a-memmove.o lib_a-memset.o lib_a-bzero.o
mikee47 commented 4 years ago

So the stripping is only done for the arduino upload? I'm using the release archives which appear to have the definitions intact.

mikee47 commented 4 years ago

Just curious, you're stripping symbols from libgcc.a in the release packages, but not libc.a. Is there a reason they're treated differently?

earlephilhower commented 4 years ago

The reason it's being done (or supposed to be done, I will double-check!) is jlegacy. We always did it manually after a build, so I captured that in the repo makfile. The I should probably stop being lazy and do it here.

I think I know where the problem lies, and it's related to this.

We actually have 2 copies of libc.a in the Arduino code. One is in the cross-built gcc directory tools/xtensa-..., one is in the tools/sdk/libc/... (again, a legacy decision made way before I started working on it). Our link path makes sure the tools/sdk/libc one is used, and that's the only one EQT cleans up.

Let me take a look at the makefile here. It would be saner to drop the always useless bits here...

earlephilhower commented 4 years ago

Give the new head a build. I couldn't find a clean way of updating the makefile (autoconf is an ugly beast), so the actual source files have been modified to generate no code. There will be a libc-a-memcpy.o in the archive, but it won't have any implementation of memcpy in it, for example.

EQT also updated to drop the cleanup it was doing on the installation.

mikee47 commented 4 years ago

Library changes work a treat, thank you! I can ditch the local copies now :-)