From: antispam@fricas.org   
      
   Waldek Hebisch  wrote:   
   > Craig A. Berry  wrote:   
   >>   
   >> On 9/5/25 6:55 AM, Waldek Hebisch wrote:   
   >>   
   >>> I now got to C++ problem.  In fact, this may be binutils problem:   
   >>> gcc generates an assember file and as from binutils-2.21 aborts on   
   >>> this file.  as from current binutils developement tree produces   
   >>> error message instead:   
   >>>   
   >>> pom/kompi/gcc/binu-build3/gas/as-new -o array_type_info.obj    
   rray_type_info.s   
   >>> array_type_info.s: Assembler messages:   
   >>> array_type_info.s: Error: no entry symbol for global function   
   '_ZN10__cxxabiv117__array_type_infoD1Ev'   
   >>>   
   >>> The offending function is defined in the following way:   
   >>>   
   >>>          .globl _ZN10__cxxabiv117__array_type_infoD1Ev   
   >>>          _ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxx   
   biv117__array_type_infoD2Ev   
   >>>   
   >>> If I delete this definition and the ony use of it the file assembles OK.   
   >>> AFAICS this means that _ZN10__cxxabiv117__array_type_infoD2Ev is correctly   
   >>> defined.   
   >>   
   >> Note that this symbol is 38 characters long.  The native VMS toolchain   
   >> traditionally limits itself to 31-character symbols and uses a checksum   
   >> to shorten symbols that are longer.  The linker, the librarian, and the   
   >> inertia of existing code are all things I've heard blamed for this state   
   >> of affairs.   
   >>   
   >> I have no idea whether the tools you are using require or are capable of   
   >> observing the 31-character limit.  If some parts do and other parts   
   >> don't, that could obviously cause trouble, and of course you've got the   
   >> C++ name mangler in the mix as well.   
   >   
   > IIUC GNU assembler internaly uses arbitrarily long names (in dynamically   
   > allocated buffers) and shortens names only on output.  Anyway, I   
   > tried shorthening names in the input file and it makes no difference.   
   >   
   > All indicates that GNU assembler can not handle simple symbol   
   > equality as intended.  Namely relevant part of original code   
   > including definitions of _ZN10__cxxabiv117__array_type_infoD2Ev   
   > and _ZN10__cxxabiv117__array_type_infoD1Ev is:   
   >   
   >         .link   
   >         .align 3   
   > _ZN10__cxxabiv117__array_type_infoD2Ev:   
   >         .pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack   
   > $80.._ZNSt9type_infoD2Ev..lk:   
   >         .linkage _ZNSt9type_infoD2Ev   
   >         .end _ZN10__cxxabiv117__array_type_infoD2Ev   
   >         .globl _ZN10__cxxabiv117__array_type_infoD1Ev   
   >         _ZN10__cxxabiv117__array_type_infoD1Ev = _ZN10__cxxabi   
   117__array_type_infoD2Ev   
   >   
   > The intent is clearly that _ZN10__cxxabiv117__array_type_infoD1Ev   
   > should be alternative name for _ZN10__cxxabiv117__array_type_infoD2Ev,   
   > but for some reasons assembler can not handle this.  AFAICS GNU   
   > assembler for VMS believes that that given function should have   
   > only one name.  For example I tried to transform fragment above   
   > to:   
   >   
   >         .link   
   >         .align 3   
   > _ZN10__cxxabiv117__array_type_infoD2Ev:   
   >         .pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack   
   > $80.._ZNSt9type_infoD2Ev..lk:   
   >         .linkage _ZNSt9type_infoD2Ev   
   >         .end _ZN10__cxxabiv117__array_type_infoD2Ev   
   >         .globl _ZN10__cxxabiv117__array_type_infoD1Ev   
   >         .ent _ZN10__cxxabiv117__array_type_infoD1Ev   
   > _ZN10__cxxabiv117__array_type_infoD1Ev:   
   >         .pdesc _ZN10__cxxabiv117__array_type_infoD2Ev..en,stack   
   >         .linkage _ZNSt9type_infoD2Ev   
   >         .end _ZN10__cxxabiv117__array_type_infoD2Ev   
   >   
   > that is I actually build second descriptor duplicating content of   
   > descriptor for _ZN10__cxxabiv117__array_type_infoD2Ev and GNU   
   > assembler still does not want to accept this.  More precisely,   
   > version  2.21 gives the same error message as original code,   
   > current trunk says:   
   >   
   > at3.s: Assembler messages:   
   > at3.s:55: Fatal error: .pdesc doesn't match with last .ent   
   >   
   > I do not know if VMS object format allows alternative names,   
   > that is two symbols resolving to the same name (but I also   
   > am not aware of any reason for such restriction), but even   
   > if there were such restriction version with duplicate descriptor   
   > should work around this.   
      
   I have tried to do similar thing using DEC assembler and arrived   
   at the following routine:   
      
       .title t2.s   
       .psect  $code,shr,exe,nowrt,quad,pic   
       .align  quad   
   $ROUTINE ts_fun1, KIND = stack, -   
       SAVED_REGS =    
       .base       r27, $LS   
       $RETURN   
   $END_ROUTINE   
   ts_fun2 == ts_fun1   
      
   That apparently assembles OK.  But ts_fun2 is defined as data   
   symbol and trying to call it leads to link failure.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)