Q: both S and M in .section flags #19
Comments
|
Hmmm...I'm not sure I get the nature of the problem, sorry. The string coalescing will definitely generate non-32b aligned PSTRs, but all the PSTR code does support non-32b starting strings. I don't think this would affect |
|
Yeah, sorry for too early of an issue as this is very likely not the case. Experimenting with suffix-merging some strings, even having a standalone one that would match the suffix, has everything working correctly and alignment also works itself out when strings are on a 4 byte boundary. And I think I missed the part that these are C strings with a '\0' as part of the blob. While this is not technically a newlib problem... revisiting the broken .elf once more, it has some weird structure to the generated function right where the PSTR(...) happened to be. The missing piece does some arithmetic at the beginning which causes an exception where the address became 0x0f4e0000. The correctly working one simply loads 2 pointers to the lambda and the __pstr__, and also what I see with the current gcc10.3 toolchain. void _mqttInitCommands() {
terminalRegisterCommand(F("MQTT.RESET"), [](const terminal::CommandContext&) { ... });
terminalRegisterCommand(F("MQTT.INFO"), [](const terminal::CommandContext&) { ... });(gdb) disassemble 0x402083a4
Dump of assembler code for function _mqttInitCommands():
0x402083a4 <+0>: l32r a3, 0x40208398
0x402083a7 <+3>: movi a2, 0x7a7
0x402083aa <+6>: addi a1, a1, -16
0x402083ad <+9>: slli a2, a2, 17
0x402083b0 <+12>: s32i a0, a1, 12
0x402083b3 <+15>: call0 0x40213488 <terminalRegisterCommand(__FlashStringHelper const*, void (*)(terminal::CommandContext const&))>
0x402083b6 <+18>: l32r a3, 0x4020839c
0x402083b9 <+21>: l32r a2, 0x402083a0
0x402083bc <+24>: call0 0x40213488 <terminalRegisterCommand(__FlashStringHelper const*, void (*)(terminal::CommandContext const&))>
0x402083bf <+27>: l32i a0, a1, 12
0x402083c2 <+30>: addi a1, a1, 16
0x402083c5 <+33>: ret.n
End of assembler dump.
(gdb) x (*0x4020839c)
0x40208380 <_FUN(terminal::CommandContext const&)>: 0x02f0c112
(gdb) p (const char*)(*0x402083a0)
$1 = 0x4026fa70 <_mqttInitCommands()::__pstr__> "MQTT.INFO"
(gdb) x (*0x40208398)
0x40209c70 <_FUN(terminal::CommandContext const&)>: 0x02f0c112 |
|
Also, I've noticed this patch at the gcc repo which kind of looks like the resulting code where l32r is supposed to be replaced by the movi + shift: But, without a reproducible example, idk if I'd claim this a toolchain bug just yet. |
|
FWIW that patch also exists in the 10.3 toolchain. IIRC it was changes to reduce generated code size for some subset of constant values. |
|
There's also esp8266/Arduino#8189 (comment) which mentioned semi-random issues, but the report got lost in the other discussion thread. There's a full build directory, too, which I grabbed and tried to compare certain pieces of code. Like, there is similar Reading symbols from ESP_Easy_mega_20210624_normal_300_ESP8266_4M1M.elf...
(gdb) disassemble _Z11CPlugin_003N7CPlugin8FunctionEP11EventStructR6String
...
0x4021d406 <+18>: bgeu a3, a2, 0x4021d40c <_Z11CPlugin_003N7CPlugin8FunctionEP11EventStructR6String+24>
0x4021d409 <+21>: j 0x4021d538 <_Z11CPlugin_003N7CPlugin8FunctionEP11EventStructR6String+324>
0x4021d40c <+24>: movi a3, 0x4e1
0x4021d40f <+27>: slli a3, a3, 18
0x4021d412 <+30>: addx4 a2, a2, a3
0x4021d415 <+33>: l32i.n a2, a2, 0
0x4021d417 <+35>: jx a2
...But this piece does not look like this when I try building it with a clean directory: (gdb) disassemble _Z11CPlugin_003N7CPlugin8FunctionEP11EventStructR6String
...
0x40216336 <+18>: bgeu a3, a2, 0x4021633c <_Z11CPlugin_003N7CPlugin8FunctionEP11EventStructR6String+24>
0x40216339 <+21>: j 0x40216468 <_Z11CPlugin_003N7CPlugin8FunctionEP11EventStructR6String+324>
0x4021633c <+24>: l32r a3, 0x40216310
0x4021633f <+27>: addx4 a2, a2, a3
0x40216342 <+30>: l32i.n a2, a2, 0
0x40216344 <+32>: jx a2
...(but idk how to continue inspecting, since 0x40216310 seems to point to some place inside of the function itself and it does not seem to do so in the calculation above with movi and resolves to some pre-linking address instead) And the symptoms sound very similar:
cc @jjsuwa-sys3175 nonetheless, maybe the above makes some sense |
|
Another interesting thing, which really points to the toolchain. Running the following script on Windows: With xtensa-lx106-elf-g++ binary in PATH: The same script running on a WSL Linux instance does nothing all of 1024 iterations. edit: After failing once, script has an added |
|
@mcspr thanks for quick test script first, fetched from https://github.com/earlephilhower/esp-quick-toolchain, and locally-built on debootstraped x86_64 Debian Buster: ok, that seems no flaws. next, downloaded 2 pre-built toolchains from https://github.com/esp8266/Arduino, "i686-mingw32" and "x86_64-mingw32": "i686-mingw32" "i686-mingw32" seems no problem. "x86_64-mingw32" whoa! what is the differences between? |
|
we have the big question: "what's happening?" place this as "gcc-xtensa-rearrange-DI-mode-constant-loading-debug-probe.patch" on /patches/gcc10.3/. and then rebuild the toolchain (especially for "x86_64-mingw32"). [example] |
|
From the example above it's a definitive constant, but why does pointer becomes a constant thing? It feels like there's another layer broken, and the constants-loading patch just happened to detect it. I have tried building locally, but no success so far with GCC=10.3 and a modified Makefile with gcc-gnu master build without patches. |
It still fails the test above: a433474aa40ab0f6433f9240455fd624> py -3 .\trying.py --cxx ".\x86_64-w64-mingw32.xtensa-lx106-elf-1757bed.210826\xtensa-lx106-elf\bin\xtensa-lx106-elf-g++.exe"
Using built-in specs.
COLLECT_GCC=.\x86_64-w64-mingw32.xtensa-lx106-elf-1757bed.210826\xtensa-lx106-elf\bin\xtensa-lx106-elf-g++.exe
COLLECT_LTO_WRAPPER=c:/users/maxim/documents/gist/a433474aa40ab0f6433f9240455fd624/x86_64-w64-mingw32.xtensa-lx106-elf-1757bed.210826/xtensa-lx106-elf/bin/../libexec/gcc/xtensa-lx106-elf/12.0.0/lto-wrapper.exe
Target: xtensa-lx106-elf
Configured with: /home/builder/dev/esp-quick-toolchain/repo/gcc-gnu/configure --prefix=/home/builder/dev/esp-quick-toolchain/xtensa-lx106-elf.win64 --build=x86_64-linux-gnu --host=x86_64-w64-mingw32 --target=xtensa-lx106-elf --disable-shared --with-newlib --enable-threads=no --disable-__cxa_atexit --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --disable-bootstrap --enable-languages=c,c++ --enable-lto --enable-static=yes --disable-libstdcxx-verbose
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210825 (experimental) (GCC)
[1/1024] (287)
_Z8functionv:
test.S:1174: movi a3, 0x37b
test.S:1175: slli a3, a3, 17I guess it's enough for an upstream gcc bug? Unless there are other things to test; build flags specific to mingw, mingw version, included 'blob' archives, etc. btw, should the issue be moved to esp-quick-toolchain? Running Debian 11 installation with mingw8, gcc10.2 and trying to build the current gcc master by hijacking the current config and replacing GCC=version with 05ace2946b4369b49026789d5a83635076b10422 (`master` at the time of writing).Some sidenotes:
Actually relevant to the build process:
|
|
@mcspr thanks for pointing me here. Looks interesting to see if this indeed is a compiler/linker bug that's been bugging us for quite some time. I was just wondering, since you started mentioning the flash string optimization, whether this is a bug that's only (mainly) manifests on Windows? In another issue you also mentioned a thought about some code being recompiled, but the string which was first a flash string duplicate (or partial duplicate) then was no longer present. But the objects using such a (partial) duplicate flash string may still refer to it. |
Just a speculation, first message proved to be incorrect and everything works as expected with the flash string(s) suffix merging. With the gist above, compiler loses / replaces the real pointer with a different instruction via an optimization that is only supposed to happen on constants, which these pointers are really not. ref.
Which sometimes seem to match the address that happens here. edit: Or, it is missing some additional condition that will check whether the referenced thing can actually be optimized? Upon further observation, generated addresses under mingw build are fairly short: While on the linux build it's something like '0x7f4f316d9fc0', which obviously does not fit the operand for a very long time |
|
re. re. reading the above, should the l32r+slli conversion also check for CONST_INT_P(src)(https://code.woboq.org/gcc/gcc/rtl.h.html#770) In case of PSTR(...) / function ptr, it's SYMBOL_REF_P(src)Which should probably be kept as-is? |
seems to be good workaround :) patches/gcc10.3/gcc-xtensa-reject-symbol-refs-from-constant-synthesis.patch: (edit: replaced |
what a proper fix would be though? |
ah, that's more safer way: |
|
Also submitted at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102115 |
|
should we contact @jcmvbkbc, the Xtensa port's maintainer? |
yeah, I wasn't sure what to do about that in the bugzilla interface. hope this ping is enough |
|
@mcspr @jjsuwa-sys3175 thanks for tagging me. I agree with the fix posted here and will commit it to the master and to the gcc-11 branch. |
|
I've also found that configuring gcc with |
|
hi @jcmvbkbc: |
@jjsuwa-sys3175 I don't. So far majority of issues were reported in a project-specific manner for the project that found them, mainly on project mailing lists. Perhaps reporting an issue on the gcc mailing list would work too, I can't recall anyone doing that for the xtensa target though. Regardless of how I'm notified of the issue I usually file a bugzilla entry for gcc or binutils. I understand that github issues looks simpler than gcc mailing list or gcc bugzilla.
This repo predates gcc switch to git so its history doesn't match bit-for-bit the current official gcc git tree. And github is not a part of my gcc workflow, so pushing code to the master there is not something that happens naturally. But that probably shouldn't inhibit reporting bugs there. |
|
GCC issue is still pending, but... returning to the original question. Given the following example: #ifdef NATIVE
#include <cstdint>
#include <cstdio>
#include <iterator>
#else
#include <Arduino.h>
#endif
void addresses(const char* const begin, const char* const end) {
::printf("%p:%p -> %.*s (%u)\n", begin, end, end - begin, begin, end - begin);
}
template <size_t Size>
void addresses(const char (&buf)[Size]) {
addresses(std::begin(buf), std::end(buf));
}
void test() {
addresses("");
addresses(","); // broken
addresses("999::");
addresses("-5:doesntmatter");
}
#ifndef NATIVE
void setup() {
Serial.begin(115200);
delay(1000);
::printf("\n\n\n");
test();
}
void loop() {
delay(100);
}
#else
int main() {
::puts("\n\n\n");
test();
}
#endifOutput is: |
FTR, I cannot reproduce this with the mainline xtensa gcc. |
Using current esp8266 arduino 3.0.2 toolchain based on gcc10.3, with platformio as builder for the example above main.cpp.S
.file "main.cpp"
.text
.section .rodata._Z9addressesPKcS0_.str1.1,"aMS",@progbits,1
.LC0:
.string "%p:%p -> (%d)\n"
.section .text._Z9addressesPKcS0_,"ax",@progbits
.literal_position
.literal .LC1, .LC0
.align 4
.global _Z9addressesPKcS0_
.type _Z9addressesPKcS0_, @function
_Z9addressesPKcS0_:
sub a5, a3, a2
mov.n a4, a3
mov.n a3, a2
l32r a2, .LC1
addi sp, sp, -16
s32i.n a0, sp, 12
call0 printf
l32i.n a0, sp, 12
addi sp, sp, 16
ret.n
.size _Z9addressesPKcS0_, .-_Z9addressesPKcS0_
.section .rodata._Z4testv.str1.1,"aMS",@progbits,1
.LC2:
.string ""
.LC5:
.string ","
.LC8:
.string "999::"
.LC11:
.string "-5:doesntmatter"
.section .text._Z4testv,"ax",@progbits
.literal_position
.literal .LC3, .LC2+1
.literal .LC4, .LC2
.literal .LC6, .LC5+2
.literal .LC7, .LC5
.literal .LC9, .LC8+6
.literal .LC10, .LC8
.literal .LC12, .LC11+16
.literal .LC13, .LC11
.align 4
.global _Z4testv
.type _Z4testv, @function
_Z4testv:
l32r a3, .LC3
l32r a2, .LC4
addi sp, sp, -16
s32i.n a0, sp, 12
call0 _Z9addressesPKcS0_
l32r a3, .LC6
l32r a2, .LC7
call0 _Z9addressesPKcS0_
l32r a3, .LC9
l32r a2, .LC10
call0 _Z9addressesPKcS0_
l32r a3, .LC12
l32r a2, .LC13
call0 _Z9addressesPKcS0_
l32i.n a0, sp, 12
addi sp, sp, 16
ret.n
.size _Z4testv, .-_Z4testv
.section .rodata.setup.str1.1,"aMS",@progbits,1
.LC15:
.string "\n\n\n"
.section .text.setup,"ax",@progbits
.literal_position
.literal .LC14, Serial
.literal .LC16, .LC15
.align 4
.global setup
.type setup, @function
setup:
movi.n a7, 0
l32r a2, .LC14
movi a3, 0xe1
addi sp, sp, -16
movi.n a6, 1
mov.n a5, a7
movi.n a4, 0x1c
slli a3, a3, 9
s32i.n a0, sp, 12
call0 _ZN14HardwareSerial5beginEm12SerialConfig10SerialModehb
l32r a2, .LC16
call0 puts
call0 _Z4testv
l32i.n a0, sp, 12
addi sp, sp, 16
ret.n
.size setup, .-setup
.section .text.loop,"ax",@progbits
.literal_position
.align 4
.global loop
.type loop, @function
loop:
ret.n
.size loop, .-loop
.weak BUILTIN_LED
.section .rodata.BUILTIN_LED,"a"
.align 4
.type BUILTIN_LED, @object
.size BUILTIN_LED, 4
BUILTIN_LED:
.word 2
.ident "GCC: (GNU) 10.3.0" |
So the compiler output is good, but the final binary is not. Looks like link-time relaxation issue to me. |
It does |
Fixes a hard-to-track bug in GCC 10.x. earlephilhower/newlib-xtensa#19 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102115 GCC 10.3 had an issue with addressing constant integer literals which would result in crazy offsets being used and random crashes in production. Update with an upstream GCC 11 bugfix by @jjsuwa-sys3175 earlephilhower/esp-quick-toolchain#31 https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=dcb2873cd32b263643bfd9d1298b35d6cd028f0a
As mentioned in the earlephilhower/newlib-xtensa#19 (comment) Solves the issue with building on current Debian 11 by regenerating libelf ./configure, otherwise it would incorrectly detect the current compiler command and fail the checking whether the C compiler works... step adding binutils patch ignoring _FORTIFY_SOURCE (and per https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=gdb/gdbsupport/common-defs.h, there are no further changes)
Remembering not easily reproducible issue from back in April:
https://gitter.im/esp8266/Arduino?at=606c9a5c0147fb05c5de1d59
I noticed these flags after the section name string in the PSTR(...) macro:
newlib-xtensa/newlib/libc/sys/xtensa/sys/pgmspace.h
Line 44 in 85c33ba
Per https://sourceware.org/binutils/docs/as/Section.html#index-Section-Stack-3
If such offset had happened on pstr... what does that look like for const char[] arrays used across the app? Is it an actually desired behaviour since the resulting pointer would (?) not be aligned?
Some extra info, sorry for blowing the text size :)
I still have the offending .bin & .elf generated back in april and still with gcc10.2 timestamped 201223, but not the rest of the build directory including the suggested .map file and neither the (possibly broken?) sources that generated it. What I meant it looked like:
However, dumping the code with current toolchain & code:
(with only change being the
namespace { ... }surrounding the function, and looking at objdump it inlined the function into the one it is called from)And, there are some instances where the 'merging' seems to happen on strings like
F("FACTORY.RESET")e.g. settingsInitCommands() here uses it, and terminal function containsF("RESET"):asm code for the April build
_mqttInitCommands()is slightly different as well, but I am not sure what to look at there forSince then, I was not really been able to reproduce this issue (reliably, or even at all, and do not have some kind of small example that could showcase the issue), but I wonder if the 'merge' flag somehow messed with the pointers. Or it is something related to gcc / binutils / different order of .o files when linking / etc., and it was silently resolved due to updates.
The text was updated successfully, but these errors were encountered: