Extension not loading when debugging non-x86/x64 targets

[d11mphillips]

This might just be my lack of knowledge of how each target platform is supported using extensions more than anything else, so I'm trying to get a basis understanding.

My extension loads and runs fine when I start debugging a Windows x64 executable, but I'd like it to support other proprietary targets. Currently the extension does not load for these, and its DLL is not listed as a loaded module when debugging the extension itself. Is there a way I can confgure the extension to load for additional target types, or would I need some insider understanding of how their own Visual Studio debugger extensions work?

The platforms in question are covered under NDA so please excuse the vageness.

Cheers!

[gregg-miskelly]

A few questions:

1. You are building a native debugger?
2. What type(s) of component are you developing? Ex: Base DM, symbol provider, etc
3. Does this target still use Windows PE files and PDBs?

Depending on what your scenario is, you might be better off developing either a Debug Adapter (Visual Studio hosting information is here) or a Debug Engine. Both of those technologies allow you to have complete control over the backend of the debugger, but it also means you will be responsible for entirely implementing the backend of the debugger. So, it really depends on if there are significant parts of Concord that you will be able to reuse. Typically, a brand-new processor architecture would probably need changes up and down a native debugging stack, so you would be better off NOT being a Concord component.

[d11mphillips]

1. You are building a native debugger?

No it's for a scripting language run within the executable, I'm not looking to reimplement native debugging itself. The platforms already have pretty comprehensive debug engines.

2. What type(s) of component are you developing? Ex: Base DM, symbol provider, etc

For this script debugger to operator I only need to be able to read and write to the native process' memory, set and receive breakpoints, so:

Remote side

• IDkmModuleInstanceLoadNotification
• IDkmRuntimeBreakpointReceived
• IDkmRuntimeMonitorBreakpointHandler

Local side:

• IDkmSymbolDocumentCollectionQuery
• IDkmSymbolDocumentSpanQuery
• IDkmSymbolQuery
• IDkmLanguageExpressionEvaluator

3. Does this target still use Windows PE files and PDBs?

No it's an ELF-style, but again I'm not looking to reimplement any of the native stuff, that already works. The script langauge has its own custom symbol format (which all works fine under Win x64).

Is the native Debug Engine responsible for loading extensions, or have I missed something in my own configuration? I'm unfamiliar with how extensions load and how they are filtered per platform/target/architecture.

Cheers!