1.1 Supported Targets

Currently libgloss is being used for the following targets:

• Sparclite Targets Supported
• Motorola CPU32 Targets supported
• Mips core Targets Supported
• PA-RISC Targets Supported

1.2 Configuring and building libgloss.

Libgloss uses an autoconf based script to configure. Autoconf scriptsare portable shell scripts that are generated from a configure.in file.Configure input scripts are based themselves on m4. Most configurescripts run a series of tests to determine features the varioussupported features of the target. For features that can’t be determinedby a feature test, a makefile fragment is merged in. The configureprocess leaves creates a Makefile in the build directory. For libgloss,there are only a few configure options of importance. These are –targetand –srcdir.

Typically libgloss is built in a separate tree just for objects. In thismanner, it’s possible to have a single source tree, and multiple objecttrees. If you only need to configure for a single target environment,then you can configure in the source tree. The argument for –target isa config string. It’s usually safest to use the full canonical opposedto the target alias. So, to configure for a CPU32 (m68k) with a separatesource tree, use:

../src/libgloss/configure --verbose --target m68k-coff

The configure script is in the source tree. When configure is invokedit will determine it’s own source tree, so the –srcdir is would beredundant here.

Once libgloss is configured, make is sufficient to build it. Thedefault values for Makefiles are typically correct for allsupported systems. The test cases in the testsuite will also builtautomatically as opposed to a make check, where test binariesaren’t built till test time. This is mostly cause the libglosstestsuites are the last thing built when building the entire GNU sourcetree, so it’s a good test of all the other compilation passes.

The default values for the Makefiles are set in the Makefile fragmentmerged in during configuration. This fragment typically has rules like

CC_FOR_TARGET = `if [ -f $${OBJROOT}/gcc/xgcc ] ; \	then echo ${OBJROOT}/gcc/xgcc -B${OBJROOT}/gcc/ ; \	else t='${program_transform_name}'; echo gcc | sed -e '' $$t ; fi`

Basically this is a runtime test to determine whether there are freshlybuilt executables for the other main passes of the GNU tools. If thereisn’t an executable built in the same object tree, thentransformedthe generic tool name (like gcc) is transformed to thename typically used in GNU cross compilers. The names aretypically based on the target’s canonical name, so if you’ve configuredfor m68k-coff the transformed name is m68k-coff-gcc inthis case. If you install with aliases or rename the tools, this won’twork, and it will always look for tools in the path. You can force the adifferent name to work by reconfiguring with the--program-transform-name option to configure. This option takes ased script like this -e s,^,m68k-coff-, which produces toolsusing the standard names (at least here at Cygnus).

The search for the other GNU development tools is exactly the same idea.This technique gets messier when build options like -msoft-floatsupport are used. The Makefile fragments set the MUTILIBvariable, and if it is set, the search path is modified. If the linkingis done with an installed cross compiler, then none of this needs to beused. This is done so libgloss will build automatically with a fresh,and uninstalled object tree. It also makes it easier to debug the othertools using libgloss’s test suites.

1.3 Adding Support for a New Board

This section explains how to add support for a new board to libgloss.In order to add support for a board, you must already have developed atoolchain for the target architecture.

All of the changes you will make will be in the subdirectory namedafter the architecture used by your board. For example, if you aredeveloping support for a new ColdFire board, you will modify files inthe m68k subdirectory, as that subdirectory contains supportfor all 68K devices, including architecture variants like ColdFire.

In general, you will be adding three components: a crt0.S file(see Crt0, the main startup file), a linker script (see Linker scripts for memory management), and ahardware support library. Each should be prefixed with the name ofyour board. For example, if you ard adding support for a new Surfboard, then you will be adding the assembly surf-crt0.S (whichwill be assembled into surf-crt0.o), the linker scriptsurf.ld, and other C and assembly files which will be combinedinto the hardware support library libsurf.a.

You should modify Makefile.in to define new variablescorresponding to your board. Although there is some variation betweenarchitectures, the general convention is to use the following format:

