Go to the first, previous, next, last section, table of contents.


Hints

ÈùÆ®

Check the `README' file, it often has useful information that does not appear anywhere else in the directory.

`README' ÆÄÀÏÀ» üũÇضó. ÀÌ ÆÄÀÏÀº µð·ºÅ丮³» ±× ¹ÛÀÇ ³»¿ë¿¡¼­´Â º¸ÀÌÁö ¾Ê´Â À¯¿ëÇÑ Á¤º¸¸¦ °¡Áö°í ÀÖ´Ù.

½ÃÀÛÇϱâ

GDB is a large and complicated program, and if you first starting to work on it, it can be hard to know where to start. Fortunately, if you know how to go about it, there are ways to figure out what is going on.

GDB´Â Å©°í º¹ÀâÇÑ ÇÁ·Î±×·¥ÀÌ¸ç ¸¸ÀÏ GDB¸¦ ½ÃÀÛÇÑ´Ù¸é, ¾îµð¼­ ½ÃÀÛÇؾßÇÒÁö ¾Ë±â ¾î·Æ´Ù. ¿îÁÁ°Ôµµ, ¸¸ÀÏ ¿©·¯ºÐÀÌ GDB¸¦ ½ÃÀÛÇÏ´Â ¹æ¹ýÀ» ¾È´Ù¸é, ¹«¾ùÀ» Çسª°¡¾ß ÇÒÁö ÀÌÇØÇϱâ À§ÇÑ ¹æ¹ýÀÌ ÀÖ´Ù.

This manual, the GDB Internals manual, has information which applies generally to many parts of GDB.

GDB Internal manualÀº GDBÀÇ ¸¹Àº ºÎºÐ¿¡ Àû¿ëµÇ´Â Á¤º¸°¡ ÀÖ´Ù.

Information about particular functions or data structures are located in comments with those functions or data structures. If you run across a function or a global variable which does not have a comment correctly explaining what is does, this can be thought of as a bug in GDB; feel free to submit a bug report, with a suggested comment if you can figure out what the comment should say. If you find a comment which is actually wrong, be especially sure to report that.

Ưº°ÇÑ ÇÔ¼ö³ª µ¥ÀÌÅÍ ±¸Á¶¿¡ ´ëÇÑ Á¤º¸´Â ÀÌ ÇÔ¼öµéÀ̳ª µ¥ÀÌÅÍ ±¸Á¶ °ü·Ã ÁÖ¼®¿¡ ÀÖ´Ù. ¸¸ÀÏ ¹«¾ùÀ» ÇÏ´ÂÁö¿¡ ´ëÇÑ Á¤È®ÇÑ ÁÖ¼®À» °¡Áö°í ÀÖÁö ¾Ê´Â ÇÔ¼ö³ª Àü¿ª º¯¼ö¸¦ ¿ì¿¬È÷ ¸¸³­´Ù¸é, ÀÌ°ÍÀº GDB³» ¹ö±×·Î »ý°¢ÇÒ¼ö ÀÖ´Ù; ¸¸ÀÏ ÁÖ¼®ÀÌ ¸»Çϴ°ÍÀÌ ¹«¾ùÀÎÁö¸¦ ÀÌÇØÇß´Ù¸é ÁÖ¼®°ú ÇÔ²² ¹ö±× ¸®Æ÷Æ®¸¦ ºÎ´ã¾øÀÌ º¸³»¶ó. ¸¸ÀÏ À߸øµÈ ÁÖ¼®À» ¹ß°ßÇÑ´Ù¸é, ƯÈ÷ ÁÖ¼® º¸°í¸¦ È®½ÇÈ÷ Çضó.

Comments explaining the function of macros defined in host, target, or native dependent files can be in several places. Sometimes they are repeated every place the macro is defined. Sometimes they are where the macro is used. Sometimes there is a header file which supplies a default definition of the macro, and the comment is there. This manual also documents all the available macros.

È£½ºÆ®, Ÿ°Ù ¶Ç´Â native ÀÇÁ¸ÀûÀÎ ÆÄÀϵ鿡 Á¤ÀÇµÈ ¸ÅÅ©·Î ÇÔ¼öµéÀ» ¼³¸íÇÏ´Â ÁÖ¼®Àº ¸î¸î Àå¼Ò¿¡ ÀÖÀ»¼ö ÀÖ´Ù. °¡²û À̰͵éÀº ¸ÅÅ©·Î°¡ Á¤ÀÇµÈ ¸ðµç Àå¼Ò¿¡¼­ ¹Ýº¹µÈ´Ù. °¡²û ¸ÅÅ©·Î°¡ »ó¿ëµÈ°÷¿¡µµ ÀÖ´Ù. °¡²û ¸ÅÅ©·ÎÀÇ ±âº» Á¤ÀǸ¦ ´ë½ÅÇÏ´Â Çì´õ ÆÄÀÏÀÌ ÀÕÀ¸¸ç ÄÚ¸àÆ®°¡ ÀÖ´Ù. ÀÌ ¸Å´º¾ó ¿ª½Ã ÀÌ¿ëÇÒ¼ö ÀÖ´Â ¸ÅÅ©·Î ¸ðµÎ¸¦ ¹®¼­È­Çß´Ù.

Start with the header files. Once you have some idea of how GDB's internal symbol tables are stored (see `symtab.h', `gdbtypes.h'), you will find it much easier to understand the code which uses and creates those symbol tables.

Çì´õ ÆÄÀÏ·Î ½ÃÀÛÇضó. ÀÏ´Ü ¿©·¯ºÐÀÌ GDB ³»ºÎ ½Éº¼ Å×À̺íÀÌ ÀúÀå(`symtab.h', `gdbtypes.h')µÇ´Â ¹æ¹ý¿¡ ´ëÇÑ ¸î°¡Áö idea¸¦ °¡Áö°í ÀÖ´Ù¸é, »ç¿ëµÈ Äڵ带 ÀÌÇØÇÏ°í ÀÌ ½Éº¼ Å×À̺íÀ» ¸¸µå´Â°ÍÀÌ ½±´Ù´Â°ÍÀ» ¹ß°ßÇÒ °ÍÀÌ´Ù.

You may wish to process the information you are getting somehow, to enhance your understanding of it. Summarize it, translate it to another language, add some (perhaps trivial or non-useful) feature to GDB, use the code to predict what a test case would do and write the test case and verify your prediction, etc. If you are reading code and your eyes are starting to glaze over, this is a sign you need to use a more active approach.

¿©·¯ºÐÀº ¿©·¯ºÐÀÌ ÀÌÇØÇÏ°í ÀÖ´Â °ÍÀ» °­È­Çϱâ À§ÇØ °¡Áö°í ÀÖ´Â Á¤º¸¸¦ ó¸®ÇÏ±æ ¿øÇÒÁö ¸ð¸¥´Ù. ¿ä¾àÇؼ­, ±×°ÍÀ» ´Ù¸¥ ¾ð¾î·Î ¹ø¿ªÇÏ°í, GDB¿¡ ¸î¸î Ư¡À» Ãß°¡ÇÏ°í, Å×½ºÆ® °æ¿ì°¡ ¹«¾ùÀÎÁö ¿¹»óµÇ´Â Äڵ带 »ç¿ëÇÏ°í, Å×½ºÆ® ÄÉÀ̽º¸¦ Àû°í, ¿¹»óÀ» °Ë»çÇضó. ¸¸ÀÏ Äڵ带 ÀÐ°í ´«ÀÌ Èå·ÁÁö±â ½ÃÀÛÇÑ´Ù¸é, ÀÌ°ÍÀº ´õ Àû±ØÀûÀÎ Á¢±ÙÀ» »ç¿ëÇÒ ÇÊ¿ä°¡ Àִٴ ǥ½ÃÀÌ´Ù.

Once you have a part of GDB to start with, you can find more specifically the part you are looking for by stepping through each function with the next command. Do not use step or you will quickly get distracted; when the function you are stepping through calls another function try only to get a big-picture understanding (perhaps using the comment at the beginning of the function being called) of what it does. This way you can identify which of the functions being called by the function you are stepping through is the one which you are interested in. You may need to examine the data structures generated at each stage, with reference to the comments in the header files explaining what the data structures are supposed to look like.

ÀÏ´Ü ½ÃÀ۽à GDBÀÇ ÀϺθ¦ °¡Áö°í ÀÖ´Ù¸é, ¿©·¯ºÐÀº next ¸í·É¾î·Î °¢ ÇÔ¼ö¸¦ stepÇϸç, ã°íÀÚ ÇÏ´Â ºÎºÐÀ» ´õ ¹ß°ßÇÒ¼ö ÀÖ´Ù. stepÀ» »ç¿ëÇÏÁö ¸¶¶ó. ±×·¸Áö ¾ÊÀ¸¸é ¿©·¯ºÐÀº ¾îÁö·¯¿ï °ÍÀÌ´Ù; ´Ù¸¥ ÇÔ¼ö¸¦ È£ÃâÇÏ¿© stepping ÇÏ´Â ÇÔ¼öµéÀº ÀÌ ÇÔ¼öµéÀÌ ¹«¾ùÀ» ÇÏ´ÂÁö¸¦ ÀÌÇØ(È£ÃâµÇ´Â ÇÔ¼öÀÇ ½ÃÀ۽à ÁÖ¼®À» »ç¿ëÇÏ¿©)ÇÒ¼ö ÀÖµµ·Ï Ä¿´Ù¶õ ±×¸²À» °¡Áöµµ·Ï ÇØÁØ´Ù. ¿©·¯ºÐÀÌ steppingÇÏ´Â ÇÔ¼ö¿¡ ÀÇÇØ È£ÃâµÇ´Â ÇÔ¼ö°¡ ¾î´À°ÍÀÎÁö ÀνÄÇÒ¼ö ÀÖ´Â ¹æ¹ýÀº ¿©·¯ºÎÀÌ Èï¹Ì·Î¿öÇÏ´Â °ÍÀÌ´Ù. ¿©·¯ºÐÀº µ¥ÀÌÅÍ ±¸Á¶¸¦ ¼³¸íÇÏ´Â Çì´õ ÆÄÀϳ» ÁÖ¼®¿¡ ´ëÇÑ ÂüÁ¶¿Í ÇÔ²² °¢ ´Ü°è¿¡¼­ ¸¸µé¾îÁö´Â µ¥ÀÌÅÍ ±¸Á¶¸¦ °Ë»çÇÒ ÇÊ¿ä°¡ ÀÖ´Ù.

Of course, this same technique can be used if you are just reading the code, rather than actually stepping through it. The same general principle applies--when the code you are looking at calls something else, just try to understand generally what the code being called does, rather than worrying about all its details.

¹°·Ð, ÀÌ ±â¼úÀº ¸¸ÀÏ ¿©·¯ºÐÀÌ Äڵ带 Àд´ٸé steppingÇÏ´Â °ÍÀÌ»óÀ¸·Î »ç¿ëµÉ¼ö ÀÖ´Ù. ÀϹÝÀûÀÎ ¿ø¸®°¡ Àû¿ëµÈ´Ù.--¿©·¯ºÐÀÌ Ã£´Â Äڵ尡 ¹«¾ùÀ» È£ÃâÇÒ¶§, ¼¼ºÎÀûÀÎ ¸ðµç°Í¿¡ ´ëÇØ °ÆÁ¤Çϱ⠺¸´Ù´Â È£ÃâµÈ Äڵ尡 ¹«¾ùÀ» ÇÏ´ÂÁö ÀÌÇØÇϵµ·Ï ½ÃµµÇضó.

