When using openocd with a MCU with multiple targets, openocd will listen on multiple ports (one per core) for gdb to connect to.
So for example a LPC4370 with the following openocd config:

swj_newdap lpc4370 m4 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x4ba00477
jtag newtap lpc4370 m0sub -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x0ba01477
jtag newtap lpc4370 m0app -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x0ba01477

target create lpc4370.m4 cortex_m -chain-position lpc4370.m4
target create lpc4370.m0sub cortex_m -chain-position lpc4370.m0sub
target create lpc4370.m0app cortex_m -chain-position lpc4370.m0app

lpc4370.m4 configure -work-area-phys 0x10000000 \
                        -work-area-size 0x20000 -work-area-backup 0
lpc4370.m0sub configure -work-area-phys 0x18000000 \
                         -work-area-size 0x4800 -work-area-backup 0
lpc4370.m0app configure -work-area-phys 0x10080000 \
                         -work-area-size 0x92000 -work-area-backup 0
targets lpc4370.m4

The main m4 core will be available as usual by connecting with gdb> target remote localhost:3333 , and m0app will be debuggable by connecting with gdb> target remote localhost:3335 .

The m0app and m0sub cores are a bit special in that they must be started from the m4 core, and any attempts to start them from gdb will result in warnings and the core will still be in reset state, until started by the m4 core.