# The name of the crt0.o file.SURF_CRT0 = surf-crt0.o# The name of the linker script.SURF_SCRIPTS = surf.ld# The name of the hardware support library.SURF_BSP = libsurf.a# The object files that make up the hardware support library.SURF_OBJS = surf-file1.o surf-file2.o# The name of the Makefile target to use for installation.SURF_INSTALL = install-surf

Then, you should create the ${SURF_BSP} and${SURF_INSTALL} make targets. Add ${SURF_CRT0} tothe dependencies for the all target and add${SURF_INSTALL} to the dependencies for the installtarget. Now, when libgloss is built and installed, support for yourBSP will be installed as well.

2.1 Compilation passes

GCC by itself only compiles the C or C++ code into assembler. TypicallyGCC invokes all the passes required for you. These passes are cpp, cc1,gas, ld. cpp is the C preprocessor. This will merge in theinclude files, expand all macros definitions, and process all the#ifdef sections. To see the output of ccp, invoke gcc with the-E option, and the preprocessed file will be printed on thestdout. cc1 is the actual compiler pass that produces the assembler forthe processed file. GCC is actually only a driver program for all thecompiler passes. It will format command line options for the other passes.The usual command line GCC uses for the final link phase will have LDlink in the startup code and additional libraries by default.

GNU AS started it’s life to only function as a compiler pass, butthese days it can also be used as a source level assembler. When used asa source level assembler, it has a companion assembler preprocessorcalled gasp. This has a syntax similar to most other assemblermacros packages. GAS emits a relocatable object file from the assemblersource. The object file contains the executable part of the application,and debug symbols.

LD is responsible for resolving the addresses and symbols to somethingthat will be fully self-contained. Some RTOS’s use relocatable objectfile formats like a.out, but more commonly the final image willonly use absolute addresses for symbols. This enables code to be burnedinto PROMS as well. Although LD can produce an executable image, thereis usually a hidden object file called crt0.o that is required asstartup code. With this startup code and a memory map, the executableimage will actually run on the target environment. StartupFiles.

The startup code usually defines a special symbol like _startthat is the default base address for the application, and the firstsymbol in the executable image. If you plan to use any routines from thestandard C library, you’ll also need to implement the functions thatthis library is dependent on. Porting Newlib.

Options

Options for the various development tools are covered in more detailelsewhere. Still, the amount of options can be an overwhelming amount ofstuff, so the options most suited to embedded systems are summarizedhere. If you use GCC as the main driver for all the passes, most of thelinker options can be passed directly to the compiler. There are alsoGCC options that control how the GCC driver formats the command linearguments for the linker.

GCC Options

Most of the GCC options that we’re interested control how the GCC driverformats the options for the linker pass.

-nostartfiles

-nostdlib

-Xlinker

Pass the next option directly to the linker.

-v

-fpic

GAS Options

LD Options

3.1 Crt0, the main startup file

To make a program that has been compiled with GCC to run, youneed to write some startup code. The initial piece of startup code iscalled a crt0. (C RunTime 0) This is usually written in assembler, andit’s object gets linked in first, and bootstraps the rest of theapplication when executed. This file needs to do the following things.

1. Initialize anything that needs it. This init section varies. If you aredeveloping an application that gets download to a ROM monitor, thenthere is usually no need for any special initialization. The ROM monitorhandles it for you.

   If you plan to burn your code in a ROM, then the crt0 typically has todo all the hardware initialization that is required to run anapplication. This can include things like initializing serial ports orrun a memory check. It all depends on the hardware.

