{"action":"created","issue":{"url":"https://api.github.com/repos/mbeddr/mbeddr.core/issues/1164","labels_url":"https://api.github.com/repos/mbeddr/mbeddr.core/issues/1164/labels{/name}","comments_url":"https://api.github.com/repos/mbeddr/mbeddr.core/issues/1164/comments","events_url":"https://api.github.com/repos/mbeddr/mbeddr.core/issues/1164/events","html_url":"https://github.com/mbeddr/mbeddr.core/issues/1164","id":58187710,"number":1164,"title":"Debugging inside OS callbacks","user":{"login":"wuryel","id":3432345,"avatar_url":"https://avatars.githubusercontent.com/u/3432345?v=3","gravatar_id":"","url":"https://api.github.com/users/wuryel","html_url":"https://github.com/wuryel","followers_url":"https://api.github.com/users/wuryel/followers","following_url":"https://api.github.com/users/wuryel/following{/other_user}","gists_url":"https://api.github.com/users/wuryel/gists{/gist_id}","starred_url":"https://api.github.com/users/wuryel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wuryel/subscriptions","organizations_url":"https://api.github.com/users/wuryel/orgs","repos_url":"https://api.github.com/users/wuryel/repos","events_url":"https://api.github.com/users/wuryel/events{/privacy}","received_events_url":"https://api.github.com/users/wuryel/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-02-19T10:00:44Z","updated_at":"2015-02-25T12:48:56Z","closed_at":null,"body":"I would like to extend the mbeddr debugger to my extension of mbeddr. The \"new\" DSL shall provide access the the tasking facilities of the OS below. Right now I focus on a Linux host and use the pthread_create(...) directive to create and start a concurrent thread. This primitive expects a pointer\r\nto a code snippet which is executed as a separate thread. Essentially the OS calls this code snippet whenever the thread is being scheduled.\r\n\r\nNow I can place a breakpoint on DSL level into this code snippet and the debugger holds correctly but the stack frame construction fails when lifting the debugger information to DSL level.\r\n\r\nThe call stack information provided by the debugger goes below the DSL/Application level (so internals of the pthread_create(...) primitive are reported). This information (obviously) can't be mapped to the respective node on MPS tree level and the whole thing crashes.\r\n\r\nI did some investigation in the mbeddr debugger implementation and identified a few checks that I removed in order to be able to successfully debug.\r\n\r\nIn the current implementation exceptions are thrown if it is not possible to map debugger information to MPS nodes. After my tiny changes these exceptions are not thrown anymore, but there is just no mapping performed. Maybe this is not the intended or best way to solve the issue (by far I haven't understood all the implementation), but at least it allows debugging code inside an OS callback routine.\r\n\r\nThis is what I did:\r\n\r\n1) Source files refered to by the debug info are allowed to have the extension \".S\" and \".s\" besides just \".c\". So this had to be added in these three operations\r\n\r\n1a)  -- com.mbeddr.core.debug.(util models).debugger.(mapper).(state).(frame-mapper).(impl).MFrameMapperImpl.getFileName()\r\n1b)  -- com.mbeddr.core.debug.(util models).debugger.(mapper).(state).(frame-mapper).(impl).GeneratedCFilePath.GeneratedCFilePath()\r\n1c)  -- com.mbeddr.core.debug.(util models).debugger.(mapper).(state).(frame-mapper).(impl).GeneratedCFilePath.getUnitName\r\n\r\n2) If the stack frame tracing doesn't work, this doesn't necessarily mean that we have an issue. Maybe a warning is sufficient here, so the user is aware of the fact.\r\nTo solve this I just removed the statements throwing the respective exceptions:\r\n\r\n2a)  -- com.mbeddr.core.debug.(util models).debugger.(mapper).(state).(frame-mapper).(impl).MFrameMapperImpl.getClosestNodeViaTracesNew()\r\n    - within the else block the statement \"throw new MMissingTracesException();\" is removed;\r\n    - instead \"return null;\" is inserted\r\n\r\n2b) -- com.mbeddr.core.debug.(util models).debugger.(mapper).(state).(frame-mapper).(impl).MFrameMapperImpl.constructFrameMappings()\r\n    - within the outer else block the statement \"throw new MMissingTracesException(\"Could not establish the trace for C routine: \" + mappingStackFrame.getStackFrame().routineName());\" is removed"},"comment":{"url":"https://api.github.com/repos/mbeddr/mbeddr.core/issues/comments/75954196","html_url":"https://github.com/mbeddr/mbeddr.core/issues/1164#issuecomment-75954196","issue_url":"https://api.github.com/repos/mbeddr/mbeddr.core/issues/1164","id":75954196,"user":{"login":"wuryel","id":3432345,"avatar_url":"https://avatars.githubusercontent.com/u/3432345?v=3","gravatar_id":"","url":"https://api.github.com/users/wuryel","html_url":"https://github.com/wuryel","followers_url":"https://api.github.com/users/wuryel/followers","following_url":"https://api.github.com/users/wuryel/following{/other_user}","gists_url":"https://api.github.com/users/wuryel/gists{/gist_id}","starred_url":"https://api.github.com/users/wuryel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wuryel/subscriptions","organizations_url":"https://api.github.com/users/wuryel/orgs","repos_url":"https://api.github.com/users/wuryel/repos","events_url":"https://api.github.com/users/wuryel/events{/privacy}","received_events_url":"https://api.github.com/users/wuryel/received_events","type":"User","site_admin":false},"created_at":"2015-02-25T12:48:56Z","updated_at":"2015-02-25T12:48:56Z","body":"Ok, I sent the pull request - hope I didn't mess it up ;-)\r\n\r\n1) Having multi-threaded applications supported by the debugger would be great, of course. Although with many embedded platforms this is not supported by the hardware/gbd. My intention was to be able to debug at all, regardless of the thread.\r\n\r\n2) I like your idea with the flag in the run configuration.\r\n"}}