Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code size increase of 6k in esp-quick-toolchain #7107

Closed
6 tasks done
Jason2866 opened this issue Feb 24, 2020 · 9 comments · Fixed by #7109
Closed
6 tasks done

Code size increase of 6k in esp-quick-toolchain #7107

Jason2866 opened this issue Feb 24, 2020 · 9 comments · Fixed by #7109
Assignees

Comments

@Jason2866
Copy link
Contributor

Basic Infos

  • This issue complies with the issue POLICY doc.
  • I have read the documentation at readthedocs and the issue is not addressed there.
  • I have tested that the issue is present in current master branch (aka latest git).
  • I have searched the issue tracker for a similar issue.
  • If there is a stack dump, I have decoded it.
  • I have filled out all fields below.

Platform

  • Hardware: [ESP-12|other]
  • Core Version: [latest git hash vs. commit 6be5616]
  • Development Env: [Platformio]
  • Operating System: [Windows|Ubuntu]

Settings in IDE

  • Module: [Nodemcu]
  • Flash Mode: [dout]
  • Flash Size: [1MB]
  • lwip Variant: [v2 Lower Memory|Higher Bandwidth]
  • Reset Method: [nodemcu]
  • Flash Frequency: [40Mhz]
  • CPU Frequency: [80Mhz]
  • Upload Using: [OTA|SERIAL]
  • Upload Speed: [115200] (serial upload only)

Problem Description

Not a bug. But since commit #6be561617f645f6a2ae82b8211f6af8c43e834cf and latest stage
there is a code size increase about 6k in the esp-quick-toolchain.
Code size with commit #6be..
image

and with latest stage

image

Is there a big change in functions that explains that code size increase?
Thx!

@devyte
Copy link
Collaborator

devyte commented Feb 24, 2020

Are you sure that's the right commit? It's just an eboot minor thing and readme.

@Jason2866
Copy link
Contributor Author

