Distribuire, eseguire ed eseguire il debug del progetto MSBuild Linux

Dopo aver creato un progetto C++ linux basato su MSBuild in Visual Studio e aver eseguito la connessione al progetto usando il Gestione connessioni Linux, è possibile eseguire ed eseguire il debug del progetto. Si compila, si esegue e si sottopone a debug il codice nella destinazione remota.

Esistono diversi modi di interagire con il progetto Linux ed eseguirne il debug.

• Eseguire il debug usando le tradizionali funzionalità di Visual Studio, ad esempio punti di interruzione, finestre Espressioni di controllo e passaggio del puntatore su una variabile. Usando questi metodi, è possibile eseguire il debug nel modo consueto, come per gli altri tipi di progetto.

• Visualizzare l'output dal computer di destinazione nella finestra della console di Linux. È anche possibile usare la console per inviare l'input al computer di destinazione.

Eseguire il debug del progetto Linux

1. Selezionare la modalità di debug nella pagina delle proprietà Debug.

   Per il debug delle applicazioni in esecuzione su Linux viene usato GDB. Quando si esegue il debug in un sistema remoto (non WSL), è possibile eseguire GDB in due modi diversi selezionabili dall'opzione Modalità di debug nella pagina delle proprietà Debug del progetto:

   

   Per il debug delle applicazioni in esecuzione su Linux viene usato GDB. È possibile eseguire GDB in due modalità diverse, selezionabili dall'opzione Modalità di debug nella pagina delle proprietà di debug del progetto:

   

   • In modalità gdbserver, GDB viene eseguito in locale e si connette a gdbserver nel sistema remoto.

   • In modalità gdb, GDB viene guidato nel sistema remoto dal debugger di Visual Studio. Questa è un'opzione migliore se la versione locale di GDB non è compatibile con la versione installata nel computer di destinazione. Questa è l'unica modalità supportata dalla finestra della console Linux.

   Nota

   Se non è possibile raggiungere i punti di interruzione in modalità di debug gdbserver, provare la modalità gdb. gdb deve prima essere installato nella destinazione remota.

2. Selezionare la destinazione remota usando la barra degli strumenti standard Debug in Visual Studio.

   Quando la destinazione remota è disponibile, verrà visualizzata in base al nome o all'indirizzo IP.

   

   Se non si è ancora connessi alla destinazione remota, verrà visualizzata un'istruzione per usare Linux Gestione connessioni per connettersi alla destinazione remota.

   

3. Impostare un punto di interruzione facendo clic nella barra di navigazione a sinistra di un codice che verrà sicuramente eseguito.

   Un punto rosso viene visualizzato nella riga di codice in cui è stato impostato il punto di interruzione.

4. Premere F5 (o Debug > Avvia debug) per avviare il debug.

   Quando si avvia il debug, l'applicazione viene compilata nella destinazione remota prima che venga avviata. Gli eventuali errori di compilazione verranno visualizzati nella finestra Elenco errori.

   Se non sono presenti errori, l'app verrà avviata e il debugger verrà sospeso in corrispondenza del punto di interruzione.

   

   È ora possibile interagire con l'applicazione nello stato corrente, visualizzare le variabili ed eseguire il codice un'istruzione alla volta premendo i tasti di comando, ad esempio F10 o F11.

5. Se si vuole usare la console Linux per interagire con l'app, selezionare Debug > console Linux.

   

   Questa console visualizzerà qualsiasi output della console dal computer di destinazione e lo invierà al computer di destinazione.

   

Configurare altre opzioni di debug (progetti MSBuild)

• Gli argomenti della riga di comando possono essere passati all'eseguibile usando l'elemento Argomenti del programma nella pagina delle proprietà di debug del progetto.

• È possibile esportare la DISPLAY variabile di ambiente usando il comando di preavvio nelle pagine delle proprietà debug del progetto. Ad esempio: export DISPLAY=:0.0

  

