Re: Questions regarding submittals

[Jeffrey A Law <law@cygnus.com>]

  In message <199809072053.VAA01106@phal.cygnus.co.uk>you write:
  > > The hack that I used is to create a new pseudo directive in gas called
  > > .compiler that takes a string argument in order to update the Compilation
  > > Unit for each module. I modified ASM_IDENTIFY_GCC to include this pseudo
  > > directive. However, that also means I needed to include the directive in
  > > gcc/config/pa/*.asm. For MPE and the HP3000, that's OK because gas is the
  > > only assembler available there. However, on HP-UX it is possible to not 
  > > use gas, and these directives would break that assembler.
  > > 
  > > Is there a better way to approach this in order to communicate the pertin
  > ent
  > > information to gas in order to generate the SOM Compilation Unit records 
  > > in BFD for MPE without breaking things elsewhere?
  > 
  > Where the existing ports need to emit this information, they use
  > FILE_ASM_OP - usually defined to something like file or .file,
  > or better, output_file_directive .
  > output_file_directive uses ASM_OUTPUT_MAIN_SOURCE_FILENAME or
  > ASM_OUTPUT_SOURCE_FILENAME, if defined.
  > 
  > output_file_directive can be called from ASM_FILE_START; e.g. look at
  > config/svr4.h .
.file already has a well defined syntax and meaning for gas and is
already in use on the PA port (note that PA port can not, does not,
and will not use svr4.h :-)

I believe Mark needs to pass more information than is available in a
.file directive.

I also believe it makes more sense from an assembler language standpoint
to have a clearer mapping from the assembler directive to what happens
in the object file.  Thus I would prefer .compiler,  .compilation_unit
or something like that over .file.



jeff