2. Zero the BSS section. This is for uninitialized data. All the addresses inthis section need to be initialized to zero so that programs that forgetto check new variables default value will get unpredictable results.
3. Call main()This is what basically starts things running. If your ROM monitorsupports it, then first setup argc and argv for command line argumentsand an environment pointer. Then branch to main(). For G++ the the mainroutine gets a branch to __main inserted by the code generator at thevery top. __main() is used by G++ to initialize it’s internal tables.__main() then returns back to your original main() and your code getsexecuted.
4. Call exit()After main() has returned, you need to cleanup things and return controlof the hardware from the application. On some hardware, there is nothingto return to, especially if your program is in ROM. Sometimes the bestthing to do in this case is do a hardware reset, or branch back to thestart address all over again.

   When there is a ROM monitor present, usually a user trap can be calledand then the ROM takes over. Pick a safe vector with no sideeffects. Some ROMs have a builtin trap handler just for this case.

portable between all the m68k based boards we have here.Example Crt0.S.

/* ANSI concatenation macros. */#define CONCAT1(a, b) CONCAT2(a, b)#define CONCAT2(a, b) a ## b

These we’ll use later.

/* These are predefined by new versions of GNU cpp. */#ifndef __USER_LABEL_PREFIX__#define __USER_LABEL_PREFIX__ _#endif/* Use the right prefix for global labels. */#define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x)

These macros are to make this code portable between both COFF anda.out. COFF always has an _ (underline) prepended onthe front of all global symbol names. a.out has none.

#ifndef __REGISTER_PREFIX__#define __REGISTER_PREFIX__#endif/* Use the right prefix for registers. */#define REG(x) CONCAT1 (__REGISTER_PREFIX__, x)#define d0 REG (d0)#define d1 REG (d1)#define d2 REG (d2)#define d3 REG (d3)#define d4 REG (d4)#define d5 REG (d5)#define d6 REG (d6)#define d7 REG (d7)#define a0 REG (a0)#define a1 REG (a1)#define a2 REG (a2)#define a3 REG (a3)#define a4 REG (a4)#define a5 REG (a5)#define a6 REG (a6)#define fp REG (fp)#define sp REG (sp)

This is for portability between assemblers. Some register names have a% or $ prepended to the register name.

/* * Set up some room for a stack. We just grab a chunk of memory. */	.set	stack_size, 0x2000	.comm	SYM (stack), stack_size

Set up space for the stack. This can also be done in the linker script,but it typically gets done here.

/* * Define an empty environment. */ .data .align 2SYM (environ): .long 0

Set up an empty space for the environment. This is bogus on any most ROMmonitor, but we setup a valid address for it, and pass it to main. Atleast that way if an application checks for it, it won’t crash.

	.align	2	.text	.global SYM (stack)	.global SYM (main)	.global SYM (exit)/* * This really should be __bss_start, not SYM (__bss_start). */	.global __bss_start

Setup a few global symbols that get used elsewhere. __bss_startneeds to be unchanged, as it’s setup by the linker script.

/* * start -- set things up so the application will run. */SYM (start):	link	a6, #-8	moveal	#SYM (stack) + stack_size, sp/* * zerobss -- zero out the bss section */	moveal	#__bss_start, a0	moveal	#SYM (end), a11:	movel	#0, (a0)	leal	4(a0), a0	cmpal	a0, a1	bne	1b

The global symbol start is used by the linker as the defaultaddress to use for the .text section. then it zeros the.bss section so the uninitialized data will all be cleared. Someprograms have wild side effects from having the .bss section letuncleared. Particularly it causes problems with some implementations ofmalloc.

/* * Call the main routine from the application to get it going. * main (argc, argv, environ) * We pass argv as a pointer to NULL. */ pea 0 pea SYM (environ) pea sp@(4) pea 0	jsr	SYM (main)	movel	d0, sp@-

Setup the environment pointer and jump to main(). Whenmain() returns, it drops down to the exit routine below.

/* * _exit -- Exit from the application. Normally we cause a user trap * to return to the ROM monitor for another run. */SYM (exit):	trap	#0

Implementing exit here is easy. Both the rom68k and bugcan handle a user caused exception of zero with no side effects.Although the bug monitor has a user caused trap that will returncontrol to the ROM monitor, this solution has been more portable.

3.2 Linker scripts for memory management

