Questions regarding submittals

Questions regarding submittals

[Mark Klein]

I'm about to submit my changes to bfd, gas and egcs for my port of same
to the HP3000. However, before I do so, I have an ugly hack that I'd
like to discuss to see if maybe there is a better way to accomplish what
I need.

When doing an extract from a library on the HP3000, MPE requires that the
SOM Compilation Unit entries be filled in for each module, otherwise the
extract results in a object named UNNAMED.o. When extracting the various
tmplib*.a libraries to combine into libgcc.a, all the objects with the 
exception of the last object get lost as they keep overwriting UNNAMED.o.

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 pertinent
information to gas in order to generate the SOM Compilation Unit records 
in BFD for MPE without breaking things elsewhere?

Thanks in advance,


Mark
--
Mark Klein                                      DIS International, Ltd.
http://www.dis.com                              415-892-8400
PGP Public Key Available			Remove "nospam" to reply.

Re: Questions regarding submittals

[Joern Rennecke]

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

Re: Questions regarding submittals

[Jeffrey A Law]

  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

Re: Questions regarding submittals

[Joern Rennecke]

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

Does he?  That's not how I have read his message.
Mark, what information do you need to pass?

Re: Questions regarding submittals

[Mark Klein]

At 09:04 PM 9/8/98 +0100, Joern Rennecke wrote:
>> I believe Mark needs to pass more information than is available in a
>> .file directive.
>
>Does he?  That's not how I have read his message.
>Mark, what information do you need to pass?

While it is true that all I require is the filename, MPE needs a complete
compilation unit entry in the SOM. 

The compilation unit is:

struct compilation_unit {
        union name_pt    name; 
        union name_pt    language_name; 
        union name_pt    product_id; 
        union name_pt    version_id; 
        union name_pt    copyright; 
        struct sys_clock compile_time; 
        struct sys_clock source_time; 
}; 

Since I must create the entire entry, it is best to make it mean something
legitimate, so I chose to include the compiler information and version in
the meta command as in:

; gcc_compiled.:
   .compiler "hello.c GNU_C_Compiler egcs-2.91.52 19980727 (gcc2 ss-980609
experimental)"

This yields:

/OFFICIAL/PUB/ODUMP -compunit ./a.out

Compilation Unit Dictionary from ./a.out[0]:

Index Chunk     Language                                    Name
        Product_id ; Version_id 
        Compile time ; Source time

   0   0  GNU_C_Compiler                                     hello.c        
                                                            
          GNU Tools; egcs-2.91.52 19980727 (gcc2 ss-980609 experimental) 
          Compile Time: None
          Source  Time: None

   1   0  GNU_C_Compiler                                     ./libgcc2.c    
                                                            
          GNU Tools; egcs-2.91.52 19980727 (gcc2 ss-980609 experimental) 
          Compile Time: None
          Source  Time: None

   2   0  GNU_C_Compiler                                     ./libgcc2.c    
                                                            
          GNU Tools; egcs-2.91.52 19980727 (gcc2 ss-980609 experimental) 
          Compile Time: None
          Source  Time: None

   3   0  GNU_PA-RISC_Assembler                              lib2funcs.asm  
                                                            
          GNU Tools; 2.8.1 
          Compile Time: None
          Source  Time: None

   4   0  GNU_PA-RISC_Assembler                              mpebreak.asm   
                                                            
          GNU Tools; 2.8.1 
          Compile Time: None
          Source  Time: None

   5   0  HP C/XL                                            CSGLIB         
          ccxl options =  +O2 -Aa                           
          HP31506; HP C/iX Compiler Version A.04.50  
          Compile Time:  Mon Jul  8 12:05:47 1996 000000000
          Source  Time: None

   6   0  HP-C                                               exit           
          cc options =  +O2 -Aa                             
          HP92453-01; A.08.81 
          Compile Time:  Tue Jun 21 13:51:10 1994 000000000
          Source  Time:  Tue Jan 25 10:55:21 1994 000000000

[snip]

  52   0  HPUX Precision Architecture Assembler
MILLI/12.34/MremU.o

                                                            
          92453; A.08.00(sllic UX.08.00.00 10/25/89) 
          Compile Time: None
          Source  Time: None


/tmp(149): 

I'm not sure what would happen to MPE's tools if they found an incomplete
compilation
unit, but it is better to be complete, IMHO.
--
Mark Klein                                              DIS International,
Ltd.
http://www.dis.com                                      415-892-8400
PGP Public Key Available