'Programming/System'에 해당되는 글 13건

  1. 2010.09.11 터미널에서는 GDB가 아니라 CGDB를 씁시다. 4
  2. 2010.09.08 gdb에서 core dump 디버깅 2
  3. 2010.08.18 gdb 에서 thread 생성/종료 메세지 안나오게 하기 2
  4. 2010.05.31 mmap 사용시 알아둘 사항 (버스오류)
  5. 2007.07.27 FAT12과 FAT16의 부트레코드의 구성이 같은모양인가 보다 2

터미널에서는 GDB가 아니라 CGDB를 씁시다.

오늘 말입니다... 갑자기 GDB로 소스 디버깅(기존소스 분석.........)을 하고 않았더니

GDB에도 색을 넣고 싶었지 말입니다?

그래서 구글링 하다 보니깐 찿았어여? cgdb......

사용자 삽입 이미지

1 gdb 보다 더 괜찮은 놈이 있네.....

cgdb.. 얘도 분명 전에 알았던건데..... 오늘보니깐 또 새롭군여

아치에서는 기본패키지로는 없어서 (......) AUR에서 받아서 컴파일함, 시간은 얼마 안걸리네요....

이젠 소스코드보러 Shift눌러서 Screen변환 (그러고 보니 screen사용한지 벌써 4년이 다되가는군여 아아)

할필요도 없이 바로 소스 나오니깐 편해요... (vim이랑 gdb랑 왔다갔다할 필요가 없다는 말이죠.)

윗창(vim짝퉁), 아랫창(레알(?) GDB) 이 있어서 소스보면서 코딩하니깐 확 눈에 잘 들어오네요.

(왜 vim 짝퉁이냐면.... 어지간한 기능은 제대로 동작하는데... 일부기능은 동작을 안해서 -_- )

메녈페이지 읽기 귀차느신분을 위해서 기초적인 내용은 제가 간단 요약했습니다.

뭐 이정도만 알아도 대충 쓰는덴 지장 없으실거에요.

1 윗창(vim), 아랫창(gdb) 간 서로 이동하려면, i <-> ESC키 를 서로 사용하시면 됩니다.

2 윗창(vim)에서 기본키들은 거의 vim이랑 같습니다,

(hjkl 같은 이동키도 당근 같구여,검색할때 사용하는 /.?  도 페이지 이동 ctrl+f, ctrl+b, n, N 도 마찬가지죠)

3 아랫창(GDB)는 기존 GDB랑 거의 유사합니다... 오히려 일부기능은 더 보기 편하게 만들어 놨더군요.

4 break pointer를 break, clear 하는 방법은 (윗창,  vim 에서) space키를 누르면 토글 됩니다

5 소스 파일을 이동하려면 (윗창에서)  o키를 누르시면 됩니다.

그럼 현제 디렉토리에 있는 파일들 리스트가 쭈욱~ 출력되구요, 선택하시면 되겠죠

6 물론 종료하는건 ( vim 창에서) :q해서 빠져나가거나, gdb창에서 q해서 빠져나가시면 됩니다.


메녈페이지는 다음 링크보면 나와염... 더 자세한 내용을 보시려면 다음링크를 방문해 보세요

http://cgdb.sourceforge.net/docs/cgdb-no-split.html#Controlling-CGDB

아주 갈수력 실력이 줄어드는게 눈에 보이는군요

아아... 옛날엔 당연하던게 이제보니깐 짱좋은 기능이 되버렸네여

어서 빨리 윈도우플밍 가튼거 버리고 터미널의 세계로 빠지고 싶네여.... 눅스하는 회사 가가시퍼여......

어?! 그러고 보니 난 GDB자체에 색깔넣는게 목표였지 (GDB 명령어라던가,,, 변수에 따른 글자색이라던가)

이게 목표가 아니었네 .... 행여 이쪽에 대해서 아시는분이 있으면 댓글 부탁 드려요!

ps; 으아아아악 ctags가 안먹혀어..........

