GIT – 다중 원격저장소 (remote repository) 사용 방법

svn 은 하나의 repository 만 설정할 수 있지만,
git 은 여러개의 repository 를 설정할 수 있다.

[#M_ more.. | less.. | git remote add secondremote alt-machine:/path/to/repo_M#]


remote 가 http/https 일경우 다음과 같이 설정하면 된다.


[#M_ more.. | less.. | git remote add secondremote _M#]

인증이 필요할 경우 매번 id 와 암호를 입력해야 하므로 id 정도는 url 에 같이 포함시키는 것이 편리하다. id와 @ 를 도메인 앞에 붙여 주면 된다.


[#M_ more.. | less.. | git remote add secondremote]


새로 추가된 remote에 기존의 내용(commit)을 업데이트 (push)하기 위해서는 다음의 명령어도 가능


[#M_ more.. | less.. |git push -u secondremote _M#]

모든 remote 에서 branch 및 update 된 내역을 가져오려면 다음 명령어 실행(HEAD 에 merge 하지는 않는다.)


[#M_ more.. | less.. | git remote update _M#]

alt remote 의 master branch 에서 fetch 하고 현재 HEAD 에 pull


[#M_ more.. | less.. | git pull alt master_M#]


매번 repository 마다 push/pull 을 따로 해줘야 하는게 번거롭다면 stackoverflow의 pull/push from multiple remote locations 글의 답변을 참고


메모리 보호 기법 SSP(Stack Smashing Protector)


Stack Smashing Protector은 gcc 4.1버전 부터 있는 stack overflow를 방지하기 위한 컴파일러 옵션이다.


gcc 4.6.1버전에서 컴파일 후 overflow가 발생하는 프로그램을 실행시켜 보니 다음과 같이 stack smashing detected가 뜨는 것을 확인 할 수 있다.

SSP 끄기 : -fno-stack-protector

SSP를 모든 함수에 설치 : -fstack-protector-all (원래는 일정 크기의 char배열이 있는 함수에만 적용됨)

SSP의 기능을 살펴보자

1. 로컬 변수 재배치

2. 로컬 변수전에 포인터 배치

3. canary 삽입


1. 로컬 변수 재배치


#include <stdlib.h>
#include <stdio.h>
#include <string.h>


void main(int argc, char *argv[])


    int check=0;
    char buf[10];

    strcpy(buf, argv[1]);


    printf(“check : %d\n”, check);


buf를 오버플로우시켜서 check값을 바꿀 수 있을 것이다. 하지만 SSP는 스택에서 char배열을 제일 높은 곳으로 올려 다른 변수 값이 변조되는 것을 막는다.



2. 로컬 변수전에 포인터 배치


void test(char *arg)


char buf[10];

strcpy(buf, arg);


위와 같이 포인터가 있을 때 buf를 오버플로우 시켜서 test함수의 파라미터로 전달된 포인터 arg값을 바꿀 수 있을 것이다. 하지만 SSP는 arg포인터를 buf아래 쪽에 두어서 변조되는 것을 막는다.




3. canary 삽입



|       ret     |


|      ebp     |


|   canary  |


|       buf     |



stack guard처럼 canary를 두어 ret변조를 탐지한다. 이 때 canary는 ebp와 buf 사이에 넣는다. canary 값은 1) random, 2) terminator, 3) null 을 사용하여 우회하는 것을 방지한다. canary 변조를 탐지 했을 때 맨위 그림와 같이 stack-smashing-detected 메시지를 띄어준다. (변조 탐지시 __stack_chk_fail함수를 호출)


GDB 사용시 raise.c 와 같이 glibc 파일이 없다고 나오는 경우

에러 메시지 
Unable to open ‘raise.c’: File not found (file:///build/glibc-Cl5G7W/glibc-2.23/sysdeps/unix/sysv/linux/raise.c).

이 경우 우선 glibc 를 소스까지 다운로드

Building glibc without installing

To build glibc without installing you can do the standard configure and make e.g.

$ mkdir $HOME/src
$ cd $HOME/src
$ git clone git://
$ mkdir -p $HOME/build/glibc
$ cd $HOME/build/glibc
$ $HOME/src/glibc/configure --prefix=/usr
$ make

Do not run make install.

이후 아래 설명을 참고하여, 찾고자 하는 링크 위치를 심볼릭 링크 걸어주면 해결

To do full source code debugging of the C library on Ubuntu, you need to:

1) install the debuginfo version of libc6.

It’s probably already installed, but in case it isn’t, run sudo apt install libc6-dbg.

2) download the source code corresponding to the installed version of the C library.

First, create a directory anywhere – I’ll use /opt/src here. Then do the following:

sudo apt install dpkg-dev
cd /opt/src
apt source libc6
find $PWD -maxdepth 1 -type d -name 'glibc*'

Remember this name – it’ll be something like /opt/src/glibc-2.23

Now, run gdb, run your program until it stops, and at the gdb prompt do this:

(gdb) info source
Current source file is ../sysdeps/unix/sysv/linux/raise.c
Compilation directory is /build/glibc-KM3i_a/glibc-2.23/signal

So gdb is expecting the source code to be in a directory that’s different from where we put it. There are two ways to fix this:

a) move or use a symlink so that the source code is (or appears to be) in /build/glibc-KM3i_a/glibc-2.23 .

b) tell gdb how to substitute the correct source directory pathname: 

  (gdb) set substitute-path /build/glibc-KM3i_a/glibc-2.23 /opt/src/glibc-2.23