The linker script sets up the memory map of an application. It alsosets up default values for variables used elsewhere by sbrk() and thecrt0. These default variables are typically called _bss_start and_end.

For G++, the constructor and destructor tables must also be setup here.The actual section names vary depending on the object file format. Fora.out and coff, the three main sections are .text,.data, and .bss.

Now that you have an image, you can test to make sure it got thememory map right. You can do this by having the linker create a memorymap (by using the -Map option), or afterwards by using nm tocheck a few critical addresses like start, bss_end, and_etext.

Here’s a breakdown of a linker script for a m68k based target board.See the file libgloss/m68k/idp.ld, or go to the appendixes inthe end of the manual. Example Linker Script.

STARTUP(crt0.o)OUTPUT_ARCH(m68k)INPUT(idp.o)SEARCH_DIR(.)__DYNAMIC = 0;

The STARTUP command loads the file specified so that it’sfirst. In this case it also doubles to load the file as well, becausethe m68k-coff configuration defaults to not linking in the crt0.o bydefault. It assumes that the developer probably has their own crt0.o.This behavior is controlled in the config file for each architecture.It’s a macro called STARTFILE_SPEC, and if it’s set tonull, then when gcc formats it’s command line, it doesn’tadd crto.o. Any file name can be specified here, but the defaultis always crt0.o.

Course if you only use ld to link, then the control of whether ornot to link in crt0.o is done on the command line. If you havemultiple crto files, then you can leave this out all together, and linkin the crt0.o in the makefile, or by having different linkerscripts. Sometimes this is done for initializing floating pointoptionally, or to add device support.

The OUTPUT_ARCH sets architecture the output file is for.

INPUT loads in the file specified. In this case, it’s a relocatedlibrary that contains the definitions for the low-level functions needby libc.a. This could have also been specified on the command line, butas it’s always needed, it might as well be here as a default.SEARCH_DIR specifies the path to look for files, and_DYNAMIC means in this case there are no shared libraries.

/* * Setup the memory map of the MC68ec0x0 Board (IDP) * stack grows up towards high memory. This works for * both the rom68k and the mon68k monitors. */MEMORY{ ram : ORIGIN = 0x10000, LENGTH = 2M}

This specifies a name for a section that can be referred to later in thescript. In this case, it’s only a pointer to the beginning of free RAMspace, with an upper limit at 2M. If the output file exceeds the upperlimit, it will produce an error message.

/* * stick everything in ram (of course) */SECTIONS{ .text : { CREATE_OBJECT_SYMBOLS *(.text) etext = .; __CTOR_LIST__ = .; LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) *(.ctors) LONG(0) __CTOR_END__ = .; __DTOR_LIST__ = .; LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2) *(.dtors) LONG(0) __DTOR_END__ = .; *(.lit) *(.shdata) } > ram .shbss SIZEOF(.text) + ADDR(.text) :	{ *(.shbss) }

Set up the .text section. In a COFF file, .text is whereall the actual instructions are. This also sets up the CONTRUCTORand the DESTRUCTOR tables for G++. Notice that the sectiondescription redirects itself to the ram variable setup earlier.

 .talias : { } > ram .data : { *(.data) CONSTRUCTORS _edata = .; } > ram

Setup the .data section. In a coff file, this is where allhe initialized data goes. CONSTRUCTORS is a special command usedby ld.

 .bss SIZEOF(.data) + ADDR(.data) : { __bss_start = ALIGN(0x8); *(.bss) *(COMMON) end = ALIGN(0x8); _end = ALIGN(0x8); __end = ALIGN(0x8); } .mstack : { } > ram .rstack : { } > ram .stab . (NOLOAD) : { [ .stab ] } .stabstr . (NOLOAD) : { [ .stabstr ] }}

Setup the .bss section. In a COFF file, this is whereunitialized data goes. The symbols _bss_start and _endare setup here for use by the crt0.o when it zero’s the.bss section.

3.3 What to do when you have a binary image