2 무기력증

요즘엔 말이져..

다 하기 싫다는.. 걍 귀차늠...

일하는것도 보람도 없고 걍 별 흥미없는걸로 시간때우고 웝급받고 하는 이런 무한루프에 빠진..

그러다보니 메너리즘 크리 + 무기력증 이 엄습........

그래서 또 구글신님께 빌어봤어요. 그래서 찾은게 이거... 역시 나만 그런게 아니였어

http://kldp.org/node/52929

비록 5년전 글이지만.... 뭔가 와닫는게 있네요.

1. 목표먼저 세우거나
2. 걍 놀거나
3. 컴터를 버린다 (어?)

............ 아중에 하난가;

음... 역시 "계획", "하루 목표" 이게 없어서 무기력해졌던거 같군여.. 아 그리고 필수적으로 "실행" 이 있어야

겠지여... 이게 없으면 앞에 2개가 완전 도루묵이니까.....

gdb에서 core dump 디버깅

일단 dump파일을 쓸수 있는 환경 인지 조사해 본다

ulimit -c

만약 "0"라면 크기를 늘립시다..... 한.. 100000? 뭐 값은 알아서.....ㅋ

아마.. 따로 설정하지 않는이상 어지간한 배포판에서는 "0"로 설정되어 있을겁니다....

(특정배포판에 따라서.... 이 값이 고정되어 있을수도 있으므로 주의하자. 특히 레뎃, 페도라는......)

ulimit -c 100000

자..... 이젠 세그멘테이션 폴트를 일으키면 덤프파일을 내뱉게 됩니다 >_<

그담엔 gcc에서 실행하는 방법...

순서대로 적어야된다는.....  안그럼 에러(?) 뜬다는.....

gcc <exec_filename> <dump_filename>

그름 인제 다음과 같이 심볼 읽어들은 다음에, 틀린부분을 뱉어줍니다.

ps; 여러분! gcc컴파일할때 디버그 정보를 보려면 '-g' 옵션을 붙이는것은 다 아시죠? (네에~)