Ahh, sorry did not explain correctly. We noticed the code size increase because we build Tasmota (freezed stage) on the commit (#6be56..). So a commit between this and the latest does the code size increase

@devyte
Copy link
Collaborator

devyte commented Feb 24, 2020

@Jason2866 can you please help narrow down the specific commit?

@Jason2866
Copy link
Contributor Author

Will do

@Jason2866
Copy link
Contributor Author

Sorry cant narrow down more, since commit f066ed2 brakes
compiling code of Tasmota (before code size has NOT increased) after commit f69e404
(which made possible to compile Tasmota again) code size has increased

@earlephilhower
Copy link
Collaborator

Could you upload the elf from both versions? We can objdump it to get individual function sizes and compare.

@Jason2866
Copy link
Contributor Author

The elf files from both
pack.zip

@earlephilhower
Copy link
Collaborator

earlephilhower commented Feb 24, 2020

Looks like timezone related. One has sscanf, tz*, get/setenv, and ungetc.

You can do it yourself:
objdump -t firmware.elf | sort -k6 | awk '{print $6 " " $5}' > fcns.a
(repeat for the other version, then diff fcns.a fcns.b

168a169
> alloced$1945 00000004
380a382
> _daylight 00000004
423c425
< dhcp_handle_ack$isra$3 000000e0
---
> dhcp_handle_ack$isra$3 000000e8
440c442
< dhcp_set_ntp_servers 0000003c
---
> dhcp_set_ntp_servers 00000027
516c518
< dtostrf 000001ed
---
> dtostrf 000001f9
533a536,541
> environ 00000004
> environ.c 00000000
> __env_lock 00000015
> envlock.c 00000000
> __env_lock_object 00000004
> __env_unlock 00000015
568,569c576,577
< __esp_yield 0000001e
< esp_yield 0000001e
---
> __esp_yield 00000027
> esp_yield 00000027
632a641
> _findenv_r 000000a5
641,647c650,656
< flash_str$3778 00000014
< flash_str$3782 00000014
< flash_str$3836 0000001c
< flash_str$3849 00000013
< flash_str$3854 00000015
< flash_str$4964 00000025
< flash_str$5352 00000016
---
> flash_str$3777 00000014
> flash_str$3781 00000014
> flash_str$3835 0000001c
> flash_str$3848 00000013
> flash_str$3853 00000015
> flash_str$4960 00000025
> flash_str$5348 00000016
720a730,731
> _getenv_r 00000011
> getenv_r.c 00000000
732a744,745
> __gettzinfo 00000005
> gettzinfo.c 00000000
960a974
> initial_env 00000004
1012c1026
< iss$5324 00000004
---
> iss$5320 00000004
1113c1127
< lwip_standard_chksum 00000068
---
> lwip_standard_chksum 000000a0
1169a1184,1185
> __month_lengths 00000060
> month_lengths.c 00000000
1189a1206,1207
> nano-vfscanf.c 00000000
> nano-vfscanf_i.c 00000000
1241c1259
< optimistic_yield 0000002e
---
> optimistic_yield 0000002b
1267a1286
> pbuf_get_contiguous 00000054
1462a1482
> prev_tzenv 00000004
1605a1626,1627
> _scanf_chars 0000010b
> _scanf_i 0000028b
1616a1639,1640
> __sccl 0000007c
> sccl.c 00000000
1647a1672,1675
> setenv 00000021
> setenv.c 00000000
> _setenv_r 000001a7
> setenv_r.c 00000000
1656c1684
< settimeofday 000000cc
---
> settimeofday 000000c5
1684a1713,1714
> siscanf 0000006d
> _siscanf_r 0000006d
1708a1739
> sntp_getservername 00000010
1712a1744
> sntp_real_timestamp 00000004
1724c1756,1757
< sntp_set_timezone 0000001e
---
> sntp_set_timezone 00000027
> sntp_set_timezone_in_seconds 0000003d
1751a1785,1787
> sscanf 0000006d
> sscanf.c 00000000
> _sscanf_r 0000006d
1754a1791,1793
> __ssrefill_r 0000004a
> __ssvfiscanf_r 000003fa
> __ssvfscanf_r 000003fa
1819a1859,1860
> __submore 00000081
> _sungetc_r 0000008f
2030a2072
> _timezone 00000004
2089a2132,2146
> __tzcalc_limits 00000183
> tzcalc_limits.c 00000000
> tzinfo 00000040
> __tz_lock 00000015
> tzlock.c 00000000
> __tz_lock_object 00000004
> _tzname 00000008
> __tzname_dst 0000000b
> __tzname_std 0000000b
> tzset 00000017
> tzset.c 00000000
> _tzset_r 0000036c
> tzset_r.c 00000000
> __tz_unlock 00000015
> tzvars.c 00000000
2159a2217,2219
> ungetc 0000001b
> ungetc.c 00000000
> _ungetc_r 0000016f
2162a2223,2224
> unsetenv 00000019
> _unsetenv_r 0000007a
2433c2495
< xid$5282 00000004
---
> xid$5280 00000004
2500a2563
> .xt.lit._ZN13ClientContext9acceptPCBEv 00000000
2709a2773
> .xt.prop._ZN13ClientContext9acceptPCBEv 00000000
2913,2914c2977,2978
< yield 00000034
< __yield 00000034
---
> yield 0000003c
> __yield 0000003c
2938a3003,3004
> _Z10configTimeiiPKcS0_S0_ 00000078
> _Z10configTimePKcS0_S0_S0_ 0000007e
3624c3690
< _Z3maplllll 00000030
---
> _Z3maplllll 00000033
3786c3852
< _Z9RtcSecondv 0000028b
---
> _Z9RtcSecondv 00000287
3908d3973
< _ZL14realtime_stamp 00000004
4039d4103
< _ZL22s_micros_at_task_start 00000004
4044a4109
> _ZL23s_cycles_at_yield_start 00000004
4060d4124
< _ZL3dst 00000002
4096c4160
< _ZL9loop_taskP11ETSEventTag 0000003e
---
> _ZL9loop_taskP11ETSEventTag 0000003b
4100d4163
< _ZL9time_zone 00000004
4157c4220
< _ZN10WiFiClient7connectE9IPAddresst 00000147
---
> _ZN10WiFiClient7connectE9IPAddresst 0000014f
4181c4244,4245
< _ZN10WiFiServer5beginEt 00000075
---
> _ZN10WiFiServer5beginEt 00000017
> _ZN10WiFiServer5beginEth 0000007f
4186,4187c4250,4251
< _ZN10WiFiServer7_acceptEP7tcp_pcbl 00000095
< _ZN10WiFiServer9availableEPh 00000052
---
> _ZN10WiFiServer7_acceptEP7tcp_pcbl 00000067
> _ZN10WiFiServer9availableEPh 0000005a
4294a4359
> _ZN13ClientContext9acceptPCBEv 00000042
4710c4775
< _ZN7WiFiUDP11parsePacketEv 0000008d
---
> _ZN7WiFiUDP11parsePacketEv 000000a2
4713c4778
< _ZN7WiFiUDP4peekEv 0000001d
---
> _ZN7WiFiUDP4peekEv 00000029
4715,4716c4780,4781
< _ZN7WiFiUDP4readEPhj 00000053
< _ZN7WiFiUDP4readEv 00000028
---
> _ZN7WiFiUDP4readEPhj 0000006b
> _ZN7WiFiUDP4readEv 0000003b
4722,4723c4787,4788
< _ZN7WiFiUDP7stopAllEv 00000027
< _ZN7WiFiUDP8remoteIPEv 00000030
---
> _ZN7WiFiUDP7stopAllEv 00000026
> _ZN7WiFiUDP8remoteIPEv 0000002f

@earlephilhower
Copy link
Collaborator

And, in case it wasn't obvious, the format above is "C++ mangled name, bytes in hex"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants