home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / gnu / gdb / bug / 913 < prev    next >
Encoding:
Text File  |  1992-07-28  |  5.2 KB  |  126 lines
  1. Newsgroups: gnu.gdb.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!eued50.tuwien.ac.at!tuppa
  3. From: tuppa@eued50.tuwien.ac.at (Walter Tuppa)
  4. Subject: Re: Debug register use for ISC 2.2.1 (Sys v/386 R3.2)
  5. Message-ID: <TUPPA.92Jul28100919@eued50.tuwien.ac.at>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: Technical University of Vienna
  8. References: tuppa@eued50.tuwien.ac.at (Walter Tuppa)
  9. Distribution: gnu
  10. Date: Tue, 28 Jul 1992 09:09:19 GMT
  11. Approved: bug-gdb@prep.ai.mit.edu
  12. Lines: 112
  13.  
  14. Hello,
  15.  
  16. it's quite nice to use an accesspoint to watch for NULL pointer accesses, but
  17. there is a much easier way on Interactive Unix. You just write a load-file
  18. for the linker, which is mentioned on the link command line.
  19.  
  20. source of file <ldfile>
  21. =========================== cut here =========================================
  22. /* Specify the memory section of valid memory  [.MEMORY].   We  will */
  23. /* allow  addresses  from  4 megabytes (0x400000) to two gigabytes   */
  24. /* (0x80000000), we will put the text and data up at four  megabytes */
  25. /* (0x400000).                                                       */
  26. /* the second memory region is for the shared libaries like -lc_s or */
  27. /* the X-Window system. This region uses all the 0xA.. and 0xB..     */
  28. /* memory region, e.g. -lc_s uses 0xA0000000 for code (shared) and   */
  29. /* 0xA04000000 for data (private to process).                        */
  30.  
  31. MEMORY  {
  32.     user:   org = 0x00400000, len = 0x7FBFFFFF
  33.     shared: org = 0xA0000000, len = 0x1FFFFFFF
  34.     }
  35.  
  36. /* Define the sections of the object file.                           */
  37.  
  38. SECTIONS {
  39.  
  40.     /* The following sets up two  sections.   The  first  output */
  41.     /* section  is  called  ".init" and includes all the ".init" */
  42.     /* sections in the  input  files.   The  second  section  is */
  43.     /* called  ".text"  and includes all the ".text" sections in */
  44.     /* the input files.  The ".init" section  will  be  given  a */
  45.     /* starting address of four megabytes (0x400000).   It  will */
  46.     /* be  placed  in the object file at the  next  4K byte file */
  47.     /* position.  Unfortunately, there is no  way  to  determine */
  48.     /* the  header size, hence we must waste most of the zero'th */
  49.     /* block.  Further it appears that we can  not  tell  it  to */
  50.     /* page  in  from  the  next file block, but rather from the */
  51.     /* next page.  Hence we  unfortunately  waste  most  of  the */
  52.     /* page.   It appears that the loader has some bugs  dealing */
  53.     /* with  the  processing  of   ifiles.    Putting   in   the */
  54.     /* initialization  of  space to 0x9090 (nop's) seems to have */
  55.     /* helped in causing the .text section to go  to  the  right */
  56.     /* spot  in  the output file when there is no .init section. */
  57.     /* The ".text"  section  will  be  given a starting address  */
  58.     /* of the  address  immediately  after the  ".init" section. */
  59.     /* Likewise it will be put in the file immediately after the */
  60.     /* ".init" section.                                          */
  61.  
  62.     GROUP BIND (0x400000) BLOCK (0x1000) : {
  63.         .init : {} = 0x9090
  64.         .text : {} = 0x9090
  65.         } > user
  66.  
  67.     /* The following sets  up  two  more  sections.   The  third */
  68.     /* output  section  is  called  ".data" and includes all the */
  69.     /* ".data" sections in the input files.  The fourth  section */
  70.     /* is  called ".bss" and sums all the ".bss" sections in the */
  71.     /* input  files.   The  ".data"  section  will  be  given  a */
  72.     /* starting   address   of  the  next  region  alignment  (4 */
  73.     /* megabyte) address after the current  location  (the  last */
  74.     /* address  of  the  ".text" segment).  It will be placed in */
  75.     /* the object file at the next  page  alignment  (4K  bytes) */
  76.     /* file  position  after the current file position (the last */
  77.     /* position of the ".text" segment).  Again, I suspect  that */
  78.     /* it  is  necessary  to  be on a page boundary and not on a */
  79.     /* file block boundary, causing a lot  of  the  page  to  be */
  80.     /* wasted.   The  ".bss"  section  will  be given a starting */
  81.     /* address  of  the  address  of  the  end  of  the  ".data" */
  82.     /* section.  Likewise it will be put in the file immediately */
  83.     /* after the ".data" section.  However, it will not actually */
  84.     /* take any space.                                           */
  85.  
  86.     GROUP BIND (((SIZEOF (.text) + 0x3FFFFF) &
  87.       (~0x3FFFFF)) + 0x400000) BLOCK (0x1000) : {
  88.         .data : {}
  89.         .bss :  {}
  90.         } > user
  91.  
  92.     /* end of description                                        */
  93.     }
  94. =========================== cut here =========================================
  95.  
  96.  
  97. as a test, use this little program:
  98.  
  99. main()
  100. {
  101.     int *a = 0;
  102.     *a = 0;
  103. }
  104.  
  105. this should now produce a Segmentation fault (core dumped).
  106. [this can be used with cc and gcc]
  107.  
  108. I think this method is much better, because it will generate a Segmentation
  109. fault for any memory access in the first 4 MegaBytes (even if the NULL
  110. pointer is indexed by something, these will produce a fault on most cases)
  111. and can be even used without debugger.
  112.  
  113. Hope this help somebody.
  114.  
  115.  
  116. --
  117. ============================================================================
  118. Walter Tuppa    Inst. for MicroElectronics, Technical University of Vienna
  119.         Gusshausstrasse 27-29 / 1040 Vienna / AUSTRIA
  120.  
  121. E-Mail:        tuppa@iue.tuwien.ac.at
  122. Phone:        +43/1/58801-3713
  123. Fax:        +43/1/5059224
  124. ============================================================================
  125.  
  126.