• Le opzioni specifiche del debugger possono essere passate a GDB usando la voce Comandi aggiuntivi del debugger. Può essere utile ad esempio ignorare i segnali SIGILL (istruzione non valida). Per ottenere questo risultato, è possibile usare il comando handle, aggiungendo quanto segue alla voce Comandi aggiuntivi del debugger come illustrato in precedenza:

  handle SIGILL nostop noprint

• È possibile specificare il percorso del GDB usato da Visual Studio usando l'elemento Percorso GDB nella pagina delle proprietà Debug del progetto. Questa proprietà è disponibile in Visual Studio 2019 versione 16.9 e successive.

Debug con Associa a processo

La pagina delle proprietà Debug per i progetti di Visual Studio e le impostazioni Launch.vs.json per progetti CMake offrono impostazioni che consentono di creare un'associazione a un processo in esecuzione. Se è necessario un maggiore controllo oltre a quanto specificato in tali impostazioni, è possibile inserire un file denominato Microsoft.MIEngine.Options.xml nella radice della soluzione o dell'area di lavoro. Di seguito è riportato un semplice esempio:

<?xml version="1.0" encoding="utf-8"?>
<SupplementalLaunchOptions>
    <AttachOptions>
      <AttachOptionsForConnection AdditionalSOLibSearchPath="/home/user/solibs">
        <ServerOptions MIDebuggerPath="C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\Common7\IDE\VC\Linux\bin\gdb\7.9\x86_64-linux-gnu-gdb.exe"
ExePath="C:\temp\ConsoleApplication17\ConsoleApplication17\bin\x64\Debug\ConsoleApplication17.out"/>
        <SetupCommands>
          <Command IgnoreFailures="true">-enable-pretty-printing</Command>
        </SetupCommands>
      </AttachOptionsForConnection>
    </AttachOptions>
</SupplementalLaunchOptions>

L'elemento AttachOptionsForConnection include la maggior parte degli attributi che potrebbero essere necessari. Nell'esempio precedente viene illustrato come specificare un percorso in cui cercare altre librerie .so. L'elemento figlio ServerOptions consente di creare un'associazione al processo remoto usando invece la modalità gdbserver. A tale scopo, è necessario specificare un client gdb locale (quello fornito in Visual Studio 2017 è illustrato sopra) e una copia locale del file binario con simboli. L'elemento SetupCommands consente di passare i comandi direttamente a gdb. È possibile trovare tutte le opzioni disponibili nello schema LaunchOptions.xsd su GitHub.

<ItemGroup>
   <RemoteDeploy Include="__example.cpp">
<!-- This is the source Linux machine, can be empty if DeploymentType is LocalRemote -->
      <SourceMachine>$(RemoteTarget)</SourceMachine>
      <TargetMachine>$(RemoteDebuggingTarget)</TargetMachine>
      <SourcePath>~/example.cpp</SourcePath>
      <TargetPath>~/example.cpp</TargetPath>
<!-- DeploymentType can be LocalRemote, in which case SourceMachine will be empty and SourcePath is a local file on Windows -->
      <DeploymentType>RemoteRemote</DeploymentType>
<!-- Indicates whether the deployment contains executables -->
      <Executable>true</Executable>
   </RemoteDeploy>
</ItemGroup>

"disableDeploy": false,
"deployDirectory": "~\foo",
"deploy" : [
   {
      "sourceMachine": "127.0.0.1 (username=example1, port=22, authentication=Password)",
      "targetMachine": "192.0.0.1 (username=example2, port=22, authentication=Password)",
      "sourcePath": "~/example.cpp",
      "targetPath": "~/example.cpp",
      "executable": "false"
   }
]

Passaggi successivi

• Per eseguire il debug di dispositivi ARM in Linux, vedere questo post di blog relativo al debug di un dispositivo ARM incorporato in Visual Studio.

Vedi anche

Proprietà di debug C++ (Linux C++)