A few ROM monitors load binary images, typically a.out, but most allwill load an srecord. An srecord is an ASCII representation of a binaryimage. At it’s simplest, an srecord is an address, followed by a bytecount, followed by the bytes, and a 2’s compliment checksum. A wholesrecord file has an optional start record, and a required endrecord. To make an srecord from a binary image, the GNU objcopy programis used. This will read the image and make an srecord from it. To dothis, invoke objcopy like this: objcopy -O srec infile outfile. MostPROM burners also read srecords or a similar format. Use objdump -i toget a list of support object files types for your architecture.

3.4 Libraries

This describes newlib, a freely available libc replacement. Mostapplications use calls in the standard C library. When initially linkingin libc.a, several I/O functions are undefined. If you don’t plan ondoing any I/O, then you’re OK, otherwise they need to be created. Theseroutines are read, write, open, close. sbrk, and kill. Open & closedon’t need to be fully supported unless you have a filesystems, sotypically they are stubbed out. Kill is also a stub, since you can’t doprocess control on an embedded system.

Sbrk() is only needed by applications that do dynamic memoryallocation. It’s uses the symbol _end that is setup in the linkerscript. It also requires a compile time option to set the upper sizelimit on the heap space. This leaves us with read and write, which arerequired for serial I/O. Usually these two routines are written in C,and call a lower level function for the actual I/O operation. These twolowest level I/O primitives are inbyte() and outbyte(), and are alsoused by GDB back ends if you’ve written an exception handler. Somesystems also implement a havebyte() for input as well.

Other commonly included functions are routines for manipulatingLED’s on the target (if they exist) or low level debug help. Typically aputnum() for printing words and bytes as a hex number is helpful, aswell as a low-level print() to output simple strings.

As libg++ uses the I/O routines in libc.a, if read and write work,then libg++ will also work with no additional changes.

• Making I/O work
• Routines for dynamic memory allocation
• Misc support routines
• Useful debugging functions

/* _end is set in the linker command file *extern caddr_t _end;//* just in case, most boards have at least some memory */#ifndef RAMSIZE# define RAMSIZE (caddr_t)0x100000#endif/* * sbrk -- changes heap size size. Get nbytes more * RAM. We just increment a pointer in what's * left of memory on the board. */caddr_tsbrk(nbytes) int nbytes;{ static caddr_t heap_ptr = NULL; caddr_t base; if (heap_ptr == NULL) { heap_ptr = (caddr_t)&_end; } if ((RAMSIZE - heap_ptr) >= 0) { base = heap_ptr; heap_ptr += nbytes; return (base); } else { errno = ENOMEM; return ((caddr_t)-1); }}

/* * isatty -- returns 1 if connected to a terminal device, * returns 0 if not. Since we're hooked up to a * serial port, we'll say yes and return a 1. */intisatty(fd) int fd;{ return (1);}/* * getpid -- only one process, so just return 1. */#define __MYPID 1intgetpid(){ return __MYPID;}/* * kill -- go out via exit... */intkill(pid, sig) int pid; int sig;{ if(pid == __MYPID) _exit(sig); return 0;}

/* * print -- do a raw print of a string */intprint(ptr)char *ptr;{ while (*ptr) { outbyte (*ptr++); }}/* * putnum -- print a 32 bit number in hex */intputnum (num)unsigned int num;{ char buffer[9]; int count; char *bufptr = buffer; int digit; for (count = 7 ; count >= 0 ; count--) { digit = (num >> (count * 4)) & 0xf; if (digit <= 9) *bufptr++ = (char) ('0' + digit); else *bufptr++ = (char) ('a' - 10 + digit); } *bufptr = (char) 0; print (buffer); return;}

 [d.p | g | f | e | d | c | b | a ] is the byte.

 a ----- f | | b | g | ----- | | e | | c ----- d