Now, go back to your frame, and gdb should show the source code line:

(gdb) frame 1
#1 0xb7e2fea9 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
         return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

원격 호스트의 gdb(gdbserver)를 이용하여 로컬에서 debugging 하기.

다음의 세개의 글 참조


How to Debug Programs on Remote Server using GDBServer Example

GDBRemote debugging is the process of debugging a program running on a different system (called target) from a different system (called host).

To start remote debugging, a debugger running on host machine connects to a program which is running on the target via network.

The debugger in the host can then control the execution of the program on the remote system and retrieve information about its state.

Remote debugging is often useful in case of embedded applications where the resources are limited.

In this tutorial, we will see how we can debug programs running on a different system using GDB Server.

If you are new to GDB, you should first understand how to use GDB to debug C program.

We need the following two utilities to perform a remote debugging.

  • gdbserver – Run this on your target system
  • GDB – Execute this on your host system to connect to your target system

GDB and gdbserver communicate via either a serial line or a network, using the standard gdb remote serial protocol.

1. Install gbdserver on Target System

Target machine is the one which is running the program which you have to debug. You need to have the “gdbserver” executable on the target machine.

$ sudo apt-get install gdbserver

To do remote debugging, start your program using the gdbserver. gdbserver then automatically suspends the execution of your program at its entry point, and it waits for a debugger to connect to it. gdbserver doesn’t need the symbols from your program to debug. So you can strip symbols out of your program binary to save space.

$ gdbserver localhost:2000 my_prg 

Process program created; pid = 2045
Listening on port 2000

The above command suspend the execution on my_prg, and waits for a debugger to connect to it on port 2000.

2. Launch gdb on Host System

The executable file and the libraries in the host, must exactly match the executable file and libraries on the target, with an exception that the target binary symbols can be stripped. You can also load the symbols separately in the host using “file” command in gdb.

Run GDB on the host.

$ gdb my_prg

Use “target remote” to connect to the target system.

(gdb) target remote

Now you can run the normal gdb commands, as if you are debugging a local gdb program.

3. Remote Debugging Demo Example

The following C program example will be used to demonstrate the remote debugging.

#include <stdio.h>

int power(int,int);