A good place to start when tracking down some particular area is with a command which invokes that feature. Suppose you want to know how single-stepping works. As a GDB user, you know that the step command invokes single-stepping. The command is invoked via command tables (see `command.h'); by convention the function which actually performs the command is formed by taking the name of the command and adding `_command', or in the case of an info subcommand, `_info'. For example, the step command invokes the step_command function and the info display command invokes display_info. When this convention is not followed, you might have to use grep or M-x tags-search in emacs, or run GDB on itself and set a breakpoint in execute_command.

¸î¸î Ưº° ¿µ¿ªÀ» ¦i¾Æ°¥¶§ ½ÃÀÛÇÒ ÁÁÀº À§Ä¡´Â ±× Ư¡À» È£ÃâÇÏ´Â ¸í·É¾î¿¡¼­ºÎÅÍÀÌ´Ù. ¿©·¯ºÐÀÌ ´ÜÀÏ-stepping ÀÛ¾÷À» ÇÏ´Â ¹æ¹ýÀ» ¾Ë±â¸¦ ¿øÇÑ´Ù°í °¡Á¤ÇÏÀÚ. GDB »ç¿ëÀڷνá, ¿©·¯ºÐÀº ´ÜÀÏ steppingÀ» À§ÇØ step ¸í·É¾î¸¦ ¾Ë¾Æ¾ß ÇÑ´Ù. ¸í·É¾î´Â ¸í·É¾î Å×À̺í(`command.h'¸¦ ÂüÁ¶Çضó.)À» ÅëÇØ È£ÃâµÈ´Ù.; ¸í·É¾î¸¦ ½ÇÇàÇÏ´Â ÇÔ¼ö´Â ¸í·É¾î À̸§°ú `_command'³ª info ¸í·É¾îÀÇ ÇÏÀ§ ¸í·É¾î °æ¿ì·Î `_info'·Î ±¸¼ºµÇ¾î ÀÖ´Ù. ¿¹¸¦ µé¾î, step ¸í·É¾î´Â step_command ÇÔ¼ö¸¦ È£ÃâÇÏ°í info display ¸í·É¾î´Â display_info¸¦ È£ÃâÇÑ´Ù. ÀÌ ±Ô¾àÀÌ ¼º¸³µÇÁö ¾ÊÀ»¶§, ¿©·¯ºÐÀº grepÀ̳ª emacs¿¡¼­ M-x tags-search, ¶Ç´Â GDB¸¦ µ¹¸®°í execute_command¿¡ breakpoint¸¦ ¼³Á¤ÇÑ´Ù.

If all of the above fail, it may be appropriate to ask for information on bug-gdb. But never post a generic question like "I was wondering if anyone could give me some tips about understanding GDB"---if we had some magic secret we would put it in this manual. Suggestions for improving the manual are always welcome, of course.

¸¸ÀÏ À§ÀÇ ¸ðµç°ÍÀÌ ´Ù ½ÇÆÐÇÑ´Ù¸é, bug-gdb¿¡ Á¤º¸¸¦ ¿ä±¸Çضó. ±×·¯³ª "´©°¡ GDB¸¦ ÀÌÇØÇÒ¼ö ÀÖ´Â ÆÁÀ» ³ª¿¡°Ô ÁÙÁö ±Ã±ÝÇÏ´Ù"°°Àº ÀϹÝÀû Áú¹®Àº ÇÏÁö ¸¶¶ó. -- ¸¸ÀÏ ¿ì¸®°¡ Ä¿´Ù¶õ ºñ¹ÐÀ» °¡Áö°í ÀÖ´Ù¸é, ÀÌ ¸Å´º¾ó¿¡ ³ÖÀ» °ÍÀÌ´Ù. ¹°·Ð, ¸Å´º¾óÀ» °³¼±ÇÏ´Â ÀÛ¾÷Àº ¾ðÁ¦³ª ȯ¿µÇÑ´Ù.

Debugging GDB with itself

GDB µð¹ö±ëÇϱâ

If GDB is limping on your machine, this is the preferred way to get it fully functional. Be warned that in some ancient Unix systems, like Ultrix 4.2, a program can't be running in one process while it is being debugged in another. Rather than typing the command ./gdb ./gdb, which works on Suns and such, you can copy `gdb' to `gdb2' and then type ./gdb ./gdb2.

¸¸ÀÏ GDB°¡ ¸Ó½Å¿¡¼­ ´À¸®´Ù¸é, ¿ÏÀüÈ÷ ±â´ÉÀûÀ¸·Î °¡Áö´Â°ÍÀÌ ´õ ÁÁÀº ¹æ¹ýÀÌ´Ù. Ultrix 4.2 °°Àº ¸î¸î ¿¹Àü Unix system¿¡¼­, ÇÁ·Î¼¼½º´Â ÇÑ ÇÁ·Î¼¼¼­¿¡¼­ µ¹¾Æ°¡Áö ¾Ê´Â ¹Ý¸é ´Ù¸¥ ÇÁ·Î¼¼¸£·Î´Â µð¹ö±ëÀÌ µÈ´Ù. ¸í·É¾î ./gdb ./gdb¸¦ ŸÀÌÇÎÇϴ°ͺ¸´Ù´Â ¿©·¯ºÐÀº `gdb'¸¦ `gdb2'·Î º¹»çÇÏ°í ./gdb ./gdb2 °°ÀÌ Å¸ÀÌÇÎÇضó.

When you run GDB in the GDB source directory, it will read a `.gdbinit' file that sets up some simple things to make debugging gdb easier. The info command, when executed without a subcommand in a GDB being debugged by gdb, will pop you back up to the top level gdb. See `.gdbinit' for details.

¿©·¯ºÐÀÌ GDB ¼Ò½º µð·ºÅ丮¿¡¼­ GDB¸¦ µ¹¸°´Ù¸é, gdb¸¦ ½±°Ô µð¹ö±ëÇϵµ·Ï ¸¸µé±â À§ÇØ ¸î¸î °£´ÜÇÑ °ÍÀ» ¼³Á¤ÇÏ´Â `.gdbinit' ÆÄÀÏÀ» Àд´Ù. gdb°¡ µð¹ö±ëÇÏ´Â GDBÀÇ ÇÏÀ§ ¸í·É¾î°¡ ¾øÀÌ ½ÇÇàµÉ¶§, info ¸í·É¾î´Â gdb ÃÖ»óÀ§ ·¹º§·Î °¡µµ·Ï ÇÑ´Ù. ¼¼ºÎ»çÇ×À» À§ÇØ `.gdbinit'¸¦ ÂüÁ¶Çضó.

If you use emacs, you will probably want to do a make TAGS after you configure your distribution; this will put the machine dependent routines for your local machine where they will be accessed first by M-.

¸¸ÀÏ ¿©·¯ºÐÀÌ emacs¸¦ »ç¿ëÇÑ´Ù¸é, ¹èÆ÷À» ¼³Á¤ÇÑÈÄ make TAGS¸¦ ÇÏ±æ ¿øÇÒ °ÍÀÌ´Ù.; ÀÌ°ÍÀº M-.°¡ ¿ì¼± Á¢¼ÓÇÏ´Â ·ÎÄà ¸Ó½ÅÀ» À§ÇÑ ¸Ó½Å µ¶¸³ÀûÀÎ ·çƾÀ» ³õ´Â´Ù.

Also, make sure that you've either compiled GDB with your local cc, or have run fixincludes if you are compiling with gcc.

¶ÇÇÑ, ·ÎÄà cc¸¦ °¡Áö°í GDB¸¦ ÄÄÆÄÀÏÇÏ¿´´ÂÁö È®½ÇÈ÷ Çضó. ±×·¸Áö ¾Ê°í, gcc¸¦ °¡Áö°í ÄÄÆÄÀÏ Çß´Ù¸é fixincludes¸¦ µ¹·Á¶ó.

Submitting Patches

Thanks for thinking of offering your changes back to the community of GDB users. In general we like to get well designed enhancements. Thanks also for checking in advance about the best way to transfer the changes.

GDB »ç¿ëÀÚ Ä¿¹Â´ÏƼ¿¡ ¿©·¯ºÐÀÇ º¯°æ»çÇ×µéÀ» Á¦°øÇÒ·Á´Â »ý°¢¿¡ °¨»çÇÑ´Ù. ÀϹÝÀûÀ¸·Î ¿ì¸®´Â °­È­µÇ¾î Àß Á¤ÀǵȰÍÀ» ¿øÇÑ´Ù. ¶ÇÇÑ º¯°æ»çÇ×À» º¸³»ÁÖ´Â °¡Àå ÁÁÀº ¹æ¹ýÀ» È®ÀÎÇÏ¸é ¹Ì¸® °¨»çÇÏ°Ú´Ù.

The GDB maintainers will only install "cleanly designed" patches. This manual summarizes what we believe to be clean design for GDB.

GDB ¸ÞÀÎÅ×À̳ʵéÀº "¸í¹éÈ÷ µðÀÚÀεÈ" ÆÐÄ¡µé¸¸ ÀνºÅçÇÑ´Ù. ÀÌ ¸Å´º¾óÀº ¿ì¸®°¡ GDB¸¦ À§ÇÑ µðÀÚÀÎÀ» ¸í¹éÈ÷ Çϵµ·Ï ¹Ï´Â´Ù°í ¿ä¾àÇؼ­ ¸»ÇÑ´Ù.

If the maintainers don't have time to put the patch in when it arrives, or if there is any question about a patch, it goes into a large queue with everyone else's patches and bug reports.

¸¸ÀÏ ¸ÞÀÎÅ×À̳ʰ¡ µµÂøÇÑ ÆÐÄ¡¸¦ ³ÖÀ» ½Ã°£ÀÌ ¾ø´Ù¸é ¶Ç´Â ÆÐÄ¡¿¡ °üÇÑ Àǹ®Á¡ÀÌ ÀÖ´Ù¸é, ÀÌ ÆÐÄ¡´Â ´Ù¸¥ ¸ðµç »ç¶÷µéÀÇ ÆÐÄ¡¿Í ¹ö±× ¸®Æ÷Æ®¿Í ÇÔ²² Ä¿´Ù¶õ Å¥·Î º¸³»Áø´Ù.

The legal issue is that to incorporate substantial changes requires a copyright assignment from you and/or your employer, granting ownership of the changes to the Free Software Foundation. You can get the standard documents for doing this by sending mail to gnu@gnu.org and asking for it. We recommend that people write in "All programs owned by the Free Software Foundation" as "NAME OF PROGRAM", so that changes in many programs (not just GDB, but GAS, Emacs, GCC, etc) can be contributed with only one piece of legalese pushed through the bureacracy and filed with the FSF. We can't start merging changes until this paperwork is received by the FSF (their rules, which we follow since we maintain it for them).

Technically, the easiest way to receive changes is to receive each feature as a small context diff or unidiff, suitable for patch. Each message sent to me should include the changes to C code and header files for a single feature, plus `ChangeLog' entries for each directory where files were modified, and diffs for any changes needed to the manuals (`gdb/doc/gdb.texinfo' or `gdb/doc/gdbint.texinfo'). If there are a lot of changes for a single feature, they can be split down into multiple messages.

±â¼úÀûÀ¸·Î, º¯°æ»çÇ×À» ¹Þ´Â °¡Àå ½¬¿î ¹æ¹ýÀº patch°°ÀÌ ,Á¶±×¸¸ ¹®¸Æ diff³ª unidiff·Î½á °¢ Ư¡À» ¹Þ´Â°ÍÀÌ´Ù. ³ª¿¡°Ô ¿À´Â °¢ ¸Þ¼¼Áö´Â ´ÜÀÏ Æ¯Â¡À» À§ÇÑ C ÄÚµå¿Í Çì´õ ÆÄÀϵ鿡 ´ëÇÑ º¯°æ»çÇ×À» Æ÷ÇÔÇÏ¿©¾ß Çϸç, ±×¿Ü ¾î¶² ÆÄÀϵéÀÌ ¼öÁ¤µÇ¾ú´ÂÁö¸¦ À§ÇØ `ChangeLog'¸¦, ±×¸®°í ¸Å´º¾ó¿¡ ÇÊ¿äÇÑ º¯°æ»çÇ×µéÀÇ diff¸¦ Æ÷ÇÔÇØ¾ß ÇÑ´Ù.(`gdb/doc/gdb.texinfo' ³ª `gdb/doc/gdbint.texinfo') ¸¸ÀÏ ´ÜÀÏ Æ¯Â¡À» À§ÇÑ ¸¹Àº º¯°æ»çÇ×µéÀÌ ÀÕ´Ù¸é, ´ÙÁß ¸Þ¼¼Áö·Î ³ª´­¼ö ÀÖ´Ù.