#define LED_ADDR	0xd00003voidled_putnum ( num )char num;{ static unsigned char *leds = (unsigned char *)LED_ADDR; static unsigned char num_bits [18] = { 0xff,	/* clear all */ 0xc0, 0xf9, 0xa4, 0xb0, 0x99, 0x92, 0x82, 0xf8, 0x80, 0x98, /* numbers 0-9 */ 0x98, 0x20, 0x3, 0x27, 0x21, 0x4, 0xe	/* letters a-f */ }; if (num >= '0' && num <= '9') num = (num - '0') + 1; if (num >= 'a' && num <= 'f') num = (num - 'a') + 12; if (num == ' ') num = 0; *leds = num_bits[num];}/* * zylons -- draw a rotating pattern. NOTE: this function never returns. */voidzylons(){ unsigned char *leds	= (unsigned char *)LED_ADDR; unsigned char curled = 0xfe; while (1) { *leds = curled; curled = (curled >> 1) | (curled << 7); delay ( 200 ); }}

4.1 The standard remote protocol

The standard remote protocol is a simple, packet based scheme. A debugpacket whose contents are <data> is encapsulated for transmissionin the form:

$ <data> # CSUM1 CSUM2

<data> must be ASCII alphanumeric and cannot include characters$ or #. If <data> starts with two charactersfollowed by :, then the existing stubs interpret this as asequence number. For example, the command g is used to read thevalues of the registers. So, a packet to do this would look like

 $g#67

CSUM1 and CSUM2 are an ascii representation in hex of an8-bit checksum of <data>, the most significant nibble is sent first.the hex digits 0-9,a-f are used.

A simple protocol is used when communicating with the target. This ismainly to give a degree of error handling over the serial cable. Foreach packet transmitted successfully, the target responds with a+ (ACK). If there was a transmission error, then the targetresponds with a - (NAK). An error is determined when thechecksum doesn’t match the calculated checksum for that data record.Upon reciept of the ACK, GDB can then transmit the nextpacket.

Here is a list of the main functions that need to be supported. Each datapacket is a command with a set number of bytes in the command packet.Most commands either return data, or respond with a NAK. Commandsthat don’t return data respond with an ACK. All data values areascii hex digits. Every byte needs two hex digits to represent t. Thismeans that a byte with the value ‘7’ becomes ‘07’. On a 32 bitmachine this works out to 8 characters per word. All of the bytes in aword are stored in the target byte order. When writing the host side ofthe GDB protocol, be careful of byte order, and make sure that the codewill run on both big and little endian hosts and produce the same answers.

These functions are the minimum required to make a GDB backend work. Allother commands are optional, and not supported by all GDB backends.

‘read registers g’

returns XXXXXXXX...

Registers are in the internal order for GDB, and the bytes in a registerare in the same order the machine uses. All values are in sequencestarting with register 0. All registers are listed in the same packet. Asample packet would look like $g#.

‘write registersGXXXXXXXX...’

XXXXXXXX is the value to set the register to. Registers are inthe internal order for GDB, and the bytes in a register are in the sameorder the machine uses. All values are in sequence starting withregister 0. All registers values are listed in the same packet. A samplepacket would look like $G000000001111111122222222...#

returns ACK or NAK

‘read memory mAAAAAAAA,LLLL’

AAAAAAAA is address, LLLL is length. A sample packet wouldlook like $m00005556,0024#. This would request 24 bytes startingat address 00005556

returns XXXXXXXX...XXXXXXXX is the memory contents. Fewer bytes than requested willbe returned if only part of the data can be read. This can be determinedby counting the values till the end of packet # is seen andcomparing that with the total count of bytes that was requested.

‘write memoryMAAAAAAAA,LLLL:XXXXXXXX’

AAAAAAAA is the starting address, LLLL is the number ofbytes to be written, and XXXXXXXX is value to be written. Asample packet would look like$M00005556,0024:101010101111111100000000...#

returns ACK or NAK for an error. NAK is alsoreturned when only part of the data is written.

‘continuecAAAAAAAAA’

AAAAAAAA is address to resume execution at. If AAAAAAAA isomitted, resume at the curent address of the pc register.

