request for assistance in understanding undocumented gas directives

request for assistance in understanding undocumented gas directives

[Daniel Wilkerson]

I want to write a assembly language simulator for purposes of dynamic
semantic analysis (rather than for performance).  Note that I need the
debugging annotations so I can map things back to the higher-level
constructs they came from; think of the needs of gdb.

I thought I would try MIPS64, but I might also try other 64-bit
architectures (MIPS seems to be cleanly designed and "See MIPS Run" is
very well written).  I would simulate ELF/DWARF files directly but
they are harder to generate (LLVM will gen assembly, but won't
assemble it for you) and I don't know a library to read them that
isn't GPL3 (I don't want to be required to GPL my code.)

As Clang/LLVM is designed to cross-compile out of the box (unlike
gcc), the straightforward way to generate test input seems to be
"clang -target mips64 -S -O0 -g".  The output seems to be MIPS64
assembly in the GNU as format.  Further, if I omit the "-target
mips64" argument, then clang -S does generate x86 assembly that my
native gcc install will assemble and the result does run.  Examining
the output, it contains many of the directives that I see in online
copies of the GNU assembler manual, so, as far as I can tell, it seems
to be GNU as code.

Unfortunately, it also contains uses of odd assembler directives that
I can't find explained in the online GNU documentation: .abicalls,
.fmask, a use of .previous in what seems to be the first section,
which doesn't make sense as far as I understand.  Also, much of the
debugging information is encoded in blocks of binary.  This
documentation: https://sourceware.org/binutils/docs-2.22/as/Loc.html#Loc
speaks of DWARF2, when I think DWARF4 is current.  I don't know if I
should as you guys or the LLVM guys, but if I want to make sense of
this, where do I find up to date documentation?

Daniel

Re: request for assistance in understanding undocumented gas directives

[Nicholas Clifton]

Hi Daniel,

> 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:

   https://sourceware.org/binutils/docs-2.24/

> .abicalls,
> .fmask,

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 
severely lacking.


> 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 
good programming.


> 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 
option.


Cheers
   Nick

Re: request for assistance in understanding undocumented gas directives

[Ian Lance Taylor]

On Tue, Jul 1, 2014 at 2:39 AM, Nicholas Clifton <nickc@redhat.com> wrote:
>
> The .fmask directive appears to be part of some kind of debug information
> generation facility, although again documentation is severely lacking.

As I recall, .mask and .fmask set the values that are stored in the
.pdr section.  See the -mpdr and -mno-pdr options.  The .pdr section
holds runtime procedure descriptors that are used for stack unwinding
on some MIPS systems.

I doubt anything uses this information any more.

Ian

Re: request for assistance in understanding undocumented gas directives

[Daniel Wilkerson]

Thanks.  From p.7-5 and p.8-6 / table 8-1 (below) of
http://www.tik.ee.ethz.ch/education/lectures/TI1/materials/assemblylanguageprogdoc.pdf
it seems to indicate which registers are saved.  I cannot tell however
if it actually performs said saving of the registers or merely
annotates that they somehow should be saved.

---- .mask

Sets a mask with a bit turned on for each general purpose register
that the current routine saved. Bit one corresponds to register $1.
The offset is the distance in bytes from the virtual frame pointer
where the registers are saved. The assembler saves higher
register numbers closer to the virtual frame pointer. Space should
be allocated for those registers appearing in the mask. If bit zero is
set it is assumed that space is allocated for all 31 registers
regardless of whether they appear in the mask. (For use by
compilers).

On Tue, Jul 1, 2014 at 2:21 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Tue, Jul 1, 2014 at 2:39 AM, Nicholas Clifton <nickc@redhat.com> wrote:
>>
>> The .fmask directive appears to be part of some kind of debug information
>> generation facility, although again documentation is severely lacking.
>
> As I recall, .mask and .fmask set the values that are stored in the
> .pdr section.  See the -mpdr and -mno-pdr options.  The .pdr section
> holds runtime procedure descriptors that are used for stack unwinding
> on some MIPS systems.
>
> I doubt anything uses this information any more.
>
> Ian

Re: request for assistance in understanding undocumented gas directives

[Ian Lance Taylor]

On Wed, Jul 2, 2014 at 1:05 PM, Daniel Wilkerson
<daniel.wilkerson@gmail.com> wrote:
>
> Thanks.  From p.7-5 and p.8-6 / table 8-1 (below) of
> http://www.tik.ee.ethz.ch/education/lectures/TI1/materials/assemblylanguageprogdoc.pdf
> it seems to indicate which registers are saved.  I cannot tell however
> if it actually performs said saving of the registers or merely
> annotates that they somehow should be saved.

It merely annotates.

Ian