Re: [Patch] add support for alpha/vms archives

[Tristan Gingold <gingold at adacore dot com>]

Hartmut,

please do be too picky, as this is a first implementation that will be improved.  I plan to submit my new
version of the alpha vms back-end and archives were part of that.  I also plan to support ia64.

On Apr 3, 2010, at 4:20 PM, h.becker wrote:

>> + /* Create module name from filename (ie, extract the basename and convert it
>> +    in upper cases).  Works on both VMS and UNIX pathes.
>> +    The result has to be free().  */
> In VMS archives (object libraries) member names, aka module names, are independent of the filename. These names are set by the so called language processor, the compilers, etc. Many compilers by default use the filename, but sources can have a module directive to set a name. Some compilers use different default names, for example MACRO32 uses ".MAIN.".
> In general, module names build their own name space. For example, .MAIN. wouldn't be a legal filename on an ODS2 disks.

Yes, I recently discovered this while working on a message file.  I plan to fix that.

> Also, although not often used, an object file can contain more than one object module.

Interesting.  How can such an object file be built ?

> So the module name should be extracted from the Module Header Record.

That's right.

>> + time_t
>> + vms_time_to_time_t (unsigned int hi, unsigned int lo)
> Is there any reason why binutils are not allowed to use "long long" and 64-bit arithmetic?

64 bit arithmetic is not always available.  This file could be useful for the VAX back-end, which will not
require 64 bits.


>> +   /* Check archive kind.  */
>> +   switch (kind)
>> +     {
>> +     case vms_lib_alpha:
>> +       if ((lhd.type != LBR__C_TYP_EOBJ && lhd.type != LBR__C_TYP_ESHSTB)
>> +           || bfd_getl32 (lhd.majorid) != 3
>> +           || lhd.nindex != 2)
>> +         {
>> +           bfd_set_error (bfd_error_wrong_format);
>> +           return NULL;
>> +         }
>> +       break;
>> +     case vms_lib_txt:
>> +       if ((lhd.type != LBR__C_TYP_TXT
>> +            && lhd.type != LBR__C_TYP_MLB
>> +            && lhd.type != LBR__C_TYP_HLP)
>> +           || bfd_getl32 (lhd.majorid) != 3
>> +           || lhd.nindex != 1)
>> +         {
>> +           bfd_set_error (bfd_error_wrong_format);
>> +           return NULL;
>> +         }
>> +       break;
>> +     default:
>> +       abort ();
>> +     }
> I didn't check the whole submission, so seeing this makes me wonder why text libraries seem to be allowed/supported, here. Later, I do see
>> + /* Add a target for text library.  This costs almost nothing and is useful to
>> +    read VMS library on the host.  */
> but I'm not sure what will be read, here.

The purpose of this is to be able to handle text libraries.  That useful to read header or help files on
unix.

>> + /* Build the symbols index.  */
>> + + static bfd_boolean
>> + _bfd_vms_lib_build_map (unsigned int nbr_modules,
>> +                         struct vms_index *modules,
>> +                         unsigned int *res_cnt,
>> +                         struct vms_index **res)
>> + {
> From a quick look I don't see it, so: Do you reject (or plan to reject) the module if a symbol from the to be added module is already in the archive?

Good catch.  Indeed this have to be done.

>> +               if ((flags & BSF_GLOBAL
>> +                    || flags & BSF_WEAK
>> +                    || flags & BSF_INDIRECT
>> +                    || bfd_is_com_section (sec))
>> +                   && ! bfd_is_und_section (sec))
> 
> I may misinterpret the code, but VMS weak symbols and PSECT names are not in the global symbol table of a VMS object library.

You're right for weak symbols (that's a frequent semantic mismatch between archives).  For PSECT names, I
think that they are not put in the BFD symbol table.  To be checked.

Thank you for all your comment.  I have to continue the work!

Tristan.