returns the same replay as last signal. There is no immediatereplay to cont until the next breakpoint is reached, and theprogram stops executing.

‘step sAA..AA’

AA..AA is address to resumeIf AA..AA is omitted, resume at same address.

returns the same replay as last signal. There is no immediatereplay to step until the next breakpoint is reached, and theprogram stops executing.

‘last signal ?’

This returns one of the following:

• SAAWhere AA is the number of the last signal.Exceptions on the target are converted to the most similar Unix stylesignal number, like SIGSEGV. A sample response of this type wouldlook like $S05#.
• TAAnn:XXXXXXXX;nn:XXXXXXXX;nn:XXXXXXXX;AA is the signal number.nn is the register number.XXXXXXXX is the register value.
• WAAThe process exited, and AA is the exit status. This is onlyapplicable for certains sorts of targets.

These are used in some GDB backends, but not all.

‘write reg Pnn=XXXXXXXX’

Write register nn with value XXXXXXXX.

returns ACK or NAK

‘kill request k’

‘toggle debug d’

toggle debug flag (see 386 & 68k stubs)

‘reset r’

reset – see sparc stub.

‘reservedother’

On other requests, the stub should ignore the request and send an emptyresponse $#<checksum>. This way we can extend the protocol and GDBcan tell whether the stub it is talking to uses the old or the new.

‘searchtAA:PP,MM’

Search backwards starting at address AA for a match with patternPP and mask MM. PP and MM are 4 bytes.

‘general queryqXXXX’

Request info about XXXX.

‘general setQXXXX=yyyy’

Set value of XXXX to yyyy.

‘query sect offsqOffsets’

Get section offsets. Reply is Text=xxx;Data=yyy;Bss=zzz

‘console output Otext’

Send text to stdout. The text gets display from the target side of theserial connection.

Responses can be run-length encoded to save space. A *means thatthe next character is an ASCII encoding giving a repeat count whichstands for that many repetitions of the character preceding the *.The encoding is n+29, yielding a printable character where n >=3(which is where run length encoding starts to win). You can’t use avalue of where n >126 because it’s only a two byte value. An examplewould be a 0*03 means the same thing as 0000.

4.2 A linked in exception handler

A GDB stub consists of two parts, support for the exceptionhandler, and the exception handler itself. The exception handler needsto communicate to GDB on the host whenever there is a breakpointexception. When GDB starts a program running on the target, it’s pollingthe serial port during execution looking for any debug packets. So whena breakpoint occurs, the exception handler needs to save state, and senda GDB remote protocol packet to GDB on the host. GDB takes any outputthat isn’t a debug command packet and displays it in the command window.

Support for the exception handler varies between processors, but theminimum supported functions are those needed by GDB. These are functionsto support the reading and writing of registers, the reading and writingof memory, start execution at an address, single step, and last signal.Sometimes other functions for adjusting the baud rate, or resetting thehardware are implemented.

Once GDB gets the command packet from the breakpoint, it will read a fewregisters and memory locations an then wait for the user. When the usertypes run or continue a continue command is issuedto the backend, and control returns from the breakpoint routine to theapplication.

4.3 Using a ROM monitor as a backend

GDB also can mimic a human user and use a ROM monitors normal debugcommands as a backend. This consists mostly of sending and parsingASCII strings. All the ROM monitor interfaces share a common setof routines in gdb/monitor.c. This supports adding new ROMmonitor interfaces by filling in a structure with the common commandsGDB needs. GDb already supports several command ROM monitors, includingMotorola’s Bug monitor for their VME boards, and the Rom68kmonitor by Integrated Systems, Inc. for various m68k based boards. GDBalso supports the custom ROM monitors on the WinBond and Oki PA basedtargets. There is builtin support for loading files to ROM monitorsspecifically. GDB can convert a binary into an srecord and then load itas an ascii file, or using xmodem.

4.4 Adding support for new protocols

Binutils