In this way, if we read and like the feature, we can add it to the sources with a single patch command, do some testing, and check it in. If you leave out the `ChangeLog', we have to write one. If you leave out the doc, we have to puzzle out what needs documenting. Etc., etc.

ÀÌ·± ¹æ¹ýÀ¸·Î, ¸¸ÀÏ ¿ì¸®°¡ Ư¡À» Àаí ÁÁ¾ÆÇÑ´Ù¸é ´ÜÀÏ ÆÐÄ¡ ¸í·É¾î°¡ ÀÖ´Â ¼Ò½º¿¡ Ãß°¡ÇÒ¼ö ÀÖ°í Å×½ºÆ®¸¦ ÇÏ°í, °Ë»çÇÒ¼ö ÀÖ´Ù. ¸¸ÀÏ ¿©·¯ºÐÀÌ `ChangeLog'¿¡ ³²±ä´Ù¸é, °Å±â¿¡ ¾´´Ù. ¸¸ÀÏ ¿©·¯ºÐÀÌ docÀ» ³²±ä´Ù¸é, ¿ì¸®´Â ¹®¼­È­°¡ ÇÊ¿äÇÑ °ÍÀ» ¾Ë¾Æ¾ß ÇÑ´Ù. µîµî..

The reason to send each change in a separate message is that we will not install some of the changes. They'll be returned to you with questions or comments. If we're doing our job correctly, the message back to you will say what you have to fix in order to make the change acceptable. The reason to have separate messages for separate features is so that the acceptable changes can be installed while one or more changes are being reworked. If multiple features are sent in a single message, we tend to not put in the effort to sort out the acceptable changes from the unacceptable, so none of the features get installed until all are acceptable.

