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.

Sign up for GitHub

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

Jump to bottom

openocd on raspberry pi #4

Closed
yschaeff opened this issue Jan 11, 2017 · 1 comment
Closed

openocd on raspberry pi #4

yschaeff opened this issue Jan 11, 2017 · 1 comment

Comments

@yschaeff
Copy link

I'm trying to compile openocd on a raspberry pi and I'm hitting this issue:

rtos_freertos_stackings.c: In function 'rtos_freertos_esp108_stack_read_voluntary':
rtos_freertos_stackings.c:375:22: error: cast increases required alignment of target type [-Werror=cast-align]
uint32_t *stackregs=(uint32_t *)stack_data; //alias so we can read/write entire words. Little-endian hosts only!

Which make sense since the code mentions it doesn't work on big endian machines. I'd like to use a raspberry pi as JTAG adapter but I can't get it to compile.
@igrr
Copy link
Member

igrr commented Jan 18, 2017

One line above there's a workaround which is currently enabled only in clang:
https://github.com/espressif/openocd-esp32/blob/master/src/rtos/rtos_freertos_stackings.c#L371-L374

Maybe you can change conditional above that so the warning is suppressed on your system as well.

@Cooler1989 Cooler1989 mentioned this issue Jan 23, 2018
Closed
@Sermus Sermus mentioned this issue Mar 4, 2018
Closed
igrr pushed a commit that referenced this issue Feb 12, 2019
@gerekon
helper/types: cast to uint32_t,uint16_t to avoid UB by shifting int t…
9df1c9a 
…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>
espressif-bot pushed a commit that referenced this issue Dec 30, 2019
@tom-van
helper/types: cast to uint32_t,uint16_t to avoid UB by shifting int t…
d4ef54c 
…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>
espressif-bot pushed a commit that referenced this issue Nov 4, 2020
@mwachs5
Merge pull request #4 from sifive/mwachs5-patch-sckdiv
db2ec67 
Don't write SCKDIV when flashing
gerekon pushed a commit that referenced this issue Jun 29, 2022
@erhankur
rtos/esp32_stacking: AddressSanitizer: heap-buffer-overflow issue
90907b8 
    #0 0x10c41485f in __asan_memcpy+0x1af (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x4285f)
    #1 0x10ab3dcfd in buf_cpy binarybuffer.c:60
    #2 0x10ab2774b in rtos_generic_stack_read rtos.c:664
    #3 0x10aac3ed9 in freertos_get_thread_registers_from_stack FreeRTOS.c:1148
    #4 0x10aab2ea2 in freertos_get_thread_reg_list FreeRTOS.c:1238
    #5 0x10aab32b1 in freertos_get_thread_reg FreeRTOS.c:1269
    #6 0x10aabe903 in freertos_get_tasks_details FreeRTOS.c:797
    #7 0x10aab270f in freertos_update_threads FreeRTOS.c:1060
    #8 0x10ab1d66e in rtos_thread_packet rtos.c:395
    #9 0x10ab1bad2 in gdb_thread_packet rtos.c:191
    #10 0x10aa4643d in gdb_input_inner gdb_server.c:3547
    #11 0x10aa3d534 in gdb_input gdb_server.c:3743
    #12 0x10aa8e565 in server_loop server.c:566
    #13 0x1099f6e66 in openocd_thread openocd.c:380
    #14 0x1099f685e in openocd_main openocd.c:419
    #15 0x1099f52b1 in main main.c:40
    #16 0x7fff6bf78cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@igrr @yschaeff