[Bug debug/115774] New: GDb does not work in Centos 9 Stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115774 Bug ID: 115774 Summary: GDb does not work in Centos 9 Stream Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ergasies.uni at gmail dot com Target Milestone: --- ./arm-none-eabi-gdb -ver ./arm-none-eabi-gdb: error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory libncursesw.so.5 does not exist in Centos 9 only the version 6 and also libtinfo.s0.5 is not available. So I cannot use the debugger.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #8 from Nikos Tosis --- We found the problem, the bug was in Embedded Ecoder from Mathworks. So the Coder has generated wrong C Code. Thank you all.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #7 from Nikos Tosis --- thank you for the info, I will try tomorrow to see if I made a mistake in simulink or its a bug from simulink.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #5 from Nikos Tosis --- Hi, I opened this bug report in January and until today I didn't see any reaction. do you need more information about the bug or has been fixed?
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #4 from Nikos Tosis --- (In reply to Andrew Pinski from comment #1) > What is the command line you are using to compile the sources? > > Does -fno-strict-aliasing help? > Does it work at -O0? I use -mcpu=cortex-m4 -std=gnu11 -g -DDEBUG -DUSE_HAL_DRIVER -DSTM32F446xx -Og -ffunction-sections -fdata-sections -Wall -Wextra -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -save-temps -ffile-prefix-map=/home/runner/work/Nyx_Simulink/Nyx_Simulink/Code=. (In reply to Andrew Pinski from comment #1) > What is the command line you are using to compile the sources? > > Does -fno-strict-aliasing help? > Does it work at -O0? I think your suggestion is not working, the assembly code is different but still a wrong address.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #3 from Nikos Tosis --- (In reply to Christophe Lyon from comment #2) > I may be reading the code incorrectly, but ISTM that rtu_AngleMecIn is the > 3rd parameter of the function, so you pass &UnitDelay_DSTATE, > while you pass &Sig_MechanicalAngle as 5th parameter. > > So it's normal that (*rtu_AngleMecIn) and (Sig_MechanicalAngle) have > different values. This is the declaration void ConvertPWMtoAngle(const int16_T *rtu_qSollin, const boolean_T *rtu_detectStartUpin, const real32_T *rtu_AngleMecIn, real32_T *rty_AngleElec, real32_T *rty_AnlgleMec) and this is the call ConvertPWMtoAngle(&qSoll, &rtb_UnitDelay_n, &UnitDelay_DSTATE, &rtb_AngleCalculation_o1, &Sig_MechanicalAngle); qSoll = 1 rtb_UnitDelay_n = 2 UnitDelay_DSTATE = 3 rtb_AngleCalculation_o1 = 4 Sig_MechanicalAngle = 5 The code is auto genenated from Matlab but I see that everything is ok.
[Bug c/108575] New: Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 Bug ID: 108575 Summary: Bug in gcc arm non eabi Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ergasies.uni at gmail dot com Target Milestone: --- Created attachment 54363 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54363&action=edit i files and some screenshots. Hi, I use the gcc-arm-none-eabi-10.3-2021.10 version. I working on Fedora 29. My C Code is auto-generated from Simulink. The following code is the function call. /* ModelReference: '/AngleCalculation' incorporates: * DataStoreRead: '/Data Store Read' * Inport: '/Input' * Inport: '/Input1' * UnitDelay: '/Unit Delay' */ ConvertPWMtoAngle(&qSoll, &rtb_UnitDelay_n, &UnitDelay_DSTATE, &rtb_AngleCalculation_o1, &Sig_MechanicalAngle); and this is the declaration of the function. /* Output and update for referenced model: 'ConvertPWMtoAngle' */ void ConvertPWMtoAngle(const int16_T *rtu_qSollin, const boolean_T *rtu_detectStartUpin, const real32_T *rtu_AngleMecIn, real32_T *rty_AngleElec, real32_T *rty_AnlgleMec) The global variable Sig_MechanicalAngle according to map file has the address 0x20004c94. In the function ConvertPWMtoAngle the implementation looks like this: continuesAngle = (degresProCounter * (real32_T)rtb_Switch_d) + (*rtu_AngleMecIn); and the assembly looks like this: 0800837C 4B14LDRR3, =EncoderCounter ; [PC, #80] [0x080083D0] =0x2224 0800837E 881BLDRH R3, [R3] 08008380 4A0ELDRR2, =ConvertPWMtoAngle_DW ; [PC, #56] [0x080083BC] =0x20004CF0 08008382 8912LDRH R2, [R2, #8] 08008384 1A9BSUBS R3, R3, R2 08008386 B21BSXTH R3, R3 08008388 EE07 3A90 VMOV S15, R3 0800838C EEF8 7AE7 VCVT.F32.S32 S15, S15 08008390 4B15LDRR3, =degresProCounter ; [PC, #84] [0x080083E8] =0x080102E0 08008392 ED93 7A00 VLDR S14, [R3] 08008396 EE67 7A87 VMUL.F32 S15, S15, S14 0800839A ED96 7A00 VLDR S14, [R6] 0800839E EE77 7A87 VADD.F32 S15, S15, S14 080083A2 4B12LDRR3, =continuesAngle ; [PC, #72] [0x080083EC] =0x20004D0C 080083A4 EDC3 7A00 VSTR S15, [R3] 080083A8 E7CCB 0x08008344; +0x11C in line 0800839A ED96 7A00 VLDR S14, [R6] the controller loads from the memory address in R6 the value in S14. But when I check the register R6 Value the has the address value 2001 1548 and this is not the correct address, this is not the address from variable Sig_MechanicalAngle. And always the Register S14 has the value 0. The address 2001 1548 exist not in my map file as variable. This is the map entry in this address area: 0x20011394testTask500msHandle 0x20011398ComputationINTBuffer 0x20011598testTask500msBuffer COMMON 0x20011d98 0x2c ./Core/Src/main.o 0x20011d98ClockInfos 0x20011dacadcBuffer I changed my implementation to continuesAngle = (degresProCounter * (real32_T)rtb_Switch_d) + (Sig_MechanicalAngle); and the software is working properly. I checked also my stack and i did not find a stack overflow. That means when I use a pointer I have a big trouble and when I use the object of the variable then everything is ok. Could you help me and see if is it a bug?
