This is the mail archive of the
mailing list for the binutils project.
Re: request for assistance in understanding undocumented gas directives
- From: Nicholas Clifton <nickc at redhat dot com>
- To: Daniel Wilkerson <daniel dot wilkerson at gmail dot com>, binutils at sourceware dot org
- Date: Tue, 01 Jul 2014 10:39:44 +0100
- Subject: Re: request for assistance in understanding undocumented gas directives
- Authentication-results: sourceware.org; auth=none
- References: <CALzRTRnGBUYh-NQi+2--T0bNTA845911-Hg0EgL-aX=zRaGE6A at mail dot gmail dot com>
Unfortunately, it also contains uses of odd assembler directives that
I can't find explained in the online GNU documentation:
Note - the 2,22 documentation is now out of date. Assuming that you are
using the latest release of the binutils, you should be looking at the
2.24 documentation, which can be found here:
Not that the 2.24 documentation will help you with these. This is a
snafu - the directives should be documented. As usual though, the
source code is your friend. In gas/config/tc-mips.c there is this comment:
The following pseudo-ops from the Kane and Heinrich MIPS book are
not MIPS CPU specific, but are also not specific to the object file
format. This file is probably the best place to define them, but
Which implies that you need to obtain a copy of "MIPS RISC Architecture"
in order to proceed. But later on there is this:
/* Handle the .abicalls pseudo-op. I believe this is equivalent to
.option pic2. It means to generate SVR4 PIC calls. */
Which might help a bit.
The .fmask directive appears to be part of some kind of debug
information generation facility, although again documentation is
a use of .previous in what seems to be the first section,
which doesn't make sense as far as I understand.
It is probably there for safety, In case there was a previous section.
Ie the .previous is probably being generated by code in the compiler
which might be used anywhere, not just at the start of the assembler
output. So using a .previous to restore a saved current section is just
Also, much of the
debugging information is encoded in blocks of binary.
Presumably this debug information is being generated by the *compiler*
and not the *assembler*. Thus you need to tell the compiler to annotate
its debugging output. With gcc this would be via the -dA command line