ºÐ¸®µÈ ¸Þ¼¼Áö¿¡ °¢ º¯°æ»çÇ×À» º¸³»´Â ÀÌÀ¯´Â ¿ì¸®´Â ¸î¸î º¯°æ»çÇ×µéÀ» ÀνºÅçÇÏÁö ¾Ê±â ¶§¹®ÀÌ´Ù. Áú¹®À̳ª ÄÚ¸àÆ®¸¦ °¡Áö°í ¿©·¯ºÐ¿¡°Ô µÇµ¹¾Æ ¿Â´Ù. ¸¸ÀÏ ¿ì¸®°¡ Á¤È®È÷ ¿ì¸®ÀÏÀ» ÇÑ´Ù¸é, ¿©·¯ºÐ¿¡°Ô µ¹¾Æ°¡´Â ¸Þ¼¼Áö´Â º¯°æ »çÇ×À» ¹Þ¾ÆµéÀϼö ÀÖµµ·Ï ¸¸µé±â À§ÇØ °íÃÆ´Ù´Â ¸»ÀÌ´Ù. °¢ Ư¡À» À§ÇØ ºÐ¸®µÈ ¸Þ¼¼Áö¸¦ °¡Áö´Â ÀÌÀ¯´Â ¹ÞÀº º¯°æ»çÇ×µéÀº Çϳª³ª ±× ÀÌ»óÀÇ º¯°æ»çÇ×µéÀÌ ´Ù½Ã ÀÛ¾÷µÇ´Â µ¿¾È ¼³Ä¡µÈ´Ù. ¸¸ÀÏ ¿©·¯ Ư¡µéÀÌ ´ÜÀÏ ¸Þ¼¼Áö·Î º¸³»Áø´Ù¸é, ¿ì¸®´Â ¹Þ¾ÆµéÀϼö ¾ø´Â º¯°æ»çÇ×µéÀ» ¹Þ¾ÆµéÀ̵µ·Ï ³ë·ÂÇÏÁö ¾Ê´Â´Ù. ±×·¡¼­ Ư¡Áß ¾î¶²°Íµµ ¹Þ¾ÆµéÀ϶§±îÁö´Â ¼³Ä¡µÇÁö ¾Ê´Â´Ù.

