🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.gdb.bug
Article #135

Re: Debug register use for ISC 2.2.1 (Sys v/386 R3.2)

#135
From: Walter Tuppa
Date: Tue, 28 Jul 1992 09:09
111 lines
5425 bytes
Hello,

it's quite nice to use an accesspoint to watch for NULL pointer accesses, but
there is a much easier way on Interactive Unix. You just write a load-file
for the linker, which is mentioned on the link command line.

source of file <ldfile>
=========================== cut here =========================================
/* Specify the memory section of valid memory  [.MEMORY].   We  will */
/* allow  addresses  from  4 megabytes (0x400000) to two gigabytes   */
/* (0x80000000), we will put the text and data up at four  megabytes */
/* (0x400000).                                                       */
/* the second memory region is for the shared libaries like -lc_s or */
/* the X-Window system. This region uses all the 0xA.. and 0xB..     */
/* memory region, e.g. -lc_s uses 0xA0000000 for code (shared) and   */
/* 0xA04000000 for data (private to process).                        */

MEMORY  {
	user:   org = 0x00400000, len = 0x7FBFFFFF
	shared: org = 0xA0000000, len = 0x1FFFFFFF
	}

/* Define the sections of the object file.                           */

SECTIONS {

	/* The following sets up two  sections.   The  first  output */
	/* section  is  called  ".init" and includes all the ".init" */
	/* sections in the  input  files.   The  second  section  is */
	/* called  ".text"  and includes all the ".text" sections in */
	/* the input files.  The ".init" section  will  be  given  a */
	/* starting address of four megabytes (0x400000).   It  will */
	/* be  placed  in the object file at the  next  4K byte file */
	/* position.  Unfortunately, there is no  way  to  determine */
	/* the  header size, hence we must waste most of the zero'th */
	/* block.  Further it appears that we can  not  tell  it  to */
	/* page  in  from  the  next file block, but rather from the */
	/* next page.  Hence we  unfortunately  waste  most  of  the */
	/* page.   It appears that the loader has some bugs  dealing */
	/* with  the  processing  of   ifiles.    Putting   in   the */
	/* initialization  of  space to 0x9090 (nop's) seems to have */
	/* helped in causing the .text section to go  to  the  right */
	/* spot  in  the output file when there is no .init section. */
	/* The ".text"  section  will  be  given a starting address  */
	/* of the  address  immediately  after the  ".init" section. */
	/* Likewise it will be put in the file immediately after the */
	/* ".init" section.                                          */

	GROUP BIND (0x400000) BLOCK (0x1000) : {
	    .init : {} = 0x9090
	    .text : {} = 0x9090
	    } > user

	/* The following sets  up  two  more  sections.   The  third */
	/* output  section  is  called  ".data" and includes all the */
	/* ".data" sections in the input files.  The fourth  section */
	/* is  called ".bss" and sums all the ".bss" sections in the */
	/* input  files.   The  ".data"  section  will  be  given  a */
	/* starting   address   of  the  next  region  alignment  (4 */
	/* megabyte) address after the current  location  (the  last */
	/* address  of  the  ".text" segment).  It will be placed in */
	/* the object file at the next  page  alignment  (4K  bytes) */
	/* file  position  after the current file position (the last */
	/* position of the ".text" segment).  Again, I suspect  that */
	/* it  is  necessary  to  be on a page boundary and not on a */
	/* file block boundary, causing a lot  of  the  page  to  be */
	/* wasted.   The  ".bss"  section  will  be given a starting */
	/* address  of  the  address  of  the  end  of  the  ".data" */
	/* section.  Likewise it will be put in the file immediately */
	/* after the ".data" section.  However, it will not actually */
	/* take any space.                                           */

	GROUP BIND (((SIZEOF (.text) + 0x3FFFFF) &
	  (~0x3FFFFF)) + 0x400000) BLOCK (0x1000) : {
		.data : {}
		.bss :  {}
		} > user

	/* end of description                                        */
	}
=========================== cut here =========================================


as a test, use this little program:

main()
{
	int *a = 0;
	*a = 0;
}

this should now produce a Segmentation fault (core dumped).
[this can be used with cc and gcc]

I think this method is much better, because it will generate a Segmentation
fault for any memory access in the first 4 MegaBytes (even if the NULL
pointer is indexed by something, these will produce a fault on most cases)
and can be even used without debugger.

Hope this help somebody.


--
============================================================================
Walter Tuppa	Inst. for MicroElectronics, Technical University of Vienna
		Gusshausstrasse 27-29 / 1040 Vienna / AUSTRIA

E-Mail:		tuppa@iue.tuwien.ac.at
Phone:		+43/1/58801-3713
Fax:		+43/1/5059224
============================================================================
Technical Details
Message-ID: <TUPPA.92Jul28100919@eued50.tuwien.ac.at>
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!eued50.tuwien.ac.at!tuppa
References: tuppa@eued50.tuwien.ac.at (Walter Tuppa)

Show Full Headers
Complete Article Headers
Newsgroups: gnu.gdb.bug
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!eued50.tuwien.ac.at!tuppa
From: tuppa@eued50.tuwien.ac.at (Walter Tuppa)
Subject: Re: Debug register use for ISC 2.2.1 (Sys v/386 R3.2)
Message-ID: <TUPPA.92Jul28100919@eued50.tuwien.ac.at>
Sender: gnulists@ai.mit.edu
Organization: Technical University of Vienna
References: tuppa@eued50.tuwien.ac.at (Walter Tuppa)
Distribution: gnu
Date: Tue, 28 Jul 1992 09:09:19 GMT
Approved: bug-gdb@prep.ai.mit.edu
Lines: 112