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

gdb server: Add back support to disable the gdb server via the gdb_port config #3

Merged
merged 1 commit into from
Jan 31, 2017

Conversation

sandeepmistry
Copy link
Contributor

As per the documentation, used "disabled" as the value to disable, as this is the same value to disable the telnet and tcl server.

Related to arduino/Arduino#4330.

Also, submitted upstream (but no activity): http://openocd.zylin.com/#/c/3175/

…rt config

As per the documentation, used "disabled" as the value to disable, as this
is the same value to disable the telnet and tcl server.
sandeepmistry pushed a commit to sandeepmistry/OpenOCD that referenced this pull request Nov 4, 2016
In the case that the STKALIGN bit is set on Cortex M processors, on
entry to an exception - the processor can store an additional 4 bytes
of padding before regular stacking to achieve 8-byte alignment on
exception entry.  In the case that this padding is present, the
processor will set bit (1 << 9) in the stacked xPSR register.  Use the
new calculate_process_stack callback to take into account the xPSR
register and use it on the standard Cortex_M3 stacking.

Note: Change #2301 had some misinformation regarding the padding.  On
Cortex-M the padding is stored BEFORE stacking so xPSR is always
available at a fixed offset.

Tested on a Cortex-M0+ (Atmel SAMR21) board which has STKALIGN fixed
to a '1' such that this alignment always occurs on non-aligned stacks.

Behavior of xPSR verified via the (bad-sorry) assembly program below by
setting a breakpoint on the SVC_Handler symbol.  The first time
SVC_Handler is triggered the stack was 0x20000ff8, the second time
SVC_Handler is triggered the stack was 0x20000ffc.  Note that in both
cases the interrupt handler gets 0x20000fd8 for a stack pointer.

GDB exerpt:

Breakpoint 1, 0x000040b6 in Reset_Handler ()
(gdb) hbreak SVC_Handler
Hardware assisted breakpoint 2 at 0x40f8
(gdb) cont
Continuing.

Breakpoint 2, 0x000040f8 in SVC_Handler ()
(gdb) print $msp
$3 = (void *) 0x20000fd8
(gdb) x/9w $msp
0x20000fd8:     0x1     0x2     0x3     0x4
0x20000fe8:     0x88160082      0xa53   0x40ce  0x21000000
0x20000ff8:     0x0
(gdb) cont
Continuing.

Breakpoint 2, 0x000040f8 in SVC_Handler ()
(gdb) print $msp
$4 = (void *) 0x20000fd8
(gdb) x/9w $msp
0x20000fd8:     0x1     0x2     0x3     0x4
0x20000fe8:     0x88160082      0xa53   0x40e8  0x21000200
0x20000ff8:     0x0

Assembly program:

	.cpu cortex-m0plus
	.fpu softvfp
	.thumb
	.syntax unified

.section .vectors
@ pvStack:
	.word	0x20001000
@ pfnReset_Handler:
	.word	Reset_Handler + 1
@ pfnNMI_Handler:
	.word	0
@ pfnHardFault_Handler:
	.word	0
@ pfnReservedM12:
	.word	0
@ pfnReservedM11:
	.word	0
@ pfnReservedM10:
	.word	0
@ pfnReservedM9:
	.word	0
@ pfnReservedM8:
	.word	0
@ pfnReservedM7:
	.word	0
@ pfnReservedM6:
	.word	0
@ pfnSVC_Handler:
	.word	SVC_Handler + 1

.section .text
.global Reset_Handler
Reset_Handler:
    cpsie i
    ldr r0, .stack_start
    ldr r2, .stack_last
    eors r1, r1
.loop_clear:
    str r1, [r0]
    adds r0, r0, arduino#4
    cmp r0, r2
    bne .loop_clear
    subs r2, r2, arduino#4
    mov sp, r2
    movs r0, arduino#1
    movs r1, arduino#2
    movs r2, arduino#3
    movs r3, arduino#4
    svc #0
    ldr r0, .stack_start
    ldr r2, .stack_last
    eors r1, r1
.loop_clear2:
    str r1, [r0]
    adds r0, r0, arduino#4
    cmp r0, r2
    bne .loop_clear2
    mov sp, r2
    movs r0, arduino#1
    movs r1, arduino#2
    movs r2, arduino#3
    movs r3, arduino#4
    svc #0
.loop:
	b .loop
.align 4
.stack_start:
    .word 0x20000f00
.stack_last:
    .word 0x20000ffc

@ first call - 0x2000fff8 -- should already be aligned
@ second call - 0x2000fffc -- should hit the alignment code
.global SVC_Handler
SVC_Handler:
    bx lr

Change-Id: Id0940e6bbd6a59adee1378c0e86fe86830f0c8fc
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Cc: Paul Fertser <fercerpav@gmail.com>
Cc: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Cc: Evan Hunter <evanhunter920@gmail.com>
Cc: Jon Burgess <jburgess777@gmail.com>
Reviewed-on: http://openocd.zylin.com/3003
Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
@facchinm facchinm merged commit 261fae5 into arduino:arduino Jan 31, 2017
facchinm pushed a commit to facchinm/OpenOCD that referenced this pull request Jun 8, 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
    arduino#1 0x55978a61ff9e in stlink_usb_read_reg src/jtag/drivers/stlink_usb.c:1539
    arduino#2 0x55978a8cfd45 in adapter_load_core_reg_u32 src/target/hla_target.c:67
    arduino#3 0x55978a9f48e3 in armv7m_read_core_reg src/target/armv7m.c:236
    arduino#4 0x55978a8d24fc in adapter_load_context src/target/hla_target.c:372
    arduino#5 0x55978a8d261b in adapter_debug_entry src/target/hla_target.c:396
    arduino#6 0x55978a8d3123 in adapter_poll src/target/hla_target.c:457
    arduino#7 0x55978a528357 in target_poll src/target/target.c:535
    arduino#8 0x55978a539fd4 in target_wait_state src/target/target.c:2914
    arduino#9 0x55978a556e20 in jim_target_wait_state src/target/target.c:5256
    arduino#10 0x55978a5cca62 in command_unknown src/helper/command.c:1030
    arduino#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>
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 this pull request may close these issues.

2 participants