If this sounds painful or authoritarian, well, it is. But we get a lot of bug reports and a lot of patches, and many of them don't get installed because we don't have the time to finish the job that the bug reporter or the contributor could have done. Patches that arrive complete, working, and well designed, tend to get installed on the day they arrive. The others go into a queue and get installed as time permits, which, since the maintainers have many demands to meet, may not be for quite some time.

¸¸ÀÏ ÀÌ°ÍÀº °íÅ뽺·´°Å³ª ±ÇÀ§ÀûÀΰÍó·³ µé¸°´Ù¸é, ±×·²Áöµµ ¸ð¸¥´Ù. ±×·¯³ª ¸¹Àº ¹ö±× ¸®Æ÷Æ®¿Í ¸¹Àº ÆÐÄ¡¸¦ ¿øÇÑ´Ù. ±×¸®°í ±×°Íµé ´ëºÎºÐÀº ¿ì¸®°¡ ¹ö±× ¸®Æ÷Æ®³ª ±â¿©ÀÚ°¡ ÇÒ¼ö ÀÖ´Â ÀÛ¾÷À» ³¡³¾ ½Ã°£À» °¡Áö°í ÀÖÁö ¾Ê±â ¶§¹®¿¡ ¼³Ä¡ÇÏÁö ¾Ê´Â´Ù. ¿ÏÀüÈ÷ ÀÛ¾÷ÇÏ°í Àß µðÀÚÀÎµÈ ÆÐÄ¡´Â µµÂøÇÏÀÚ¸¶ÀÚ ¼³Ä¡¸¦ ÇÑ´Ù. ´Ù¸¥°ÍµéÀº Å¥·Î °¡°í ½Ã°£ÀÌ ³ª¸é ¼³Ä¡¸¦ ÇÑ´Ù. ¿Ö³ÄÇÏ¸é ¸ÞÀÎÅ×À̳ʵéÀº ÃæÁ·½Ãų ¸¹Àº Á¶°ÇÀ» °¡Áö±â ¶§¹®¿¡, ÃæºÐÇÑ ½Ã°£À» °¡ÁöÁö ¸øÇÒ °ÍÀÌ´Ù.

