Sysprogs forums › Forums › VisualGDB › Semihosting broken with latest GCC arm-eabi update
- This topic has 5 replies, 2 voices, and was last updated 10 years, 2 months ago by support.
-
AuthorPosts
-
August 17, 2014 at 02:25 #885zarthcodeParticipant
Just the other day, VisualGDB invited me to update to the latest arm-eabi release. I did it, not knowing that it would break semihosting.
Now, when calling initialise_monitor_handles(), a SVC call is performed (it made a SIGTRAP and “just worked”, before) – something I’m not sure that I understand – but am digging into.
Target is a STM32F427 – What changed?
August 21, 2014 at 02:05 #3331supportKeymasterHi,
The previous version did not include the initialise_monitor_handles() method at all. In the current version it is used by the weak implementations of syscalls that can be overridden. Are you calling it initialise_monitor_handles() explicitly, or is it called by some syscall you are invoking?
August 21, 2014 at 04:29 #3332zarthcodeParticipantThat’s the problem. I don’t know. I don’t have the previous version/build. VisualGDB prompted me to update SysGCC, and that’s when the change occurred. It was always GCC 4.8.2, initialise_monitor_handles() was absolutely present, as it worked as expected. I have nothing overridden.
I’ve since switched to launchpad GCC 4.9, it’s initialise_monitor_handles() implementation works exactly as expected, without making a SVC request.
August 24, 2014 at 18:20 #3335supportKeymasterHi,
We’ve released an updated toolchain based on gcc 4.9.1 that resolves some issues and includes a newer newlib. Does your problem still happen with that version?
September 2, 2014 at 10:12 #3333zarthcodeParticipantOnly a slight change. There is no wonky SVC call now, which is no longer a show-stopper. However, printf is still no longer redirected as a result of initialise_monitor_handles(); – All calls to printf appear to (silently) go nowhere apparent. (No issues w/launchpad.)
September 5, 2014 at 04:20 #3334supportKeymasterHi,
This can be related to the implementation of initialize_monitor_handles() in newlib 2.1.0:
void initialise_monitor_handles (void) { int i; #ifdef ARM_RDI_MONITOR int volatile block[3]; block[0] = (int) ":tt"; block[2] = 3; /* length of filename */ block[1] = 0; /* mode "r" */ monitor_stdin = do_AngelSWI (AngelSWI_Reason_Open, (void *) block); block[0] = (int) ":tt"; block[2] = 3; /* length of filename */ block[1] = 4; /* mode "w" */ monitor_stdout = monitor_stderr = do_AngelSWI (AngelSWI_Reason_Open, (void *) block); #else int fh; const char * name; name = ":tt"; asm ("mov r0,%2; mov r1, #0; swi %a1; mov %0, r0" : "=r"(fh) : "i" (SWI_Open),"r"(name) : "r0","r1"); monitor_stdin = fh; name = ":tt"; asm ("mov r0,%2; mov r1, #4; swi %a1; mov %0, r0" : "=r"(fh) : "i" (SWI_Open),"r"(name) : "r0","r1"); monitor_stdout = monitor_stderr = fh; #endif for (i = 0; i < MAX_OPEN_FILES; i ++) openfiles.handle = -1;
openfiles[0].handle = monitor_stdin;
openfiles[0].pos = 0;
openfiles[1].handle = monitor_stdout;
openfiles[1].pos = 0;
}Our toolchain includes a patch that declares this function as __attribute__((weak)), so you can simply get the newlib source code and add this one file to your project, setting ARM_RDI_MONITOR if you need it and modifying anything else you need. You won’t need to rebuild the libc or anything else, the functions from your manually added file will simply replace the default ones.
-
AuthorPosts
- You must be logged in to reply to this topic.