김시환 님이 쓰신 글 :
:
: 빌더 3.0 시절부터 지금까지 쭉 장비제어 프로그램을 개발하고 있는데 늘 고민인 것이 테스트와 디버깅 및 기능 보완 수정입니다.
:
: 처음 개발 시작할 때는 그냥 사무실의 개인 PC에서 작업을 하고 코팅이 마무리 되고 장비 제작이 완료가 되면 제어 PC에서 디버깅 및 테스트를 돌립니다.
:
: 예전 초창기에는 원격 설치가 아닌 설치 원본 CD와 설치키가 있어서 제어 PC에 개발툴 설치하고 디버깅 및 테스트 한후 납품전에 개발툴 삭제했었습니다. 그러다 장비 사용중에 수정 요청이 있으면 간단한 것은 수정후 실행파일만 던져 주고 복잡한 수정은 현장가서 개발툴 또 설치하고 수정, 테스트 하고 지우기를 반복했습니다.
:
: 그러던 것이 최근에는 개발툴의 설치 제한 횟수가 정해지는 방식으로 변경되고 그나마도 매년 갱신하지 않으면 설치가 불가능하게 변경되면서 고민에 휩싸였습니다.
:
: 물론 1달 사용 가능한 임시 버젼으로 설치하고 디버깅하면 되는데 이게 또 은근 짜증을 유발합니다. 컴파일 몇번하고 나면 개발툴을 종료 후 재 로딩하기를 반복해야 하고 써드파티 컴포넌트 라도 있으면 매번 이거 설치하는 것도 장난이 아닙니다. 물론 현장가서 수정할 일이라도 생기면 또 지우고 재설치 하기를 반복해야 합니다.  재경우에는 심한 경우 장비를 1년에 서너번 이상 수정해 줄때도 있습니다.
:
: 어떤 장비는 10년이 다돼 가는데 수정해 달라는 것도 부지기 수 입니다.
:
: 그래서 이번에 본격적으로 PAServer 를 도입해서 해 보려고 하는데 이게 또 만만치가 않네요..
: 일단 노트북과 제어PC를 랜으로 1:1 연결하고 테스트 및 디버깅을 하는데  원인을 찾고 에러 수정하고 재 실행하려고 하면 제어PC 상에 디버깅 프로세스가 살아 있어서 바로 실행이 안됩니다. 매번 작업관리자에 들어가서 디버깅 백그라운드 프로세스를 죽여야만 재 실행이 되니 이게 여간 짜증나는 일이 아니네요.. 이 증상은 예전에도 있었는데 버젼이 몇번이나 바뀌어도 수정이 안돼네요..
:
: 더군다나 PAServer 가 1:1 로 연결이라도 잘 되면 괜찮은데 이게 어찌 연결에 실패하면 절대 재 연결이 안됩니다.
: WiFi 이용해서 어찌 연결을 해서 디버깅하려고 하면 너무 느려 터져서 숨막혀 죽을 지경입니다.
: 이게 저만 그런건지 다들 저처럼 고생고생 하면서 개발하시는지 혹시 기발한 방법이 있으시면 공유좀 해주세요..
:
:
:




엠바 툴은 문제가 많죠.

리모트가 아닌 로컬 디버깅 시에도 32비트 프로그램은 디버깅이 그런대로 되나
64비트로 컴파일해서 디버깅 시에 'disconnected session' 이라는 정체 불명의 에러가 나면서
IDE가 먹통이 돼 버리는 현상이 있는데.

이런 현상이 나타나는 이유는...

IDE가 32비트 프로그램이라 별도의 외부 64비트 디버거 프로세스를 이용해서 64비트 프로그램을 디버깅하도록
엠바 툴이 구성되어 있는데

64비트 디버거와 32비트 IDE 사이의 프로세스간 정보교환을 위한 IPC 메카니즘으로 Shared memory 기법을 이용하면
매우 효율적이고 간단했을 것을 엠바 애들은 IPC 메카니즘에 로컬 디버깅 시에도 소켓을 이용하고 있어요.

64비트로 컴파일해서 디버깅 시에 나타나는 'disconnected session' 에러는 소켓 세션이 끊켰다는 것을 의미 합니다.

리모트 디버깅도 아닌 로컬 디버깅 시에는 굳이 소켓을 이용할 이유가 전혀 없음에도 불구하고 이걸 이용하고 있는 것은...
멀티플렛폼 지원한답시고 소켓을 이용해 만들어 놓은 리모트 디버거의 코드를 그대로 베껴서 로컬 디버거에서 써 먹고 보자는
게으름 때문일 겁니다.

'disconnected session' 에러가 발생하는 이유는 IDE나 디버거 소켓 코드에 버그가 있다는 것을 의미하는 거고.

리모트 디버거도 같은 맥락이죠.

툴의 소켓 코드에 버그가 있다는 것.


엠바 툴의 버그를 모든 상황에 일반적으로 적용할 수는 없겠으나

리모트와 로컬 양쪽 PC에서 관리자권한으로 코맨드 창을 열어서

netsh winsock reset

실행 후 재부팅 해서 시도해 보세요.



그리고 또 하나... 황당한 문제점.


리모트 디버깅시  지정한 리모트쪽 scratch 디렉토리로 컴파일한 바이너리와
디버깅 정보 파일 등이 PAClient에 의해서 리모트 쪽으로 카피되는데...

처음 컴파일해서 디버깅 할 때와 디버깅 세션 종료 후 다시 F9 눌러서 디버깅 할 때는 문제가 없는데
소스파일을 수정해서 다시 컴파일 되었을 경우. 즉 디버깅 정보 파일 내용이 변경되어 새로 갱신된
디버깅 정보 파일이 리모트쪽으로 다시 Deploy 되어야 하는데...

리모트쪽 PAServer 에서 이전의 디버깅 정보 파일을 닫지 않고 계속해서 파일핸들을 열어놓고 있어서
카피가 되지 않는 황당한 일이 벌어집니다.





또다른 문제. Rad Studio 10.4 의 경우 C++ 64비트 리모트 디버깅도 안된다는 것.

10.4 버전에선 C++  64비트 디버깅 시... lldb mi 인터페이스를 이용한 디버거가 사용되고...
lldb를 이용한 디버깅 시에 변수 쿼리시 파이썬 스크립트 코드를 실행해서 쿼리하도록
디버거 구조를 만들어 놨는데...(32비트는 legacy 디버거 사용)

리모트 쪽에서 lldb를 사용하는 환경이 누락되어 있어서 64비트 C++ 리모트 디버깅이 안됍니다.





아.

이런 아마추어 같은 애들이 무슨 컴파일러를 만들겠다고 설레발 치고 있는 건지.
별볼일 없는 프로젝트 매니져 애들 싹 짤라내고 유능한 인재로 물갈이 하지 않는 이상
엠바는 더 이상 기대할 게 없어요. 만들기 쉬운 파스칼 컴파일러에 올인해서 현상 유지하는 정도 밖에는.


엠바툴은 IDE, LSP, Debugger 모든 것들이 워낙에 엉망.