Reading symbols from /usr/lib/libpng14.so.14...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libpng14.so.14
......
Reading symbols from /usr/lib/libXdmcp.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libXdmcp.so.6
Core was generated by `./qq'.
Program terminated with signal 11, Segmentation fault.
#0  main (argc=1, argv=0xbfdae444) at /tmp/qq.c:26
26          *a= 3;

이리 쉬운걸 몰라쓰까여......  분명

"세그멘테이션 폴트 일어나면 덤프파일을 만든다" 까지는 알고 있었는데....

(어연 옛날? 학교 유닉스 서버에서는 분명이 덤프파일이 떳었던걸로 기억하는지라 그때부터 알았는데..... )

왜 눅스에서는 덤프파일은 안나오지... 이상하다.. 라고 "생각" 만 했었거든요 -_-....

(분명히 설정값 건드리면 나올거라고 생각은 했는데)

왜 GDB랑 생각을 안했는지 미스테리...

ulimit 명령어가 있었다는것도 지금 알았네요.... GDB는 초보라능.....

- 지금 프로그램 띠워나서... 세그폴트날때까지 기대리고 있는데... 안죽네여 아놔.. 아깐 그렇게 잘 죽더니만

gdb 에서 thread 생성/종료 메세지 안나오게 하기

GDB랑 멀티스레드랑 같이 사용하면 스레드 관련 메세지가 나온다

문제는 스레드가 매우자주 (뭐 1초라던가) 생겼다 없어지는 프로그램이라면...

화면에  아래와 같은 문자가 계속나와서 ...... 기존의 디버그 메세지조차 다 없애 버린다는거.....

......
[New Thread 0xb52ceb70 (LWP 30665)]
[Thread 0xb52ceb70 (LWP 30665) exited]
[New Thread 0xb52ceb70 (LWP 30666)]
[Thread 0xb52ceb70 (LWP 30666) exited]
[New Thread 0xb52ceb70 (LWP 30667)]
[Thread 0xb52ceb70 (LWP 30667) exited]
[New Thread 0xb52ceb70 (LWP 30668)]
[Thread 0xb52ceb70 (LWP 30668) exited]
[New Thread 0xb52ceb70 (LWP 30669)]
[Thread 0xb52ceb70 (LWP 30669) exited]
[New Thread 0xb52ceb70 (LWP 30670)]
[Thread 0xb52ceb70 (LWP 30670) exited]
[New Thread 0xb52ceb70 (LWP 30671)]
......
^C
Program received signal SIGINT, Interrupt.
0xb7fe1424 in __kernel_vsyscall ()
(gdb)

이것도 찾아보면 금방나오네여...

(사실 저번에도 찾았는데... 그렇게 안찾이던게(?) 오늘은 한방에 찾아지네여 신기해라...

대체 저번엔 구글에서 무슨 키워드로 검색했길래 못 찾았지 ㅠㅠ)

뭐 어떤애들은 GDB소스를 뜯어고쳐서 해결하라는 -_- 애들도 있긴하던데...

이건 좀 무리... 무리...... 수정후 리컴파일은 복잡하자나.......

그래서 다음과 같은 방법을 찾음..

역시 길은 있다는.. 못찾을 뿐이지...

$gdb ./program
Reading symbols from /home/lowid/program ...done
(gdb) set print thread-events off
(gdb) run

이제 스레드 생성/종료 이벤트 알림 메세지가 더이상 나오지 않습니다 만세!

--------------------------------------------------------------------------------------------------

GDB에서 Thread 디버깅할때 ...... 더 자세한 내용은 역시 메뉴얼 페이지를 읽어보는것이 제일 낫다..

관심있다면 한번 읽어보세요

http://sourceware.org/gdb/current/onlinedocs/gdb/Threads.html

mmap 사용시 알아둘 사항 (버스오류)


mmap  이라하면... seek 같은 귀찬은짓 안하고 파일에서 메모리로 사상 받은다음에,

그 메모리를 조작하면 자동(?) 으로 그 (메모리에 변경된 내용)이 파일에 저장되는 참 편한 넘이져.

(꼭 파일 디스크립터가 있어야하는건 아니지만.......)

근데 문제는,,,저 int files의 파일/파일 디스크립터를 open 할떄 주의 해야하는게...

NAME  
       mmap - map pages of memory

SYNOPSIS
       #include <sys/mman.h>

       void *mmap(void *addr, size_t len, int prot, int flags. int fildes, off_t off);

mmap을 사용할때는 Target 이 되는 파일이 write할 길이보다 커야한다. 는거........

(그러므로 (아래서도 적었지만) 당연히 파일크기가 0가 되서는 안됨)

만약 그렇지 않다면 "버스 오류" 라는 메세지를 출력하고 프로그럄이 종료되어버리는 문제가 생긴다.

O_TRUNC 같은 옵션을 open 함수 사용할때 놓어서도 안되므로 주의 하도록 하자,

그니깐 정리하면.... "mmap은 쓸파일의 크기를 변경할수 없다" 는것..

버스 오류가 나면 참고하도록하자.

joinc에 주의사항하나 정도는 적혀있을듯 했었는데.. 없었던거 같다 (아님 내가 제대로 안읽었던가)

kldp에는 비슷한 내용의 글타래가 올라왔던거 같으니깐 구글에서 찾아보세염.

이걸 왜 했냐면......----------------------------

euckr로 변환된 문서를 utf8로 적용하려고, iconv를 쓰다보니...문제가 생겼다

버퍼 크기가 작어서(euckr로 잡으니) 로케일이 변경되다가 말았던것....

저번엔 utf8->euckr로 변경할때는 어짜피 파일크기가 utf8크기가 크니깐, 그냥 utf8파일 크기를 버퍼 크기로 줘도

상관없었는데, 문제는 그 반대의 상황이 문제였던것...

그래서 메모리 사상을 써봐서 해결해 볼까.......... 해서 mmap을 쓸려고 하니깐....

뭐야... 이것도 결국 버퍼 크기 알아야 하잖아... 챗...

그냥 iconv 함수 쓸때 euckr파일크기 * 2 (사실 1.5배만 해도 충분하다고 하지만) 로 최대 버퍼 잡아서 넘겨버렸다..

(http://kldp.org/node/68263)

잘 되네 변환..

이제 터미널에서 글자폭을 알아야 할 차레...

(뭐 정안되면 UTF8용으로 글자폭 알아보던 함수를 다시 한번 수정해야겠다.

지금 만든건 CJK(한글, 한문, 히라/가타카나)는 글자폭을 제대로 알아오는데.............

러시아어(...) 같은건 제대로 못얻어 와서....... wscol인가.. 그건 왜 눅스에 없을까...)

에이 걍 터미널에서 삽질하지 말고 gtk로 ...?..

FAT12과 FAT16의 부트레코드의 구성이 같은모양인가 보다

음.......; 전에 했던거지만
나중에 다시 찾아볼일이 있거나
필요한 사람이 있을까봐 다음을 기록한다

ORG 0x7c00

;Fat12 FileSystem BootRecord
;문자열(String)일 경우에 꼭 최고 바이트를 맞춰야하며,
;적기싫다면 공백으로(space) 채워넣어야만 한다
;그리고 이위에는 (BR을 유지하기 위해) 어떤 코드라도 들어가면 안된다
;(Vmware에서는 상관않는 모양이지만,Qemu에서, 이걸제대로 하지안으면 작동이 안된다.
;필히 밎의 jmp로 따로 만든 레이블로 점프하게 하자

 jmp register_init     ;Jump Boot Code
 db 0x90                ;Jump Boot Code Padding
 db "LolyComp"      ;OEM Name (String,MAX 8Byte)
 dw 512                 ;Bytes Per Sector
 db 1                     ;Sector Per Cluster
 dw 1                    ;Reserved Sector Count
 db 2                     ;Number of FATs
 dw 224                 ;Boot Entry Count
 dw 2880                ;Total Sector 12(16)
 db 0xf0                 ;Media 여기선 Floppy Disk,보통은 HDD면0 ,자세한건 링크를 참조..
 dw 9                    ;Fat Size 12(16)
 dw 18                   ;Sector Per Track
 dw 2                    ;Number of Heads
 dd 0                     ;Hidden Sector
 dd 2280                ;Total Sector
 db 0                     ;Driver Number
 db 0                     ;Reserved1
 db 0x29                ;Boot Signature
 dd 0xffffffff           ;Volume ID
 db "My_os_VOL "  ;Volume Lable (String 11 Byte)
 db "FAT12  "         ;File System Type (String 8 Byte)
 RESB 18               ;Padding (왜 채워주는건진 잘 모르겠다)

register_init:
;...여기서부터 레지스터 초기화 들어갑니다~


 자세한 설명은 다음 링크를 참조하면 답이 나옵니다
 FAT12 bootrecord랑 FAT16 bootrecord의 구조가 같으므로 FAT16을 참고...
 표(?)그림(?)을 보면 단박에 이해가 갈거라고 확신합니다.

http://network.hanb.co.kr/view.php?bi_id=1259


ORG 0x7c00의 정체..
왜 하마터면 0x7c00 인가? 하고 KLDP에 질문한적이 있는데.
그에 따라오는 답변은 아주 간단명료 했다.. 처음에 IBM아저씨들이 그렇게 정했으니까..
랍니다.. 꼭 이값을 쓰는 특별한 목적은 없는건지,아니면 이값자체가 그리 큰 의미가
없나봅니다. 뭐 책에도 나와있긴했지만(책 사기전이였거든요)

파일시스템.
FAT파일 시스템만 대충 봐둔게 좀 도움이 되네요..
문제는 뒤에는 몰라..겠지만... 이거 과연 스터디나 할수 있을지..

prev 1 2 3 next