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

building issue #1

Open
bigoplus opened this issue Sep 13, 2017 · 0 comments
Open

building issue #1

bigoplus opened this issue Sep 13, 2017 · 0 comments

Comments

@bigoplus
Copy link

Hi, when I build master branch, 1e2be7e, some error happend
Undefined symbols for architecture x86_64:
"_msp432p4_flash", referenced from:
_flash_drivers in libopenocd.a(drivers.o)
"_multicore_rtos", referenced from:
_rtos_create in libopenocd.a(src_rtos_librtos_la-rtos.o)
_rtos_qsymbol in libopenocd.a(src_rtos_librtos_la-rtos.o)
_rtos_try_next in libopenocd.a(src_rtos_librtos_la-rtos.o)
_rtos_types in libopenocd.a(src_rtos_librtos_la-rtos.o)
"_plugin_flash", referenced from:
_flash_drivers in libopenocd.a(drivers.o)
"_stm32h7x_flash", referenced from:
_flash_drivers in libopenocd.a(drivers.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/openocd] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

sysprogs pushed a commit that referenced this issue May 24, 2018
…oo far

Without this, we have some types promoted to `int` when they need to be
`unsigned int`.

Here's some ubsan output hitting this:

Unfortunately, what happens is that things get promoted to `int`, but
need to be `unsigned int`. Here's the ubsan output:

src/helper/types.h:126:65: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
    #0 0x55978a612060 in le_to_h_u32 src/helper/types.h:126
    #1 0x55978a61ff9e in stlink_usb_read_reg src/jtag/drivers/stlink_usb.c:1539
    #2 0x55978a8cfd45 in adapter_load_core_reg_u32 src/target/hla_target.c:67
    #3 0x55978a9f48e3 in armv7m_read_core_reg src/target/armv7m.c:236
    #4 0x55978a8d24fc in adapter_load_context src/target/hla_target.c:372
    #5 0x55978a8d261b in adapter_debug_entry src/target/hla_target.c:396
    #6 0x55978a8d3123 in adapter_poll src/target/hla_target.c:457
    #7 0x55978a528357 in target_poll src/target/target.c:535
    #8 0x55978a539fd4 in target_wait_state src/target/target.c:2914
    #9 0x55978a556e20 in jim_target_wait_state src/target/target.c:5256
    #10 0x55978a5cca62 in command_unknown src/helper/command.c:1030
    #11 0x55978aaed894 in JimInvokeCommand /home/cody/d/openocd-code/jimtcl/jim.c:10364

Change-Id: I24f6abfd26b6980100657397d69c84f2b80a005a
Signed-off-by: Cody P Schafer <openocd@codyps.com>
Reviewed-on: http://openocd.zylin.com/4455
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
sysprogs pushed a commit that referenced this issue Feb 11, 2019
…_check

Slow version of blank check procedure reads target memory sector-by-sector
using 1 KB chunks. Due to bug in chunk size calculation algorithm the actual
size of the chunk is always 1 KB even if sector size is smaller.
This causes out-of-boundary read of the last sector.

Steps to reproduce:
1) Use target with small sectors (e.g. psoc6 with 512-byte sectors)
2) set WORKAREASIZE_CM0 0
3) flash erase_check 1

Running slow fallback erase check - add working memory
Info : SWD DPIDR 0x6ba02477
Error: Failed to read memory at 0x14008000
unknown error when checking erase state of flash bank #1 at 0x14000000
	Bank is erased

Change-Id: I03d0d5fb3a1950ae6aac425f5e24c7fd94b38325
Signed-off-by: Bohdan Tymkiv <bhdt@cypress.com>
Reviewed-on: http://openocd.zylin.com/4785
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
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

No branches or pull requests

1 participant