Please send patches directly to the GDB maintainers.

the GDB maintainers¿¡ Á÷Á¢ ÆÐÄ¡¸¦ º¸³»¶ó.

Obsolete Conditionals

±¸½Ä Á¶°Çµé

Fragments of old code in GDB sometimes reference or set the following configuration macros. They should not be used by new code, and old uses should be removed as those parts of the debugger are otherwise touched.

GDB¿¡¼­ ¿¹Àü ÄÚµå ÇÁ·¹±×¸ÕÆ®¸¦ ÂüÁ¶Çϰųª ´ÙÀ½ ¼³Á¤ ¸ÅÅ©·Î¸¦ ¼³Á¤Çضó. À̰͵éÀº »õ Äڵ忡¼­´Â »ç¿ëµÇ¾î¼­´Â ¾ÈµÇ¸ç ¿¹Àü »ç¿ëÀº µð¹ö°ÅÀÇ ÀÌ ºÎºÐµé¿¡¼­ Á¦°ÅµÇ¾î¾ß ÇÑ´Ù.

STACK_END_ADDR
This macro used to define where the end of the stack appeared, for use in interpreting core file formats that don't record this address in the core file itself. This information is now configured in BFD, and GDB gets the info portably from there. The values in GDB's configuration files should be moved into BFD configuration files (if needed there), and deleted from all of GDB's config files. Any `foo-xdep.c' file that references STACK_END_ADDR is so old that it has never been converted to use BFD. Now that's old!

ÀÌ ¸ÅÅ©·Î´Â ½ºÅà ³¡ÀÌ ³ªÅ¸³ª´Â °÷¿¡ Á¤ÀÇÇϱâ À§ÇØ »ç¿ëµÇ¸ç ÄÚ¾îÆÄÀÏ ÀÚü¿¡ ÀÌ ÁÖ¼Ò¸¦ ±â·ÏÇÏÁö ¾Ê´Â ÄÚ¾î ÆÄÀÏ Çü½Ä Çؼ®½Ã »ç¿ëµÈ´Ù. ÀÌ Çü½ÄÀº BFD¿¡ ¼³Á¤µÇ¸ç GDB´Â °Å±â¼­ ¾Æ¸¶µµ Á¤º¸¸¦ °¡Á®¿Â´Ù. GDB ¼³Á¤ ÆÄÀϳ» °ªµéÀº BFD ¼³Á¤ ÆÄÀÏ(ÇÊ¿äÇÏ´Ù¸é)·Î À̵¿µÇ¾î¾ß Çϸç GDBÀÇ ¼³Á¤ÆÄÀÏ ¸ðµÎ¿¡¼­ Á¦°ÅµÇ¾î¾ß ÇÑ´Ù.

PYRAMID_CONTROL_FRAME_DEBUGGING
pyr-xdep.c
PYRAMID_CORE
pyr-xdep.c
PYRAMID_PTRACE
pyr-xdep.c
REG_STACK_SEGMENT
exec.c


Go to the first, previous, next, last section, table of contents.