Question: gdb/openocd synchronization/possible race condition #186

TommyMurphyTM1234 · 2017-03-07T10:32:41Z

I hope it's OK to post this here in case anybody has some insight even though admittedly it's almost certainly not a GNU ARM Eclipse plugin issue per se (or at all) and I realise that the FAQ says to only post GNU ARM Eclipse issues.

I see here (http://gnuarmeclipse.github.io/debug/openocd/) under "Quote the entire echo command" a snippet about gdb synchronizing with openocd using the -c 'echo "Started by GNU ARM Eclipse"' command.

Is that the sum total of synchronization between gdb and openocd?
At what point does it happen?
In particular does that synchronization ensure that openocd has initialized fully (e.g. gdb/mi port 3333 and telnet port 4444 servers if applicable etc.) or just that it has started up but may still have initialization to do?

My problem is that in some cases it looks like gdb tries to attach to openocd's gdb/mi port 3333 before openocd has successfully initialized that "server" and I get this:

Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: No connection could be made because the target machine actively refused it.
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: No connection could be made because the target machine actively refused it.
localhost:3333: No connection could be made because the target machine actively refused it.

Specifically I don't get this if I have one of our FlashPro programmers attached (driven by a custom JTAG driver that I have added to openocd). But if I have more than one then the added time taken to enumerate/init etc. these seems to delay openocd sufficiently that it has not yet initialized the gdb/mi port 3333 server by the time that gdb attempts to connect.

However even though it has not happened to date with a single programmer attached it seems to me that there is some latent race condition between gdb and openocd and it was simply luck that avoided problems previously?

Any tips on how to synchronize gdb and openocd in order to avoid this problem?

Thanks and apologies again if this is somewhat off topic from GNU ARM Eclipse proper.

Regards
Tommy`

The text was updated successfully, but these errors were encountered:

ilg-ul · 2017-03-07T12:02:48Z

I hope it's OK to post this here

let's say it is somehow related, but generally questions should be addressed via the project forum.

-c 'echo "Started by GNU ARM Eclipse"' ... the sum total of synchronization

unfortunately it is the only portable synchronisation method I could find.

At what point does it happen?

it happens when OpenOCD decides to print this message. in most cases it is when the board is ready.

does that synchronization ensure that openocd has initialized fully

I have no control over this.

some latent race condition between gdb and openocd

for you to have a reference, the SEGGER J-Link GDB Server, by design, prints a message to confirm it is waiting for connections. this method is a good synchronisation method, and I don't recall such problems with the J-Link plug-in.

OpenOCD does not print such messages, so I had to find a workaround. I personally do not use OpenOCD, and do not recommend it to users.

if you decide to improve OpenOCD, I suggest you contribute a patch to OpenOCD, to print the waiting connection message, and later I can update the plug-ins to use it.

TommyMurphyTM1234 · 2017-03-07T12:07:37Z

Hi Liviu - thanks for the feedback.
That's very useful.
I will investigate further on the openocd side of things.
Just to clarify one thing - I guess that the plugin waits for the "Started by GNU ARM Eclipse" string to appear from openocd?
What does it do once it sees it?
Regards
Tommy

ilg-ul · 2017-03-07T13:53:28Z

What does it do once it sees it?

starts the GDB client.

TommyMurphyTM1234 · 2017-03-07T15:22:00Z

Thanks Liviu - I was confusing gdb starting openocd (piped mode) with socket mode used here where openocd and gdb are started separately (in this case by the plugin). I'll continue looking into this to see if I can get a better solution. At the moment the only one I have is to put a counter delay at the top of gdbinit which is a real hack! :-)

ilg-ul · 2017-03-07T15:28:41Z

looking into this to see if I can get a better solution

yeah, you can switch to J-Link.

TommyMurphyTM1234 · 2017-03-07T15:55:39Z

I hear ya! :-) But unfortunately I have to support OpenOCD in this case. :-(
Thanks a lot for your feedback on this issue.

TommyMurphyTM1234 · 2017-03-07T16:28:32Z

In case it helps anybody else ... one hack (obviously not ideal) which helps is to delay for a period before allowing gdb to proceed. The period to delay will vary and must be chosen by trial and error.
One way to do this in a portable way (since Windows doesn't seem to have a workable equivalent of shell sleep x) is to use ping - e.g. change Debugger > GDB Client Setup > Commands to

shell ping 127.0.0.1 -n 3
set mem inaccessible-by-default off

Where -n specifies the number of seconds (- 1?) to delay and the value needs to be large enough to give openocd time to fully init.
But as I said it's just a hack and the value may differ from one machine/environment/load to another.

TommyMurphyTM1234 · 2017-04-05T19:43:15Z

FWIW I have worked around this for now using my own hack to OpenOCD but this is not an ideal/general fix for everybody. When I get the time I will follow up on this with the OpenOCD project - e.g. start a discussion about the issue and maybe request an enhancement to address it.
For now here is my code change to src/openocd.c (0.10.0 release version) in case it helps anybody else:

/** OpenOCD runtime meat that can become single-thread in future. It parse
 * commandline, reads configuration, sets up the target and starts server loop.
 * Commandline arguments are passed into this function from openocd_main().
 */
static int openocd_thread(int argc, char *argv[], struct command_context *cmd_ctx)
{
	int ret;
	
#ifdef MICROSEMI
	/*
	 * If launched by GNU ARM Eclipse (GAE) then strip the trailing -c and 
	 * 'echo "Started by GNU ARM Eclipse"' command line args. GAE uses this 
	 * string as a simple synchronization mechanism to tell it when it can 
	 * launch GDB which will then connect to OpenOCD's GDB/MI socket interface.
	 * However this echo command is processed by parse_config_file() but
	 * the GDB/MI socket interface is only initialized/configure later by
	 * command_run_line() so there's a race condition whereby GDB may try to 
	 * connect before this interface is ready. So instead the string is echoed
	 * later after we know that the GDB/MI interface is ready and waiting for 
	 * connections.
	 * 
	 * See also: https://sourceforge.net/p/openocd/tickets/147/
	 */
	int f_GAE = 0;
	if (strstr(argv[argc-1], "Started by GNU ARM Eclipse"))
	{
		argc -= 2;
		f_GAE = 1;
	}
#endif /* MICROSEMI */
	
	if (parse_cmdline_args(cmd_ctx, argc, argv) != ERROR_OK)
		return ERROR_FAIL;

	if (server_preinit() != ERROR_OK)
		return ERROR_FAIL;

	ret = parse_config_file(cmd_ctx);
	if (ret == ERROR_COMMAND_CLOSE_CONNECTION)
		return ERROR_OK;
	else if (ret != ERROR_OK)
		return ERROR_FAIL;

	ret = server_init(cmd_ctx);
	if (ERROR_OK != ret)
		return ERROR_FAIL;

	if (init_at_startup) {
		ret = command_run_line(cmd_ctx, "init");
		if (ERROR_OK != ret)
			return ERROR_FAIL;
	}

#ifdef MICROSEMI
	/* See comments above */
	if (f_GAE)
	{
		LOG_USER("Started by GNU ARM Eclipse");
	}
#endif /* MICROSEMI */

	ret = server_loop(cmd_ctx);

	int last_signal = server_quit();
	if (last_signal != ERROR_OK)
		return last_signal;

	if (ret != ERROR_OK)
		return ERROR_FAIL;
	return ERROR_OK;
}

Liviu - I presume that you build OpenOCD as-is and don't apply any of your own patches/mods to it?

ilg-ul · 2017-04-05T19:47:20Z

I presume that you build OpenOCD as-is

that's correct. unless absolutely necessary, I avoid adding patches, since they increase maintenance cost.

unfortunately your patch is not very fortunate, I would search for a more elaborate solution.

TommyMurphyTM1234 · 2017-04-05T20:03:13Z

unfortunately your patch is not very fortunate, I would search for a more elaborate solution.

I agree but I am using that for now as I build OpenOCD with some other mods right now.
As I said I will chase it up with the OpenOCD project when I get a chance - hopefully soon.
Thanks.

ilg-ul · 2017-04-05T20:30:47Z

a more portable trick would be a small delay in ms, default 500, user configurable in the plug-in.

TommyMurphyTM1234 · 2017-04-05T22:23:40Z

I don't think that depending on a timed delay is a good idea.
I think your original idea of having openocd (optionally?) emit some message/banner to announce when it is truly ready for connections is a better idea.
Or having it delay processing command line specified "echo" commands until it is ready for connections so that the existing synchronization with the "Started by GNU ARM Eclipse" output works as is.
As I said I'll flag the issue with the OpenOCD project ASAP to see what they think about this and to see if it has been reported/mentioned before now.

ilg-ul · 2017-04-05T23:50:58Z

having openocd (optionally?) emit some message/banner to announce when it is truly ready for connections is a better idea

if you manage to push some changes to the mainstream openocd to have a stable, 100% reliable way of getting this message, even if when enabled by a switch or command, then I'll consider updating the plug-in, although we need to maintain compatibility with older versions too.

ilg-ul · 2017-04-24T16:42:02Z

since I doubt that it'll be a fix soon, we'll close this for now.

TommyMurphyTM1234 · 2017-09-02T15:56:55Z

Just looking at the OpenOCD code here:

https://sourceforge.net/p/openocd/code/ci/master/tree/src/server/server.c

Does this offer what's needed?
E.g. could GNU MCU Eclipse start OpenOCD, wait for the "accepting 'gdb' connection on tcp/" message before starting GDB?

ilg-ul · 2017-09-02T21:50:30Z

could GNU MCU Eclipse start OpenOCD, wait for the "accepting 'gdb' connection on tcp/" message before starting GDB?

I guess it should work too, but I don't think it'll make a big difference from hunting for my message.

Info : Found flash device 'micron n25q128' (ID 0x0018ba20)
cleared protection for sectors 64 through 255 on flash bank 0
Ready for Remote Connections
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333

TommyMurphyTM1234 · 2017-09-02T22:02:39Z

I'm not so sure.
The de facto message is definitely output too early before OpenOCD is ready to accept gdb Remote Serial Protocol connections in some cases.
E.g. if the JTAG probe initialisation takes "a while".
Using the other banner string may make this more robust.
I'll try to experiment to see...

ilg-ul · 2017-09-02T22:09:58Z

E.g. if the JTAG probe initialisation takes "a while"

I don't know what to say, in my case the full listing is

Info : JTAG tap: riscv.cpu tap/device found: 0x20000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x2)
Info : dtmcontrol_idle=5, dmi_busy_delay=1, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=2, ac_busy_delay=0
Info : dtmcontrol_idle=5, dmi_busy_delay=3, ac_busy_delay=0
Info : Disabling abstract command reads from CSRs.
Info : [0] Found 2 triggers
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=64, program buffer at 0x340, 2 triggers
Info : Listening on port 3333 for gdb connections
Info : Found flash device 'micron n25q128' (ID 0x0018ba20)
cleared protection for sectors 64 through 255 on flash bank 0
Ready for Remote Connections
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Info : JTAG tap: riscv.cpu tap/device found: 0x20000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x2)
invalid command name "arm"
Info : JTAG tap: riscv.cpu tap/device found: 0x20000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x2)
Info : Padding image section 0 with 2 bytes
Info : Padding image section 1 with 2 bytes
Info : JTAG tap: riscv.cpu tap/device found: 0x20000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x2)
===== RISC-V Registers

from this sequence I understand that the JTAG probe is initialised before the socket, so when the gdb client comes, everyting should be ready.

could you check your console when you encounter the problem and compare it with this sequence?

TommyMurphyTM1234 · 2017-09-02T22:24:17Z

What probe are you using? Olimex or something similar? Put a delay/sleep of a few seconds in the relevant OpenOCD JTAG interface driver's init method and see if it still works. I suspect that it will not and you will get something like GDB error E0 or some other anomalous behaviour.

ilg-ul · 2017-09-03T04:11:32Z

a delay/sleep of a few seconds in the relevant OpenOCD JTAG interface driver's init method and see if it still works

you mean to patch the openocd source code?

TommyMurphyTM1234 · 2017-09-03T09:42:41Z

Yes, but just to show that the current -c 'echo "Started by GNU MCU Eclipse"' approach is not robust. Not as a fix. Maybe having the plugin wait for "accepting 'gdb' connection on tcp/xxxx" would work in the general case. I'll see if I can try this out to check if it does work.

ilg-ul · 2017-09-03T09:53:00Z

just to show that the current -c 'echo "Started by GNU MCU Eclipse"' approach is not robust

ah, right, I know it is not robust. and, although I did not measure it, I think that the "accepting..." message is only a few millisecond away from the echo message, which might be only marginally better, but not enough.

could you add some messages in your patched init method, one before the sleep and one after it, to see how they inteleave with the rest of the messages?

I expected the init to complete well before preparing the socket, but if openocd is multithreaded, the sleep itself may give control to the next thread, which might be the one to prepare the socket.

ilg-ul · 2017-09-03T09:57:08Z

perhaps a more robust aproach would be to make the synchronisation mechanism configurable by the user, i.e. in the gdb client section to add a field where to configure wither a string or a delay in milliseconds, and maybe also make the echo string added to openocd optional or configurable.

truhlikfredy · 2017-09-03T21:52:43Z

The sleep in multi threaded openocd might not help.
Yes, that sounds good, more configuration option never hurt.
I'm tempted to make a patch for openocd to accept -pc, the same as -c but running in the post init parts. Same as Tommy's approach but instead modifying original behaviour which might break something else and not get accepted I would hope a new command (instead of modifying the existing one) would be easier to get accepted and merged. Then if we could modify the echo string here to be -pc instead -c we could have something which wouldn't require running modified forks.

TommyMurphyTM1234 · 2017-09-03T22:18:12Z

OpenOCD is single threaded right now and has been for a long time.
I did some timings of the init/string output and will post more tomorrow.
But the key issue is that the current -c 'echo "Started by GNU MCU Eclipse"' banner is output far too early well before the gdb socket is ready.
I'm pretty sure that having the plugin check for "accepting 'gdb' connections on tcp/" is a fail-safe solution ensuring that gdb is not started and does not try to connect until OpenOCD is definitely ready to accept gdb RSP connections. But I'm modifying my copy of the plugin to test this hypothesis. Again I should have more info tomorrow. I don't think that configurability is needed here and I would definitely sure clear of delay based approaches as they are always dodgy.

ilg-ul · 2017-09-04T03:10:19Z

OpenOCD is single threaded right now

are you sure? on macOS, the Activity Monitor reports 3 threads.

I'm modifying my copy of the plugin to test this hypothesis

ok, good plan.

the only drawback I see for this solution is that the plug-in will no longer work with older openocds, since that message was added not so long ago.

ilg-ul · 2017-09-04T03:12:34Z

if we could modify the echo string here to be -pc instead -c we could have something which wouldn't require running modified forks.

yes, we can do it, but it'll have the same disadvantage, it'll not work with older openocds.

TommyMurphyTM1234 · 2017-09-04T07:53:43Z

are you sure? on macOS, the Activity Monitor reports 3 threads.

There is definitely no thread creation code in OpenOCD.
In fact openocd.c has this:

/** OpenOCD runtime meat that can become single-thread in future. It parse
 * commandline, reads configuration, sets up the target and starts server loop.
 * Commandline arguments are passed into this function from openocd_main().
 */
static int openocd_thread(int argc, char *argv[], struct command_context *cmd_ctx)
{
...

Having said that I do see multiple threads in ProcessExplorer on Windows 10 too

19312	0.20	22,984,262	openocd.exe+0x14e0
18864			ntdll.dll!TpReleaseTimer+0xe0
19320			ntdll.dll!TpReleaseTimer+0xe0

but I suspect that threads in addition to the main one created by OpenOCD are created by the OS for its own purposes/reasons - e.g.

https://stackoverflow.com/questions/34822072/why-does-windows-10-start-extra-threads-in-my-program

The code itself is definitely not multithreaded.

TommyMurphyTM1234 · 2017-09-04T08:14:44Z

the only drawback I see for this solution is that the plug-in will no longer work with older openocds, since that message was added not so long ago.

This message:

LOG_INFO("accepting '%s' connection on tcp/%s", service->name, service->port);

exists in all of the following OpenOCD versions:

This message

LOG_INFO("accepting '%s' connection from %s", service->name, service->port);

appears in:

This message:

LOG_INFO("accepting '%s' connection from %i", service->name, c->sin.sin_port);

appears in:

As such checking for "accepting 'gdb' connection" could be an appropriate and backward compatible check or else a check for the three possible formats outlined above?

My only other concern is that the LOG_INFO message appears before the call to new_connection() which may be the code that actually prepares the socket for connections in which case there could still be a race condition albeit a lot less severe than the existing one...

	if (service->type == CONNECTION_TCP) {
		address_size = sizeof(c->sin);

		c->fd = accept(service->fd, (struct sockaddr *)&service->sin, &address_size);
		c->fd_out = c->fd;

		/* This increases performance dramatically for e.g. GDB load which
		 * does not have a sliding window protocol.
		 *
		 * Ignore errors from this fn as it probably just means less performance
		 */
		setsockopt(c->fd,	/* socket affected */
			IPPROTO_TCP,			/* set option at TCP level */
			TCP_NODELAY,			/* name of option */
			(char *)&flag,			/* the cast is historical cruft */
			sizeof(int));			/* length of option value */

		LOG_INFO("accepting '%s' connection on tcp/%s", service->name, service->port);
		retval = service->new_connection(c);
		if (retval != ERROR_OK) {
			close_socket(c->fd);
			LOG_ERROR("attempted '%s' connection rejected", service->name);
			command_done(c->cmd_ctx);
			free(c);
			return retval;
		}
	} else if (service->type == CONNECTION_STDINOUT) {

But in the meantime let me experiment with my modded plugin and OpenOCD 0.10.0+dev at least. :-)

ilg-ul · 2017-09-04T08:19:24Z

As such checking for "accepting 'gdb' connection" could be an appropriate ...

as long as future versions will not change it, yes... :-(

ilg-ul · 2017-09-04T08:20:23Z

if you confirm that hunting for this string solves your problem, I'll update the plug-ins.

TommyMurphyTM1234 · 2017-09-04T08:46:26Z

as long as future versions will not change it, yes... :-(

Hmmm - yes - forward compatibility is always a challenge... :-|

if you confirm that hunting for this string solves your problem, I'll update the plug-ins.

Thanks - I'm looking into it now with my modified GME openocd plugin and will do some experimentation and report back.

BTW - in relation to earlier questions about the relative timing of messages from OpenOCD this might clarify:

Open On-Chip Debugger 0.10.0+dev-00142-g645b474b-dirty (2017-09-03-13:53)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
M2S090
Info : only one transport option; autoselect 'jtag'
adapter speed: 6000 kHz
cortex_m reset_config sysresetreq
trst_only separate trst_push_pull
do_board_reset_init
2017-09-03 14:31:45.629 : Started by GNU ARM Eclipse
Info : 2017-09-03 14:31:45.631 : Listening on port 6666 for tcl connections
Info : 2017-09-03 14:31:45.631 : Listening on port 4444 for telnet connections
Info : 2017-09-03 14:31:45.632 : microsemi_flashpro_initialize start
Info : FlashPro ports available: E200OP5M0
Info : FlashPro port used: E200OP5M0
Info : 2017-09-03 14:31:46.105 : microsemi_flashpro_initialize end
Info : clock speed 6000 kHz
Info : JTAG tap: M2S090.tap tap/device found: 0x2f8071cf (mfg: 0x0e7 (GateField), part: 0xf807, ver: 0x2)
Info : JTAG tap: M2S090.tap disabled
Info : JTAG tap: M2S090.dap enabled
2017-09-03 14:31:46.107 : Info : Cortex-M3 IDCODE = 0x4ba00477
Info : M2S090.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : 2017-09-03 14:31:46.138 : Listening on port 3333 for gdb connections
Info : 2017-09-03 14:31:46.478 : accepting 'gdb' connection on tcp/3333
undefined debug reason 7 - target needs reset
Warn : target not halted

Info : dropped 'gdb' connection

The "Listening on port 3333 for gdb connections" message seems to be a SiFive addition - not sure why.
Note that the "Started by GNU MCU Eclipse" message appears very early on and (in relative terms) well before the "accepting 'gdb' connections on tcp/3333" message.
In some (many?) cases the intervening initialization will happen "quick enough" that by the time the plugin starts gdb and it tries to make a GDB RSP connection to port 3333 everything is ready and it works.
But in some cases (e.g. a JTAG interface driver that takes "longer" to init - such as ours) then this will not be the case and GDB will be launched and will attempt a GDB RSP connection to 3333 before the socket it completely ready.

AntonKrug · 2017-09-04T08:49:17Z

I apologise if this is a stupid question, but would it be viable to probe the port with netstat or lsof to see if the advertised port is really LISTENING?

Not even sure if there is Windows equivalent for it.

ilg-ul · 2017-09-04T10:01:03Z

as long as it is intended to help, there is no such thing as a stupid question.

it might work, but:

it is not very portable across linux/macOS/windows
it would require to parse the ouput
if it is not listening, what to do? loop forever and invoke the program until it is?

it seems complicated and heavy.

truhlikfredy · 2017-09-04T19:55:25Z

Probing it on Java level gets rid of the parsing:

http://www.geekality.net/2013/04/30/java-simple-check-to-see-if-a-server-is-listening-on-a-port/

But I'm not sure that a empty connection and disconnecting will trigger something undesired on the openOCD side.

I was trying to change the wait till the "accepting 'gdb' connection" and I got timeouts, so I wondered if I never received that text.

So I put lot of System.out.println and run eclipse with -consoleLog and for some reason last text I received was the "Started by GNU ARM Eclipse". I'm wondering would it be possible that something interrupts/breaks the error pipe and I'm not receiving any more information from the current pipe?

ilg-ul · 2017-09-04T20:01:28Z

where exactly is written the openocd log, to stdout or stderr? is it the same stream as the one used for -c echo?

TommyMurphyTM1234 · 2017-09-04T20:08:41Z

This is what we were getting in the log (e.g. when Eclipse is launched with -consoleLog):

!ENTRY ilg.gnumcueclipse.debug.gdbjtag.openocd 4 1 2017-09-04 13:45:45.477
!MESSAGE D:\sandbox\eclipse\oxygen\eclipse\/../openocd/bin/openocd.exe -c gdb_port 3333 -c telnet_port 4444 --command set DEVICE M2S090 --file board/microsemi-cortex-m3.cfg -c echo "Started by GNU MCU Eclipse"
Open On-Chip Debugger 0.10.0+dev-00142-g645b474b-dirty (2017-09-03-13:53)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
M2S090
Info : only one transport option; autoselect 'jtag'
adapter speed: 6000 kHz
cortex_m reset_config sysresetreq
trst_only separate trst_push_pull
do_board_reset_init
2017-09-04 13:45:45.564 : Started by GNU MCU Eclipse
Info : 2017-09-04 13:45:45.565 : Listening on port 6666 for tcl connections
Info : 2017-09-04 13:45:45.566 : Listening on port 4444 for telnet connections
Info : 2017-09-04 13:45:45.566 : microsemi_flashpro_initialize start
Info : FlashPro ports available: E200OP5M0
Info : FlashPro port used: E200OP5M0
Info : 2017-09-04 13:45:46.038 : microsemi_flashpro_initialize end
Info : clock speed 6000 kHz
Info : JTAG tap: M2S090.tap tap/device found: 0x2f8071cf (mfg: 0x0e7 (GateField), part: 0xf807, ver: 0x2)
Info : JTAG tap: M2S090.tap disabled
Info : JTAG tap: M2S090.dap enabled
2017-09-04 13:45:46.040 : Info : Cortex-M3 IDCODE = 0x4ba00477
Info : M2S090.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : 2017-09-04 13:45:46.069 : Listening on port 3333 for gdb connections

The "accepting 'gdb' connections on tcp/3333" message does't appear there even though it is appearing in the OpenOCD log in Eclipse and is going to the stderr as it's coloured red in the console and other LOG_INFO messages are obviously visible to the plugin Java code.

It's very very odd....

TommyMurphyTM1234 · 2017-09-04T20:11:06Z

So I put lot of System.out.println and run eclipse with -consoleLog and for some reason last text I received was the "Started by GNU ARM Eclipse". I'm wondering would it be possible that something interrupts/breaks the error pipe and I'm not receiving any more information from the current pipe

Just to clarify - Anton sees "Started by GNU ARM Eclipse" last because he is using a version of OpenOCD with my ugly hack that moves this log message to the end of openocd.c:openocd_thread() instead of it appearing at the start as it normally does in the unhacked openocd.

ilg-ul · 2017-09-04T20:12:51Z

it looks like there was a good reason why I used the -c echo hack...

truhlikfredy · 2017-09-04T20:45:46Z

In our case it should be the stderr

I should probably try the same with the vanilla OpenOCD. I tried to debug the plugin, so I got the Eclipse SDK and I got so far that the SDK Eclipse was able to compile the plugin and then run Eclipse Oxygen with it, but I didn't far enough to be able to debug it.

Something odd/funny is on the OpenOCD which doesn't not work well with the pipes the way they are handled.

h4tr3d · 2017-12-07T17:14:07Z

Hi guys!

By the way, I found that GDB 8.0 + OpenOCD 0.10.0 in most case unusable combination in case, when some RTOS (ThreadX in my case) is used and RTOS support module used by OpenOCD. Often I observe such messages when try to stop process:

Cannot execute this command without a live selected thread.

All work good with GDB 7.7.1 (original) and 7.8 (Linaro branch) and OpenOCD 0.10.0. Currently I have no ideas how it report and just freeze used GDB version.

Issue found on Manjaro Linux using GDB located in repos and Qt Creator, but I reproduce issues using only GDB and OpenOCD from command line. I deal with Cypress FX3 chip in our production board.

ilg-ul · 2017-12-07T19:48:04Z

I reproduce issues using only GDB and OpenOCD from command line

I cannot confirm it, for my RISC-V tests I use the latest GDB and the latest OpenOCD and did not encounter this problem.

h4tr3d · 2017-12-07T21:09:42Z

RISC-V

Cypress FX3 uses ARM926E-JS core and RTOS ThreadX. OpenOCD ability to handle RTOS threads is used too. Seems, that RTOS and it handling on the OpenOCD/GDB side is a major thing.

TommyMurphyTM1234 · 2017-12-07T21:16:12Z

I don't see what these posts have to do with the original topic of this thread?!

ilg-ul · 2017-12-07T23:47:52Z

they probably don't.

@h4tr3d, for support and general questions, please use the project forum.

ilg-ul self-assigned this Mar 7, 2017

ilg-ul added the question label Mar 7, 2017

ilg-ul closed this as completed Apr 24, 2017

TommyMurphyTM1234 mentioned this issue Sep 2, 2017

"Remote failure reply: E0E" when OpenOCD is piped ilg-archived/openocd#18

Closed

TommyMurphyTM1234 mentioned this issue Aug 15, 2023

Is it possible to set the timeout when gdb server (such as openocd) starts? #585

Open

Question: gdb/openocd synchronization/possible race condition #186

Question: gdb/openocd synchronization/possible race condition #186

Comments

TommyMurphyTM1234 commented Mar 7, 2017

ilg-ul commented Mar 7, 2017

TommyMurphyTM1234 commented Mar 7, 2017

ilg-ul commented Mar 7, 2017

TommyMurphyTM1234 commented Mar 7, 2017

ilg-ul commented Mar 7, 2017

TommyMurphyTM1234 commented Mar 7, 2017

TommyMurphyTM1234 commented Mar 7, 2017 • edited Loading

TommyMurphyTM1234 commented Apr 5, 2017

ilg-ul commented Apr 5, 2017 • edited Loading

TommyMurphyTM1234 commented Apr 5, 2017

ilg-ul commented Apr 5, 2017

TommyMurphyTM1234 commented Apr 5, 2017

ilg-ul commented Apr 5, 2017

ilg-ul commented Apr 24, 2017

TommyMurphyTM1234 commented Sep 2, 2017

ilg-ul commented Sep 2, 2017

TommyMurphyTM1234 commented Sep 2, 2017 • edited Loading

ilg-ul commented Sep 2, 2017

TommyMurphyTM1234 commented Sep 2, 2017

ilg-ul commented Sep 3, 2017

TommyMurphyTM1234 commented Sep 3, 2017

ilg-ul commented Sep 3, 2017

ilg-ul commented Sep 3, 2017

truhlikfredy commented Sep 3, 2017

TommyMurphyTM1234 commented Sep 3, 2017

ilg-ul commented Sep 4, 2017

ilg-ul commented Sep 4, 2017

TommyMurphyTM1234 commented Sep 4, 2017

TommyMurphyTM1234 commented Sep 4, 2017 • edited Loading

ilg-ul commented Sep 4, 2017

ilg-ul commented Sep 4, 2017

TommyMurphyTM1234 commented Sep 4, 2017

AntonKrug commented Sep 4, 2017 • edited Loading

ilg-ul commented Sep 4, 2017

truhlikfredy commented Sep 4, 2017

ilg-ul commented Sep 4, 2017

TommyMurphyTM1234 commented Sep 4, 2017

TommyMurphyTM1234 commented Sep 4, 2017

ilg-ul commented Sep 4, 2017

truhlikfredy commented Sep 4, 2017

h4tr3d commented Dec 7, 2017

ilg-ul commented Dec 7, 2017

h4tr3d commented Dec 7, 2017 • edited Loading

TommyMurphyTM1234 commented Dec 7, 2017

ilg-ul commented Dec 7, 2017

TommyMurphyTM1234 commented Mar 7, 2017 •

edited

Loading

ilg-ul commented Apr 5, 2017 •

edited

Loading

TommyMurphyTM1234 commented Sep 2, 2017 •

edited

Loading

TommyMurphyTM1234 commented Sep 4, 2017 •

edited

Loading

AntonKrug commented Sep 4, 2017 •

edited

Loading

h4tr3d commented Dec 7, 2017 •

edited

Loading