From 7d86b5d55d228fda6e78afaa2bbeb373793a5c34 Mon Sep 17 00:00:00 2001 From: Andrew Cagney Date: Tue, 15 Jan 2002 01:38:45 +0000 Subject: * gdb.texinfo (Embedded Processors, Calling program functions): Obsolete references to a29k. --- gdb/doc/ChangeLog | 5 + gdb/doc/gdb.texinfo | 501 ++++++++++++++++++++++++++-------------------------- 2 files changed, 256 insertions(+), 250 deletions(-) (limited to 'gdb') diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog index 2ebde29..775b0e0 100644 --- a/gdb/doc/ChangeLog +++ b/gdb/doc/ChangeLog @@ -1,3 +1,8 @@ +2002-01-14 Andrew Cagney + + * gdb.texinfo (Embedded Processors, Calling program functions): + Obsolete references to a29k. + 2002-01-13 Andrew Cagney * gdbint.texinfo (Coding): Review Cleanups section. Examples diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 7d395a0..2552511 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -9153,11 +9153,11 @@ execute a function from your program, but without cluttering the output with @code{void} returned values. If the result is not void, it is printed and saved in the value history. -For the A29K, a user-controlled variable @code{call_scratch_address}, -specifies the location of a scratch area to be used when @value{GDBN} -calls a function in the target. This is necessary because the usual -method of putting the scratch area on the stack does not work in systems -that have separate instruction and data spaces. +@c OBSOLETE For the A29K, a user-controlled variable @code{call_scratch_address}, +@c OBSOLETE specifies the location of a scratch area to be used when @value{GDBN} +@c OBSOLETE calls a function in the target. This is necessary because the usual +@c OBSOLETE method of putting the scratch area on the stack does not work in systems +@c OBSOLETE that have separate instruction and data spaces. @node Patching @section Patching programs @@ -11754,8 +11754,9 @@ the time of attachment. This section goes into details specific to particular embedded configurations. + +@c OBSOLETE * A29K Embedded:: AMD A29K Embedded @menu -* A29K Embedded:: AMD A29K Embedded * ARM:: ARM * H8/300:: Hitachi H8/300 * H8/500:: Hitachi H8/500 @@ -11773,250 +11774,250 @@ configurations. * Z8000:: Zilog Z8000 @end menu -@node A29K Embedded -@subsection AMD A29K Embedded - -@menu -* A29K UDI:: -* A29K EB29K:: -* Comms (EB29K):: Communications setup -* gdb-EB29K:: EB29K cross-debugging -* Remote Log:: Remote log -@end menu - -@table @code - -@kindex target adapt -@item target adapt @var{dev} -Adapt monitor for A29K. - -@kindex target amd-eb -@item target amd-eb @var{dev} @var{speed} @var{PROG} -@cindex AMD EB29K -Remote PC-resident AMD EB29K board, attached over serial lines. -@var{dev} is the serial device, as for @code{target remote}; -@var{speed} allows you to specify the linespeed; and @var{PROG} is the -name of the program to be debugged, as it appears to DOS on the PC. -@xref{A29K EB29K, ,EBMON protocol for AMD29K}. - -@end table - -@node A29K UDI -@subsubsection A29K UDI - -@cindex UDI -@cindex AMD29K via UDI - -@value{GDBN} supports AMD's UDI (``Universal Debugger Interface'') -protocol for debugging the a29k processor family. To use this -configuration with AMD targets running the MiniMON monitor, you need the -program @code{MONTIP}, available from AMD at no charge. You can also -use @value{GDBN} with the UDI-conformant a29k simulator program -@code{ISSTIP}, also available from AMD. - -@table @code -@item target udi @var{keyword} -@kindex udi -Select the UDI interface to a remote a29k board or simulator, where -@var{keyword} is an entry in the AMD configuration file @file{udi_soc}. -This file contains keyword entries which specify parameters used to -connect to a29k targets. If the @file{udi_soc} file is not in your -working directory, you must set the environment variable @samp{UDICONF} -to its pathname. -@end table - -@node A29K EB29K -@subsubsection EBMON protocol for AMD29K - -@cindex EB29K board -@cindex running 29K programs - -AMD distributes a 29K development board meant to fit in a PC, together -with a DOS-hosted monitor program called @code{EBMON}. As a shorthand -term, this development system is called the ``EB29K''. To use -@value{GDBN} from a Unix system to run programs on the EB29K board, you -must first connect a serial cable between the PC (which hosts the EB29K -board) and a serial port on the Unix system. In the following, we -assume you've hooked the cable between the PC's @file{COM1} port and -@file{/dev/ttya} on the Unix system. - -@node Comms (EB29K) -@subsubsection Communications setup - -The next step is to set up the PC's port, by doing something like this -in DOS on the PC: - -@example -C:\> MODE com1:9600,n,8,1,none -@end example - -@noindent -This example---run on an MS DOS 4.0 system---sets the PC port to 9600 -bps, no parity, eight data bits, one stop bit, and no ``retry'' action; -you must match the communications parameters when establishing the Unix -end of the connection as well. -@c FIXME: Who knows what this "no retry action" crud from the DOS manual may -@c mean? It's optional; leave it out? ---doc@cygnus.com, 25feb91 -@c -@c It's optional, but it's unwise to omit it: who knows what is the -@c default value set when the DOS machines boots? "No retry" means that -@c the DOS serial device driver won't retry the operation if it fails; -@c I understand that this is needed because the GDB serial protocol -@c handles any errors and retransmissions itself. ---Eli Zaretskii, 3sep99 - -To give control of the PC to the Unix side of the serial line, type -the following at the DOS console: - -@example -C:\> CTTY com1 -@end example - -@noindent -(Later, if you wish to return control to the DOS console, you can use -the command @code{CTTY con}---but you must send it over the device that -had control, in our example over the @file{COM1} serial line.) - -From the Unix host, use a communications program such as @code{tip} or -@code{cu} to communicate with the PC; for example, - -@example -cu -s 9600 -l /dev/ttya -@end example - -@noindent -The @code{cu} options shown specify, respectively, the linespeed and the -serial port to use. If you use @code{tip} instead, your command line -may look something like the following: - -@example -tip -9600 /dev/ttya -@end example - -@noindent -Your system may require a different name where we show -@file{/dev/ttya} as the argument to @code{tip}. The communications -parameters, including which port to use, are associated with the -@code{tip} argument in the ``remote'' descriptions file---normally the -system table @file{/etc/remote}. -@c FIXME: What if anything needs doing to match the "n,8,1,none" part of -@c the DOS side's comms setup? cu can support -o (odd -@c parity), -e (even parity)---apparently no settings for no parity or -@c for character size. Taken from stty maybe...? John points out tip -@c can set these as internal variables, eg ~s parity=none; man stty -@c suggests that it *might* work to stty these options with stdin or -@c stdout redirected... ---doc@cygnus.com, 25feb91 -@c -@c There's nothing to be done for the "none" part of the DOS MODE -@c command. The rest of the parameters should be matched by the -@c baudrate, bits, and parity used by the Unix side. ---Eli Zaretskii, 3Sep99 - -@kindex EBMON -Using the @code{tip} or @code{cu} connection, change the DOS working -directory to the directory containing a copy of your 29K program, then -start the PC program @code{EBMON} (an EB29K control program supplied -with your board by AMD). You should see an initial display from -@code{EBMON} similar to the one that follows, ending with the -@code{EBMON} prompt @samp{#}--- - -@example -C:\> G: - -G:\> CD \usr\joe\work29k - -G:\USR\JOE\WORK29K> EBMON -Am29000 PC Coprocessor Board Monitor, version 3.0-18 -Copyright 1990 Advanced Micro Devices, Inc. -Written by Gibbons and Associates, Inc. - -Enter '?' or 'H' for help - -PC Coprocessor Type = EB29K -I/O Base = 0x208 -Memory Base = 0xd0000 - -Data Memory Size = 2048KB -Available I-RAM Range = 0x8000 to 0x1fffff -Available D-RAM Range = 0x80002000 to 0x801fffff - -PageSize = 0x400 -Register Stack Size = 0x800 -Memory Stack Size = 0x1800 - -CPU PRL = 0x3 -Am29027 Available = No -Byte Write Available = Yes - -# ~. -@end example - -Then exit the @code{cu} or @code{tip} program (done in the example by -typing @code{~.} at the @code{EBMON} prompt). @code{EBMON} keeps -running, ready for @value{GDBN} to take over. - -For this example, we've assumed what is probably the most convenient -way to make sure the same 29K program is on both the PC and the Unix -system: a PC/NFS connection that establishes ``drive @file{G:}'' on the -PC as a file system on the Unix host. If you do not have PC/NFS or -something similar connecting the two systems, you must arrange some -other way---perhaps floppy-disk transfer---of getting the 29K program -from the Unix system to the PC; @value{GDBN} does @emph{not} download it over the -serial line. - -@node gdb-EB29K -@subsubsection EB29K cross-debugging - -Finally, @code{cd} to the directory containing an image of your 29K -program on the Unix system, and start @value{GDBN}---specifying as argument the -name of your 29K program: - -@example -cd /usr/joe/work29k -@value{GDBP} myfoo -@end example - -@need 500 -Now you can use the @code{target} command: - -@example -target amd-eb /dev/ttya 9600 MYFOO -@c FIXME: test above 'target amd-eb' as spelled, with caps! caps are meant to -@c emphasize that this is the name as seen by DOS (since I think DOS is -@c single-minded about case of letters). ---doc@cygnus.com, 25feb91 -@end example - -@noindent -In this example, we've assumed your program is in a file called -@file{myfoo}. Note that the filename given as the last argument to -@code{target amd-eb} should be the name of the program as it appears to DOS. -In our example this is simply @code{MYFOO}, but in general it can include -a DOS path, and depending on your transfer mechanism may not resemble -the name on the Unix side. - -At this point, you can set any breakpoints you wish; when you are ready -to see your program run on the 29K board, use the @value{GDBN} command -@code{run}. - -To stop debugging the remote program, use the @value{GDBN} @code{detach} -command. - -To return control of the PC to its console, use @code{tip} or @code{cu} -once again, after your @value{GDBN} session has concluded, to attach to -@code{EBMON}. You can then type the command @code{q} to shut down -@code{EBMON}, returning control to the DOS command-line interpreter. -Type @kbd{CTTY con} to return command input to the main DOS console, -and type @kbd{~.} to leave @code{tip} or @code{cu}. - -@node Remote Log -@subsubsection Remote log -@cindex @file{eb.log}, a log file for EB29K -@cindex log file for EB29K - -The @code{target amd-eb} command creates a file @file{eb.log} in the -current working directory, to help debug problems with the connection. -@file{eb.log} records all the output from @code{EBMON}, including echoes -of the commands sent to it. Running @samp{tail -f} on this file in -another window often helps to understand trouble with @code{EBMON}, or -unexpected events on the PC side of the connection. +@c OBSOLETE @node A29K Embedded +@c OBSOLETE @subsection AMD A29K Embedded +@c OBSOLETE +@c OBSOLETE @menu +@c OBSOLETE * A29K UDI:: +@c OBSOLETE * A29K EB29K:: +@c OBSOLETE * Comms (EB29K):: Communications setup +@c OBSOLETE * gdb-EB29K:: EB29K cross-debugging +@c OBSOLETE * Remote Log:: Remote log +@c OBSOLETE @end menu +@c OBSOLETE +@c OBSOLETE @table @code +@c OBSOLETE +@c OBSOLETE @kindex target adapt +@c OBSOLETE @item target adapt @var{dev} +@c OBSOLETE Adapt monitor for A29K. +@c OBSOLETE +@c OBSOLETE @kindex target amd-eb +@c OBSOLETE @item target amd-eb @var{dev} @var{speed} @var{PROG} +@c OBSOLETE @cindex AMD EB29K +@c OBSOLETE Remote PC-resident AMD EB29K board, attached over serial lines. +@c OBSOLETE @var{dev} is the serial device, as for @code{target remote}; +@c OBSOLETE @var{speed} allows you to specify the linespeed; and @var{PROG} is the +@c OBSOLETE name of the program to be debugged, as it appears to DOS on the PC. +@c OBSOLETE @xref{A29K EB29K, ,EBMON protocol for AMD29K}. +@c OBSOLETE +@c OBSOLETE @end table +@c OBSOLETE +@c OBSOLETE @node A29K UDI +@c OBSOLETE @subsubsection A29K UDI +@c OBSOLETE +@c OBSOLETE @cindex UDI +@c OBSOLETE @cindex AMD29K via UDI +@c OBSOLETE +@c OBSOLETE @value{GDBN} supports AMD's UDI (``Universal Debugger Interface'') +@c OBSOLETE protocol for debugging the a29k processor family. To use this +@c OBSOLETE configuration with AMD targets running the MiniMON monitor, you need the +@c OBSOLETE program @code{MONTIP}, available from AMD at no charge. You can also +@c OBSOLETE use @value{GDBN} with the UDI-conformant a29k simulator program +@c OBSOLETE @code{ISSTIP}, also available from AMD. +@c OBSOLETE +@c OBSOLETE @table @code +@c OBSOLETE @item target udi @var{keyword} +@c OBSOLETE @kindex udi +@c OBSOLETE Select the UDI interface to a remote a29k board or simulator, where +@c OBSOLETE @var{keyword} is an entry in the AMD configuration file @file{udi_soc}. +@c OBSOLETE This file contains keyword entries which specify parameters used to +@c OBSOLETE connect to a29k targets. If the @file{udi_soc} file is not in your +@c OBSOLETE working directory, you must set the environment variable @samp{UDICONF} +@c OBSOLETE to its pathname. +@c OBSOLETE @end table +@c OBSOLETE +@c OBSOLETE @node A29K EB29K +@c OBSOLETE @subsubsection EBMON protocol for AMD29K +@c OBSOLETE +@c OBSOLETE @cindex EB29K board +@c OBSOLETE @cindex running 29K programs +@c OBSOLETE +@c OBSOLETE AMD distributes a 29K development board meant to fit in a PC, together +@c OBSOLETE with a DOS-hosted monitor program called @code{EBMON}. As a shorthand +@c OBSOLETE term, this development system is called the ``EB29K''. To use +@c OBSOLETE @value{GDBN} from a Unix system to run programs on the EB29K board, you +@c OBSOLETE must first connect a serial cable between the PC (which hosts the EB29K +@c OBSOLETE board) and a serial port on the Unix system. In the following, we +@c OBSOLETE assume you've hooked the cable between the PC's @file{COM1} port and +@c OBSOLETE @file{/dev/ttya} on the Unix system. +@c OBSOLETE +@c OBSOLETE @node Comms (EB29K) +@c OBSOLETE @subsubsection Communications setup +@c OBSOLETE +@c OBSOLETE The next step is to set up the PC's port, by doing something like this +@c OBSOLETE in DOS on the PC: +@c OBSOLETE +@c OBSOLETE @example +@c OBSOLETE C:\> MODE com1:9600,n,8,1,none +@c OBSOLETE @end example +@c OBSOLETE +@c OBSOLETE @noindent +@c OBSOLETE This example---run on an MS DOS 4.0 system---sets the PC port to 9600 +@c OBSOLETE bps, no parity, eight data bits, one stop bit, and no ``retry'' action; +@c OBSOLETE you must match the communications parameters when establishing the Unix +@c OBSOLETE end of the connection as well. +@c OBSOLETE @c FIXME: Who knows what this "no retry action" crud from the DOS manual may +@c OBSOLETE @c mean? It's optional; leave it out? ---doc@cygnus.com, 25feb91 +@c OBSOLETE @c +@c OBSOLETE @c It's optional, but it's unwise to omit it: who knows what is the +@c OBSOLETE @c default value set when the DOS machines boots? "No retry" means that +@c OBSOLETE @c the DOS serial device driver won't retry the operation if it fails; +@c OBSOLETE @c I understand that this is needed because the GDB serial protocol +@c OBSOLETE @c handles any errors and retransmissions itself. ---Eli Zaretskii, 3sep99 +@c OBSOLETE +@c OBSOLETE To give control of the PC to the Unix side of the serial line, type +@c OBSOLETE the following at the DOS console: +@c OBSOLETE +@c OBSOLETE @example +@c OBSOLETE C:\> CTTY com1 +@c OBSOLETE @end example +@c OBSOLETE +@c OBSOLETE @noindent +@c OBSOLETE (Later, if you wish to return control to the DOS console, you can use +@c OBSOLETE the command @code{CTTY con}---but you must send it over the device that +@c OBSOLETE had control, in our example over the @file{COM1} serial line.) +@c OBSOLETE +@c OBSOLETE From the Unix host, use a communications program such as @code{tip} or +@c OBSOLETE @code{cu} to communicate with the PC; for example, +@c OBSOLETE +@c OBSOLETE @example +@c OBSOLETE cu -s 9600 -l /dev/ttya +@c OBSOLETE @end example +@c OBSOLETE +@c OBSOLETE @noindent +@c OBSOLETE The @code{cu} options shown specify, respectively, the linespeed and the +@c OBSOLETE serial port to use. If you use @code{tip} instead, your command line +@c OBSOLETE may look something like the following: +@c OBSOLETE +@c OBSOLETE @example +@c OBSOLETE tip -9600 /dev/ttya +@c OBSOLETE @end example +@c OBSOLETE +@c OBSOLETE @noindent +@c OBSOLETE Your system may require a different name where we show +@c OBSOLETE @file{/dev/ttya} as the argument to @code{tip}. The communications +@c OBSOLETE parameters, including which port to use, are associated with the +@c OBSOLETE @code{tip} argument in the ``remote'' descriptions file---normally the +@c OBSOLETE system table @file{/etc/remote}. +@c OBSOLETE @c FIXME: What if anything needs doing to match the "n,8,1,none" part of +@c OBSOLETE @c the DOS side's comms setup? cu can support -o (odd +@c OBSOLETE @c parity), -e (even parity)---apparently no settings for no parity or +@c OBSOLETE @c for character size. Taken from stty maybe...? John points out tip +@c OBSOLETE @c can set these as internal variables, eg ~s parity=none; man stty +@c OBSOLETE @c suggests that it *might* work to stty these options with stdin or +@c OBSOLETE @c stdout redirected... ---doc@cygnus.com, 25feb91 +@c OBSOLETE @c +@c OBSOLETE @c There's nothing to be done for the "none" part of the DOS MODE +@c OBSOLETE @c command. The rest of the parameters should be matched by the +@c OBSOLETE @c baudrate, bits, and parity used by the Unix side. ---Eli Zaretskii, 3Sep99 +@c OBSOLETE +@c OBSOLETE @kindex EBMON +@c OBSOLETE Using the @code{tip} or @code{cu} connection, change the DOS working +@c OBSOLETE directory to the directory containing a copy of your 29K program, then +@c OBSOLETE start the PC program @code{EBMON} (an EB29K control program supplied +@c OBSOLETE with your board by AMD). You should see an initial display from +@c OBSOLETE @code{EBMON} similar to the one that follows, ending with the +@c OBSOLETE @code{EBMON} prompt @samp{#}--- +@c OBSOLETE +@c OBSOLETE @example +@c OBSOLETE C:\> G: +@c OBSOLETE +@c OBSOLETE G:\> CD \usr\joe\work29k +@c OBSOLETE +@c OBSOLETE G:\USR\JOE\WORK29K> EBMON +@c OBSOLETE Am29000 PC Coprocessor Board Monitor, version 3.0-18 +@c OBSOLETE Copyright 1990 Advanced Micro Devices, Inc. +@c OBSOLETE Written by Gibbons and Associates, Inc. +@c OBSOLETE +@c OBSOLETE Enter '?' or 'H' for help +@c OBSOLETE +@c OBSOLETE PC Coprocessor Type = EB29K +@c OBSOLETE I/O Base = 0x208 +@c OBSOLETE Memory Base = 0xd0000 +@c OBSOLETE +@c OBSOLETE Data Memory Size = 2048KB +@c OBSOLETE Available I-RAM Range = 0x8000 to 0x1fffff +@c OBSOLETE Available D-RAM Range = 0x80002000 to 0x801fffff +@c OBSOLETE +@c OBSOLETE PageSize = 0x400 +@c OBSOLETE Register Stack Size = 0x800 +@c OBSOLETE Memory Stack Size = 0x1800 +@c OBSOLETE +@c OBSOLETE CPU PRL = 0x3 +@c OBSOLETE Am29027 Available = No +@c OBSOLETE Byte Write Available = Yes +@c OBSOLETE +@c OBSOLETE # ~. +@c OBSOLETE @end example +@c OBSOLETE +@c OBSOLETE Then exit the @code{cu} or @code{tip} program (done in the example by +@c OBSOLETE typing @code{~.} at the @code{EBMON} prompt). @code{EBMON} keeps +@c OBSOLETE running, ready for @value{GDBN} to take over. +@c OBSOLETE +@c OBSOLETE For this example, we've assumed what is probably the most convenient +@c OBSOLETE way to make sure the same 29K program is on both the PC and the Unix +@c OBSOLETE system: a PC/NFS connection that establishes ``drive @file{G:}'' on the +@c OBSOLETE PC as a file system on the Unix host. If you do not have PC/NFS or +@c OBSOLETE something similar connecting the two systems, you must arrange some +@c OBSOLETE other way---perhaps floppy-disk transfer---of getting the 29K program +@c OBSOLETE from the Unix system to the PC; @value{GDBN} does @emph{not} download it over the +@c OBSOLETE serial line. +@c OBSOLETE +@c OBSOLETE @node gdb-EB29K +@c OBSOLETE @subsubsection EB29K cross-debugging +@c OBSOLETE +@c OBSOLETE Finally, @code{cd} to the directory containing an image of your 29K +@c OBSOLETE program on the Unix system, and start @value{GDBN}---specifying as argument the +@c OBSOLETE name of your 29K program: +@c OBSOLETE +@c OBSOLETE @example +@c OBSOLETE cd /usr/joe/work29k +@c OBSOLETE @value{GDBP} myfoo +@c OBSOLETE @end example +@c OBSOLETE +@c OBSOLETE @need 500 +@c OBSOLETE Now you can use the @code{target} command: +@c OBSOLETE +@c OBSOLETE @example +@c OBSOLETE target amd-eb /dev/ttya 9600 MYFOO +@c OBSOLETE @c FIXME: test above 'target amd-eb' as spelled, with caps! caps are meant to +@c OBSOLETE @c emphasize that this is the name as seen by DOS (since I think DOS is +@c OBSOLETE @c single-minded about case of letters). ---doc@cygnus.com, 25feb91 +@c OBSOLETE @end example +@c OBSOLETE +@c OBSOLETE @noindent +@c OBSOLETE In this example, we've assumed your program is in a file called +@c OBSOLETE @file{myfoo}. Note that the filename given as the last argument to +@c OBSOLETE @code{target amd-eb} should be the name of the program as it appears to DOS. +@c OBSOLETE In our example this is simply @code{MYFOO}, but in general it can include +@c OBSOLETE a DOS path, and depending on your transfer mechanism may not resemble +@c OBSOLETE the name on the Unix side. +@c OBSOLETE +@c OBSOLETE At this point, you can set any breakpoints you wish; when you are ready +@c OBSOLETE to see your program run on the 29K board, use the @value{GDBN} command +@c OBSOLETE @code{run}. +@c OBSOLETE +@c OBSOLETE To stop debugging the remote program, use the @value{GDBN} @code{detach} +@c OBSOLETE command. +@c OBSOLETE +@c OBSOLETE To return control of the PC to its console, use @code{tip} or @code{cu} +@c OBSOLETE once again, after your @value{GDBN} session has concluded, to attach to +@c OBSOLETE @code{EBMON}. You can then type the command @code{q} to shut down +@c OBSOLETE @code{EBMON}, returning control to the DOS command-line interpreter. +@c OBSOLETE Type @kbd{CTTY con} to return command input to the main DOS console, +@c OBSOLETE and type @kbd{~.} to leave @code{tip} or @code{cu}. +@c OBSOLETE +@c OBSOLETE @node Remote Log +@c OBSOLETE @subsubsection Remote log +@c OBSOLETE @cindex @file{eb.log}, a log file for EB29K +@c OBSOLETE @cindex log file for EB29K +@c OBSOLETE +@c OBSOLETE The @code{target amd-eb} command creates a file @file{eb.log} in the +@c OBSOLETE current working directory, to help debug problems with the connection. +@c OBSOLETE @file{eb.log} records all the output from @code{EBMON}, including echoes +@c OBSOLETE of the commands sent to it. Running @samp{tail -f} on this file in +@c OBSOLETE another window often helps to understand trouble with @code{EBMON}, or +@c OBSOLETE unexpected events on the PC side of the connection. @node ARM @subsection ARM -- cgit v1.1