int main() {

        int i;
        printf("Program to calculate power\n");
        for (i=0;i<10;i++)
                printf("%d %d\n",i, power(2,i));
        return 0;

int power (int base, int n) {

        int i,p;
        for (i=1; i<=n; i++)
                p = p*base;
        return p;

$ cc -g -o my_prg power.c

On Target Machine,

$ gdbserver localhost:2000 my_prg
Process my_prg created; pid = 20624
Listening on port 2000

On Host Machine,

$ gdb my_prg

(gdb) target remote
Remote debugging using
Loaded symbols for /lib64/
0x00007ffff7dddaf0 in ?? () from /lib64/
(gdb) b main
Breakpoint 1 at 0x400550
(gdb) continue 

Breakpoint 1, 0x0000000000400550 in main ()

Now we have connected the gdb for remote debugging. In the last example, we have put a breakpoint in main() function. If we continue our program, the output of the program will be printed in the target machine.

On Host:

(gdb) continue

On Target:

Remote debugging from host
Program to calculate power
0 1
1 2
2 4
3 8
4 16
5 32
6 64
7 128
8 256
9 512

Child exited with status 0
GDBserver exiting

4. Attach gdb to a Running Process on Target

First you have to find the process ID of the running process in target.

On Host,

(gdb) attach 3850

Now the gdb will suspend the process 3850 in the target and you can debug the program using normal gdb commands.

5. Launch gdbserver in Multi-process Mode

In the previous demo, you would have noticed that once the program executed successfully, the gdbserver also got exited. In real-time, you may want to debug multiple programs remotely, and you may not want to start the gdbserver every time with different program names. Do the following to achieve that.

On Target, run the gdbserver with –multi and without a program name.

$ gdbserver --multi localhost:2000
Listening on port 2000

On Host,

$ gdb

(gdb) target extended-remote
Remote debugging using

(gdb) (gdb) set remote exec-file /my_prg
(gdb) file /my_prg 
Reading symbols from /my_prg...(no debugging symbols found)...done.
(gdb) b main
Note: breakpoint 1 also set at pc 0x400550.
Breakpoint 2 at 0x400550
(gdb) run
Starting program: /my_prg
Breakpoint 1, 0x0000000000400550 in main ()

From the above snippet,

  1. ‘target extended-remote’ is used to run gdbserver in multi process mode.
  2. ‘set remote exec-file /my_prg’ is used to set the program which you want to debug in the target.
  3. ‘file /my_prg’ is used to load the debugging symbols from the program in the host.
  4. ‘b main’ is used to set breakpoint at main() function.
  5. ‘run’ is used to run the program, which stops at the breakpoint main().

Note: In the above case, the executable “my_prg” is present under “/” on both target and host.

Now either you can ‘continue’ or ‘detach’ the program from debugging. Still the gdbserver will not exit in the target machine, so you can change the ‘remote exec-file’ at any time, and debug a different set of program.

Debugging C/C++ Programs Remotely Using Visual Studio Code and gdbserver

If you’re like me and prefer using a GUI to a command line for setting breakpoints, stepping through code, and inspecting values as your program runs, here is how you can set up VSCode and gdbserver to edit and debug your code locally while running it on a remote server.

Background: I’m working on an assignment for CSC469 at the University of Toronto, and it will only compile and run on the university’s teaching lab machines. My goal was to be able to edit and debug locally in a familiar editor while compiling and running on the remote teaching lab machines.

Note: I’m using macOS Sierra locally, with the remote machine running Ubuntu 14.04, but this guide should work with any Unix system. (Sorry, Windows users).

Note: Commands to be run on the remote machine are prefixed with remote$and local commands are prefixed with local$ .

1. Install gdbserver on the remote machine

Installation varies by system. On Debian/Ubuntu, you can do:

remote$ apt-get install gdbserver

Since students are not allowed to install software via apt on the U of T machines, I used Linuxbrew to install it to my user folder:

remote$ brew install gdbserver

2. Install gdb on your local machine

On macOS Sierra, I used Homebrew to install gdb:

local$ brew install gdb --with-all-targets

Note: The --with-all-targets option is important; without it, you won’t be able to debug on a remote machine with a different OS or architecture than your local machine.

3. Test gdb

At this point, you should be able to run gdbserver on the remote machine and connect to it from your local gdb CLI. I’ll use the -L option of ssh to forward local port 9091 connections to the remote port 9091:

local$ ssh -L9091:localhost:9091 user@remote
remote$ cd ./myproject/ && make
remote$ gdbserver :9091 ./myprogram

(Port 9091 is arbitrary; use any port number you like)

Leave that command running in a terminal window; it will wait until gdb connects before running ./myprogram .

In another terminal window on your local machine, run gdb:

local$ gdb
GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
For help, type "help".
Type "apropos word" to search for commands related to "word".

Then connect to the gdbserver instance:

(gdb) target remote localhost:9091
Remote debugging using localhost:9091

To verify things are working, you can run various gdb commands like info sources , or set a breakpoint with break . Use continue to run ./myprogram .

4. codesign gdb

VSCode prevents you from running gdb unless it’s signed; follow these steps to ensure it’s signed.

5. Synchronize local and remote file systems

You may have noticed that, for basic functionality, the gdb CLI on your local machine doesn’t need to be provided any information about the program or its source code except for the host and port on which gdbserver is running. But there are two big reasons why you’ll want to keep your local and remote project directories in sync:

  • Viewing source code in the gdb CLI (i.e. list).
  • The VSCode C/C++ extension requires you to provide the path to the compiled executable to launch gdb. (The "program" field in launch.json).

I opted to use sshfs since it required the least server-side setup, but you could use NFS, rsync, or other alternatives.

Using sshfs, mount the remote project folder locally:

local$ mkdir ./myproject
local$ sshfs user@remote:myproject ./myproject

Note: on macOS, you can later unmount the directory with umount ./myproject. On Linux, use fusermount -u ./myproject.

6. Configure Visual Studio Code

Open your newly-mounted project ./myproject/ in VSCode, then open .vscode/launch.json or create it if it doesn’t exist:

"version": "0.2.0",
"configurations": [
"name": "C++ Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/myprogram",
"miDebuggerServerAddress": "localhost:9091",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true,
"linux": {
"MIMode": "gdb"
"osx": {
"MIMode": "gdb"
"windows": {
"MIMode": "gdb"

This configuration will make it so clicking “C++ Launch” will run gdb similar to:

local$ gdb ./myprogram
(gdb) target remote localhost:9091

7. Write a script to compile your program and launch gdbserver

Ideally, you’d want to be able to run a single command or click a single button to compile & debug your program.

This might be possible to do via VSCode tasks and the preLaunchTask option in launch.json, but I was not able to put together a simple solution using those.

Instead I wrote a quick-and-dirty shell script :

# Kill gdbserver if it's running
ssh user@remote killall gdbserver &> /dev/null
# Compile myprogram and launch gdbserver, listening on port 9091
ssh \
-L9091:localhost:9091 \
user@remote \
"zsh -l -c 'cd myproject && make && gdbserver :9091 ./myprogram'"

8. Start debugging

Here is your new workflow:

  1. Edit some code.
  2. Run ./ in a terminal window. Your program’s output will appear here.
  3. Set some breakpoints.
  4. Run “C++ Launch”.
  5. Step through your code in VSCode’s debugger.
  6. Repeat.

That’s it! I hope this helps someone, and let me know if it can be simplified even further.

C/C++ for VS Code (Preview)

C/C++ support for Visual Studio Code is provided by a Microsoft C/C++ extension to enable cross-platform C and C++ development using VS Code on Windows, Linux, and macOS. The extension is still in preview and our focus is code editing, navigation, and debugging support for C and C++ code everywhere that VS Code runs.

cpp hero

If you just want a lightweight tool to edit your C++ files, Visual Studio Code is a great choice but if you want the best possible experience for your existing Visual C++ projects or debugging on Windows, we recommend you use a version of Visual Studio such as Visual Studio Community.

If you run into any issues or have suggestions for the Microsoft C/C++ extension, please file issues and suggestions on GitHub. If you haven’t already provided feedback, please take this quick survey to help shape this extension for your needs.

Note for Linux users: The C/C++ extension works on 64-bit Linux distros that have glibc 2.18 or later installed.

Getting Started

To install the Microsoft C/C++ extension:

  • Open VS Code.
  • Click the Extensions View icon on the Sidebar.
  • Search for c++.
  • Click Install, then click Reload.

cpp extension

With the C/C++ extension installed, open a folder that contains your C/C++ source code. VS Code will place various settings files into a .vscode subfolder.

Note: The C/C++ extension does not include a C++ compiler or debugger. You will need to install these tools or use those already installed on your computer. Popular C++ compilers are MinGW for Windows, XCode for macOS, and GCC on Linux. Also make sure your compiler executable is on your platform path for VS Code to find.


To enable code completion and navigation, you will need to generate a c_cpp_properties.json file:

  • Find any green squiggle in a source file (for example, an #include statement) and set the cursor on the line.
  • Click the lightbulb that appears in the left gutter.
  • Click Update “browse.path” setting.

browse path light bulb

This will generate a c_cpp_properties.json file that allows you to add additional browse paths to properly enable code navigation and auto-completion. The generated c_cpp_properties.json file has sections for different operating systems, make sure you update the appropriate settings for your current platform.

Below you can see that the MinGW C++ include path has been added to browse.path for Windows:

    "name": "Win32",
    "includePath": [
    "defines": [
    "intelliSenseMode": "msvc-x64",
    "browse": {
        "path": [
        "limitSymbolsToIncludedHeaders": true,
        "databaseFilename": ""

Note: You can also generate or edit a c_cpp_properties.json file with the C/Cpp: Edit Configurations command from the Command Palette (Ctrl+Shift+P).

Building your code

If you want to build your application from VS Code, you will need to generate a tasks.json file:

  • Open the Command Palette (Ctrl+Shift+P).
  • Select the Tasks: Configure Tasks… command, click Create tasks.json file from templates, and you will see a list of task runner templates.
  • Select Others to create a task which runs an external command.
  • Change the command to the command line expression you use to build your application (for example g++).
  • Add any required args (for example -g to build for debugging).
  • You can also change the label to be more descriptive.

You should now see a tasks.json file in your workspace .vscode folder that looks something like:

    "version": "2.0.0",
    "tasks": [
            "label": "build hello world",
            "type": "shell",
            "command": "g++",
            "args": [
                "-g", "helloworld.cpp"

If you’d like to be able to build your application with Tasks: Run Build Task (Ctrl+Shift+B), you can add it to the build group.

    "version": "2.0.0",
    "tasks": [
            "label": "build hello world",
            "type": "shell",
            "command": "g++",
            "args": [
                "-g", "helloworld.cpp"
            "group": {
                "kind": "build",
                "isDefault": true

For more information on tasks, see Integrate with External Tools via Tasks.

Debugging your code

To enable debugging, you will need to generate a launch.json file:

  • Navigate to the Debug view by clicking the Debug icon in the Sidebar.
  • In the Debug view, click the Configure icon.
  • Select C++ (GDB/LLDB) (to use GDB or LLDB) or C++ (Windows) (to use the Visual Studio Windows Debugger) from the Select Environment dropdown. This creates a launch.json file for editing with two configurations:
    • C++ Launch defines the properties for launching your application when you start debugging.
    • C++ Attach defines the properties for attaching to a process that’s already running.
  • Update the program property with the path to the program you are debugging.
  • If you want your application to build when you start debugging, add a preLaunchTask property with the name of the build task you created in tasks.json (“build hello world” in the example above).

Below is an example using the MinGW GDB debugger:

    "version": "0.2.0",
    "configurations": [
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:\\mingw\\bin\\gdb.exe",
            "setupCommands": [
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
            "preLaunchTask": "build hello world"

To learn more, see Configuring launch.json for C/C++ debugging.

If you are debugging with GDB on Windows, see Windows Debugging with GDB.

Editing Code

Code Formatting

The C/C++ extension for Visual Studio Code supports source code formatting using clang-format which is included with the extension.

You can format an entire file with Format Document (Shift+Alt+F) or just the current selection with Format Selection (Ctrl+K Ctrl+F) in right-click context menu. You can also configure auto-formatting with the following settings:

  • C_Cpp.clang_format_formatOnSave – to format when you save your file.
  • editor.formatOnType – to format as you type (triggered on the ; character).

By default, the clang-format style is set to “file” which means it looks for a .clang-format file inside your workspace. If the .clang-format file is found, formatting is applied according to the settings specified in the file. If no .clang-format file is found in your workspace, formatting is applied based on a default style specified in the C_Cpp.clang_format_fallbackStyle setting instead. Currently, the default formatting style is “Visual Studio”. Using “Visual Studio” formatting ensures that source code formatting will be compatible in both VS Code and Visual Studio Community.

The “Visual Studio” clang-format style is not yet an official OOTB clang-format style but it implies the following clang-format settings:

UseTab: (VS Code current setting)
IndentWidth: (VS Code current setting)
BreakBeforeBraces: AllMan
AllowShortIfStatementsOnASingleLine: false
IndentCaseLabels: false
ColumnLimit: 0

If you’d like to use a different version of clang-format than the one that ships with the extension, you can use the C_Cpp.clang_format_path setting and set its value to the path where the clang-format binary is installed.

For example on the Windows platform:

  "C_Cpp.clang_format_path": "C:\\Program Files (x86)\\LLVM\\bin\\clang-format.exe"

Fuzzy Auto-Complete

Fuzzy auto-complete is powered by an enhanced tag-parser approach. Although suggestions are not based on semantic analysis of your code, this feature provides a wider selection of matches than the single-file IntelliSense experience provided today.

In particular, this feature’s capabilities give a good experience for C code.

Navigating Code

The source code navigation features provided by the C/C++ extension are powerful tools for understanding and getting around in your codebase. These features are powered by tags stored in an offline database of symbol information. With the C/C++ extension installed, this database is generated whenever a folder containing C++ source code files is loaded into VS Code. The platform indicator (Win32 in the figure below) turns red and appears next to a flame icon while the tag-parser is generating this information.

The platform indicator during tag parsing

When the platform indicator returns to its normal appearance, the source code symbols have been tagged in the offline database and source code navigation features are ready to be used.

Specifying Additional Include Directories for Better Symbol Support

To provide the best experience, the C/C++ extension for VS Code needs to know where it can find each header file referenced in your code. By default, the extension searches the current source directory, its sub-directories, and some platform-specific locations. If a referenced header file can’t be found, VS Code displays a green squiggle underneath each #include directive that references it.

To specify additional include directories to be searched, place your cursor over any #include directive that displays a green squiggle, then click the lightbulb action when it appears. This opens the file c_cpp_properties.json for editing; here you can specify additional include directories for each platform configuration individually by adding more directories to the ‘browse.path’ property.

Search for Symbols

You can search for symbols in the current file or workspace to navigate your code more quickly.

To search for a symbol in the current file, press Ctrl+Shift+O, then enter the name of the symbol you’re looking for. A list of potential matches will appear and be filtered as you type. Choose from the list of matches to navigate to its location.

Searching the current file

To search for a symbol in the current workspace, start by pressing Ctrl+T instead, then enter the name of the symbol. A list of potential matches will appear as before. If you choose a match that was found in a file that’s not already open, the file will be opened before navigating to the match’s location.

Searching in your workspace

Alternatively, you can search for symbols by accessing these commands through the Command Palette if you prefer. Use Quick Open (Ctrl+P) then enter the ‘@’ command to search the current file, or the ‘#’ command to search the current workspace. Ctrl+Shift+O and Ctrl+T are just shortcuts for the ‘@’ and ‘#’ commands, respectively, so everything works the same.

Peek Definition

You can take a quick look at how a symbol was defined by using the Peek Definition feature. This feature displays a few lines of code near the definition inside a peek window so you can take a look without navigating away from your current location.

To peek at a symbol’s definition, place your cursor on the symbol anywhere it’s used in your source code and then press Alt+F12. Alternatively, you can choose Peek Definition from the context menu (right-click, then choose Peek Definition).

Peek definition

Currently, the C/C++ extension doesn’t parse code in a way that helps it distinguish between competing definitions based on how the symbol is used. These competing definitions arise when the symbol defines different things in different contexts, such as occurs with overloaded functions, classes and their constructors, and other situations. When this happens, each of the competing definitions are listed in the right-hand side of the peek window with the source code of the current selection displayed on the left.

With the peek window open, you browse the list of competing definitions to find the one you’re interested in. If you want to navigate to the location of one of the definitions just double-click the definition you’re interested in, or by double-clicking anywhere in the source code displayed on the left-hand side of the peek window.

Go to Definition

You can also quickly navigate to where a symbol is defined by using the Go to Definition feature.

To go to a symbol’s definition, place your cursor on the symbol anywhere it is used in your source code and then press F12. Alternatively, you can choose Go to Definition from the context menu (right-click, then choose Go to Definition). When there’s only one definition of the symbol, you’ll navigate directly to its location, otherwise the competing definitions are displayed in a peek window as described in the previous section and you have to choose the definition that you want to go to.


After you have set up the basics of your debugging environment as specified in Getting Started, you can learn more details about debugging C/C++ in this section.

VS Code supports the following debuggers for C/C++ depending on the operating system you are using:

  • Linux: GDB
  • macOS: LLDB or GDB
  • Windows: the Visual Studio Windows Debugger or GDB (using Cygwin or MinGW)

Windows Debugging with GDB

You can debug Windows applications created using Cygwin or MinGW by using VS Code. To use Cygwin or MinGW debugging features, the debugger path must be set manually in the launch configuration (launch.json). To debug your Cygwin or MinGW application, add the miDebuggerPath property and set its value to the location of the corresponding gdb.exe for your Cygwin or MinGW environment.

For example:

    "miDebuggerPath": "c:\\mingw\\bin\\gdb.exe"

Cygwin/MinGW debugging on Windows supports both attach and launch debugging scenarios.

Conditional Breakpoints

Conditional breakpoints enable you to break execution on a particular line of code only when the value of the condition is true. To set a conditional breakpoint, right-click on an existing breakpoint and select Edit Breakpoint. This opens a small peek window where you can enter the condition that must evaluate to true in order for the breakpoint to be hit during debugging.

A conditional break

In the editor, conditional breakpoints are indicated by a breakpoint symbol that has a black equals sign inside of it. You can place the cursor over a conditional breakpoint to show its condition.

Function Breakpoints

Function breakpoints enable you to break execution at the beginning of a function instead of on a particular line of code. To set a function breakpoint, on the Debug pane right-click inside the Breakpointssection, then choose Add Function Breakpoint and enter the name of the function on which you want to break execution.

Expression Evaluation

VS Code supports expression evaluation in several contexts:

  • You can type an expression into the Watch section of the Debug panel and it will be evaluated each time a breakpoint is hit.
  • You can type an expression into the Debug Console and it will be evaluated only once.
  • You can evaluate any expression that appears in your code while you’re stopped at a breakpoint.

Note that expressions in the Watch section take effect in the application being debugged; an expression that modifies the value of a variable will modify that variable for the duration of the program.

Multi-threaded Debugging

The C/C++ extension for VS Code has the ability to debug multi-threaded programs. All threads and their call stacks appear in the Call Stack section:

Multi-threaded process

Memory Dump Debugging

The C/C++ extension for VS Code also has the ability to debug memory dumps. To debug a memory dump, open your launch.json file and add the coreDumpPath (for GDB or LLDB) or dumpPath (for the Visual Studio Windows Debugger) property to the C++ Launch configuration, set its value to be a string containing the path to the memory dump. This will even work for x86 programs being debugged on an x64 machine.

Additional Symbols

If there are additional directories where the debugger can find symbol files (for example, .pdb files for the Visual Studio Windows Debugger), they can be specified by adding the additionalSOLibSearchPath(for GDB or LLDB) or symbolSearchPath (for the Visual Studio Windows Debugger).

For example:

    "additionalSOLibSearchPath": "/path/to/symbols;/another/path/to/symbols"


    "symbolSearchPath": "C:\\path\\to\\symbols;C:\\another\\path\\to\\symbols"

Locate source files

The source file location can be changed if the source files are not located in the compilation location. This is done by simple replacement pairs added in the sourceFileMap section. The first match in this list will be used.

For example:

"sourceFileMap": {
    "/build/gcc-4.8-fNUjSI/gcc-4.8-4.8.4/build/i686-linux-gnu/libstdc++-v3/include/i686-linux-gnu": "/usr/include/i686-linux-gnu/c++/4.8",
    "/build/gcc-4.8-fNUjSI/gcc-4.8-4.8.4/build/i686-linux-gnu/libstdc++-v3/include": "/usr/include/c++/4.8"

GDB, LLDB and MI Commands (GDB/LLDB)

For the C++ (GDB/LLDB) debugging environment, you can execute GDB, LLDB and MI commands directly through the debug console with the -exec command, but be careful, executing commands directly in the debug console is untested and might crash VS Code in some cases.

Other Debugging Features

  • Unconditional breakpoints
  • Watch window
  • Call stack
  • Stepping

For more information on debugging with VS Code, see this introduction to debugging in VS Code.

Known Limitations

Symbols and Code Navigation

All platforms:

  • Because the extension doesn’t parse function bodies, Peek Definition and Go to Definition don’t work for symbols defined inside the body of a function.



  • GDB on Cygwin and MinGW cannot break a running process. To set a breakpoint when the application is running (not stopped under the debugger), or to pause the application being debugged, press Ctrl-C in the application’s terminal.
  • GDB on Cygwin cannot open core dumps.


  • GDB needs elevated permissions to attach to a process. When using attach to process, you need to provide your password before the debugging session can begin.


  • LLDB:
    • When debugging with LLDB, if the Terminal window is closed while in break mode, debugging does not stop. Debugging can be stopped by pressing the Stop button.
    • When debugging is stopped the Terminal window is not closed.
  • GDB:
    • Additional manual install steps need to be completed to use GDB on macOS. See Manual Installation of GDB for OS X in the README.
    • When attaching to a process with GDB, the application being debugged cannot be interrupted. GDB will only bind breakpoints set while the application is not running (either before attaching to the application, or while the application is in a stopped state). This is due to a bug in GDB.
    • Core dumps cannot be loaded when debugging with GDB because GDB does not support the core dump format used in macOS.
    • When attached to a process with GDB, break-all will end the process.

Next Steps

Read on to find out about:

  • Basic Editing – Learn about the powerful VS Code editor.
  • Code Navigation – Move quickly through your source code.
  • Tasks – use tasks to build your project and more
  • Debugging – find out how to use the debugger with your project

Common Questions

Q: My project won’t load.

A: VS Code doesn’t currently support C++ project files, instead it considers a directory of your choosing to be the workspace of your project. Source code files inside that directory and its sub-directories are part of the workspace.

Q: How do I build/run my project?

A: VS Code supports tasks that you can configure to build your application, and natively understands the output of MSBuild, CSC, and XBuild. For more information, see the Tasks documentation.

If you have any other questions or run into any issues, please file an issue on GitHub.

mysql 데이터베이스 생성 및 사용자 추가

mysql 데이터베이스 생성 및 사용자 추가 
<mysql 접속>

# mysql -u root -p
root 패스워드 치고 접속
<데이터베이스 목록 확인>

mysql> show databases;
| Database                |
| information_schema |
| mysql                     |
2 rows in set (0.00 sec)

<test 데이터베이스 생성>

mysql> create database test;
<데이터 생성되었는지 확인>

mysql> show databases;
| Database                |
| information_schema |
| mysql                     |
| test                        |
3 rows in set (0.00 sec)
<사용자 추가하고 생성한 데이터베이스 사용 권한 주기>

grant all privileges on test.* to testuser@localhost identified by ‘testuser 계정의 패스워드 입력’ with grant option;
<testuser 사용자 생성되었는지 확인>

mysql> use mysql;
mysql> select * from user;     <- 이건 전체 유저 확인
mysql> select * from user where user=’testuser’;     <- 이건 testuser 계정 확인
<DataBase 삭제 >

mysql> drop database test;
<testuser 사용자 삭제>

mysql> delete from user where user=’testuser’;

시놀로지 NAS에서 GIT 서버 구축 및 프로젝트 관리

Synology NAS에서의 작업 
1. 제어판에서 SSH 활성화
2. 제어판에서 “사용자 홈 서비스 활성화”
3. 제어판에서 git을 사용할 사용자의 homes 권한은 “읽기/쓰기” 권한을 부여
4. 패키지 센터에서 “Git Server”을 다운로드.
5. “Git Server”을 실행후, git 을 사용할 사용자에게 권한을 부여
Synology NAS – SSH로 접속 후, root 로그인 

cd volumes1/homes/gituser (Git 사용자)
mkdir project.git   (Git 프로젝트 폴더)
cd project.git
git init –bare –shared
git update-server-info
chown -R gituser:users project.git (권한을 Git 유저에게 부여)
ls -al (권한이 제대로 옮겨졌는지 확인)
이후 원격지에서 Synology NAS GIT 서버에 리포지토리로 추가하는 방법.
mkdir project.git (원격지의 Git 프로젝트(리포지토리)생성)
cd project.git
git init
git remote add origin ssh://gituser@시놀로지IP:포트/volume1/homes/gituser/project.git (Git 폴더)

시스템 스피커로 비프음 내기 (C++ / C#) 모든 윈도우 32/64비트 버전

윈도우 7 64Bit 이상부터는, 더 이상 시스템의 내장 스피커를 이용하여 비프음을 낼 수 없다고 한다. (윈도우 API에서 더 이상 지원하지 않음)

그러나 아래 링크와 같이 시스템에 직접 접근해서 가능하다.

링크 :

링크 캡쳐 (원문의 링크가 없어져 더이상 보기 어려울 경우를 대비)

사용자 삽입 이미지

C#에서 외부프로그램 실행 및 종료

C#으로 짠 또다른 프로그램(other.exe)을 실행하기위해서


System.Diagnostics.Process proc = System.Diagnostics.Process.Start(“./other.exe”);






public const int WM_SYSCOMMAND = 0x0112;

public const int SC_CLOSE = 0xF060;



public static extern int FindWindow(

    string lpClassName, // class name

    string lpWindowName // window name




public static extern int SendMessage(

    int hWnd, // handle to destination window

    uint Msg, // message

    int wParam, // first message parameter

    int lParam // second message parameter




1. FindWindows로 창핸들을 찾아온다


int iHandle=Win32.FindWindow(className ,txtWndNm.Text);

2. SendMessage로 클로즈메세지를 보낸다.


int j=Win32.SendMessage(iHandle, Win32.WM_SYSCOMMAND,Win32.SC_CLOSE, 0);


Process.Kill()을 했는데도 안죽은게 이상하긴 하지만 위와 같이 사용하시면 확실히 죽을겁니다.

또한 외부 프로그램에 Message를 던질수도 있습니다.

[C#] 관리자 권한으로 실행하기

관리자 권한이 없는 상태에서 시스템의 정보를 읽거나 쓰려고 할때 프로그램이 올바르게 작동하지 않습니다. 이럴때 프로그램이 실행되면서, 관리자 권한으로 상승시키는 것이 필요한데요. C#에서 이러한 내용에 대한 코드를 정리합니다. 모든 코드는 Program.cs에서 이루어집니다. 먼저 using 절에 다음과 같은 네임스페이스를 추가합니다.

using System.Security.Principal;
using System.Diagnostics; 

그리고 현재 관리자 권한 상태인지의 여부를 파악하는 함수를 추가합니다.

public static bool IsAdministrator()
    WindowsIdentity identity = WindowsIdentity.GetCurrent();
    if (null != identity)
        WindowsPrincipal principal = new WindowsPrincipal(identity);
        return principal.IsInRole(WindowsBuiltInRole.Administrator);
    return false;

Program.cs 파일의 Main 함수의 시작 부분에 다음의 코드를 추가하여 관리자 권한으로 실행되는지를 확인 한다.

            if (IsAdministrator() == false)
                    ProcessStartInfo procInfo = new ProcessStartInfo();
                    procInfo.UseShellExecute = true;
                    procInfo.FileName = “IPSwitcher”;
                    procInfo.WorkingDirectory = Environment.CurrentDirectory;
                    procInfo.Verb = “runas”;
                catch (Exception ex)
                    Console.WriteLine(“This Program need to Administrator Authority:” + ex.Message);



Asterisk 설치 방법

Asterisk 설치 방법이 정리가 잘 되어 있음!~

출처 :


Tired of fighting with configs?

Try SIP.js and OnSIP — a perfect pairing for WebRTC!

Configure Asterisk

SIP.js has been tested with Asterisk 11.11.0 without any modification to the source code of SIP.js or Asterisk. Similar configuration should also work for Asterisk 12.

System Setup

Asterisk and SIP.js were tested using the following setup:

Required Packages

Install the following dependencies:

  • wget
  • gcc
  • gcc-c++
  • ncurses-devel
  • libxml2-devel
  • sqlite-devel
  • libsrtp-devel
  • libuuid-devel
  • openssl-devel

Using YUM, all dependencies can be installed with:

yum install wget gcc gcc-c++ ncurses-devel libxml2-devel sqlite-devel libuuid-devel openssl-devel.

Install libsrtp

First try installing libsrtp from the repo.

yum install libsrtp-devel

If libsrtp is not available in the repo install it from source.

  1. cd /usr/local/src/
  2. wget
  3. tar zxvf srtp-1.4.2.tgz
  4. cd /usr/local/src/srtp
  5. ./configure CFLAGS=-fPIC
  6. make && make install

Install Asterisk

  1. cd /usr/local/src/.
  2. Download Asterisk withwget
  3. Extract Asterisk: tar zxvf asterisk*.
  4. Enter the Asterisk directory: cd /usr/local/src/asterisk*.
  5. Run the Asterisk configure script:./configure --libdir=/usr/lib64.
  6. Run the Asterisk menuselect tool: make menuselect.
  7. In the menuselect, go to the resources option and ensure that res_srtp is enabled. If there are 3 x’s next to res_srtp, there is a problem with the srtp library and you must reinstall it. Save the configuration (press x).
  8. Compile and install Asterisk: make && make install.
  9. If you need the sample configs you can run make samples to install the sample configs. If you need to install the Asterisk startup script you can run make config.

Setup DTLS Certificates

  1. mkdir /etc/asterisk/keys
  2. Enter the Asterisk scripts directory:cd /usr/local/src/asterisk*/contrib/scripts.
  3. Create the DTLS certificates (replace with your ip address or dns name, replace My Super Company with your company name):./ast_tls_cert -C -O "My Super Company" -d /etc/asterisk/keys.

Configure Asterisk For WebRTC

For WebRTC, a lot of the settings that are needed MUST be in thepeer settings. The global settings do not flow down into the peer settings very well. By default, Asterisk config files are located in/etc/asterisk/. Start by editing http.conf and make sure that the following lines are uncommented:

bindaddr= ; Replace this with your IP address
bindport=8088 ; Replace this with the port you want to listen on

Change the IP address and port to the IP address of your server and the port that you would like Asterisk to listen for web socket connections on.

Next, edit sip.conf. Here you will set up two peers, one for a WebRTC client and one for a non-WebRTC SIP client. The WebRTC peer requires encryption, avpf, and icesupport to be enabled. In most cases, directmedia should be disabled. Also under the WebRTC client, the transport needs to be listed as ‘ws’ to allow websocket connections. All of these config lines should be under the peer itself; setting these config lines globally might not work.

realm= ; Replace this with your IP address
udpbindaddr= ; Replace this with your IP address

[1060] ; This will be WebRTC client
username=1060 ; The Auth user for SIP.js
host=dynamic ; Allows any host to register
secret=password ; The SIP Password for SIP.js
encryption=yes ; Tell Asterisk to use encryption for this peer
avpf=yes ; Tell Asterisk to use AVPF for this peer
icesupport=yes ; Tell Asterisk to use ICE for this peer
context=default ; Tell Asterisk which context to use when this peer is dialing
directmedia=no ; Asterisk will relay media for this peer
transport=udp,ws ; Asterisk will allow this peer to register on UDP or WebSockets
force_avp=yes ; Force Asterisk to use avp. Introduced in Asterisk 11.11
dtlsenable=yes ; Tell Asterisk to enable DTLS for this peer
dtlsverify=no ; Tell Asterisk to not verify your DTLS certs
dtlscertfile=/etc/asterisk/keys/asterisk.pem ; Tell Asterisk where your DTLS cert file is
dtlsprivatekey=/etc/asterisk/keys/asterisk.pem ; Tell Asterisk where your DTLS private key is
dtlssetup=actpass ; Tell Asterisk to use actpass SDP parameter when setting up DTLS

[1061] ; This will be the legacy SIP client

Lastly, set up extensions.conf to allow the two peers to call each other.

exten => 1060,1,Dial(SIP/1060) ; Dialing 1060 will call the SIP client registered to 1060
exten => 1061,1,Dial(SIP/1061) ; Dialing 1061 will call the SIP client registered to 1061

Restart Asterisk using service asterisk restart to ensure that the new settings take effect.

Configure SIP.js

Asterisk does not accept Contact headers with the .invaliddomain. When creating a UA, add the configuration parameterhackIpInContact. If you are missing this property you will be able to make calls from WebRTC, but not receive calls through Asterisk will fail.

Additionally this guide will only work with audio calls, Asterisk will reject video calls.

The following configuration example creates a UA for the Asterisk configuration above. Replace the values with the values from your config.

var config = {
  // Replace this IP address with your Asterisk IP address
  uri: '1060@',

  // Replace this IP address with your Asterisk IP address,
  // and replace the port with your Asterisk port from the http.conf file
  ws_servers: 'ws://',

  // Replace this with the username from your sip.conf file
  authorizationUser: '1060',

  // Replace this with the password from your sip.conf file
  password: 'password',
  // HackIpInContact for Asterisk
  hackIpInContact: true,

var ua = new SIP.UA(config);

// Invite with audio only
  audio: true,
  video: false
  • Update 10/24/2014 – If you are still having trouble with Asterisk and are using a WebSocket Secure (WSS), you can try using thehackWssInTransport: true parameter in your UA’s configuration. This is new as of commit 32bffbe on the SIP.js Master branch.


Firefox 34+ requires SIP.js 0.6.4 or later to interop with FreeSWITCH or Asterisk.

This forum post on troubleshooting WebRTC issues is a great guide for trouble shooting problems with Asterisk.

Asterisk Secure Calling Guide can help you setup dtls certificates.