[Info-vax] IA64 assembler file in shared image - ILINK-W-NOTPMTIDX

hb end.of at inter.net
Sat Mar 21 21:03:26 EDT 2015


On 03/21/2015 06:20 PM, John E. Malmberg wrote:
> On 3/21/2015 3:17 AM, hb wrote:
>> On 03/21/2015 05:54 AM, Michael Moroney wrote:
>>> "John E. Malmberg" <wb8tyw at qsl.network> writes:
>> ...
>>>> %ILINK-W-NOTPMTIDX,  section (index 0x00000000) encountered when trying
>>>> to index PMT
>>>>          module: UNIX
>>>>          file: LCL_ROOT:[libffi.ia64-dec-vms.libs]libffi.a;1
>>>> %ILINK-W-NOTPMTIDX,  section (index 0x00000000) encountered when trying
>>>> to index PMT
>>>>          module: UNIX
>>>>          file: LCL_ROOT:[libffi.ia64-dec-vms.libs]libffi.a;1
>> ...
>>> $ help/message NOTPMTIDX
>>>
>>>   NOTPMTIDX,  'symbol-type' symbol (index 0x'hexadecimal-number')
>>>               encountered when trying to index PMT
>>>          module: 'module-name'
>>>          file: 'file-name'
>>>
>>>    Facility:     ILINK, OpenVMS I64 Linker Utility
>>>
>>>    Explanation:  The section index is not identifiable as a valid
>>> section index
>>>                  by the linker.
>>
>> Symbol-type is not shown, here. So it is likely a local symbol causing
>> this. Check with analyze/object/section=symtab for (local) symbols which
>> have a shndx of 0 (analyze labels this field with "Bound to section:").
>> For a local symbol this would mean an undefined one, which the linker
>> has no chance to resolve (from where???). So itis a problem in the
>> object which the linker reports.
>
> SYMBOL 23.
> "OTS$MOVE" bound to section 0. (SHDR$K_SHN_UNDEF) symtab$w_st_shndx
>
> SYMBOL 24.
> "ffi_closure_unix_inner"  Bound to section  0.
>        (SHDR$K_SHN_UNDEF)           symtab$w_st_shndx

ffi_closure_unix_inner and OTS$MOVE are undefined global symbols, which 
are OK. I expected an undefined local symbol in the symbol table. There 
is no such thing.

But there are ltoff22x relocations, hand coded in the source, for which 
the assembler generates ldxmov relocations, for optimization. The ldxmov 
specifies a non-existing (local) symbol index. So the linker complains.

If I patch the object with the correct local symbol index, the linker 
doesn't print any warning.

Patching is probably not what you want to do, here. But you can make the 
two symbols used in the "ltoff22x"s global. Then the correct symbols are 
used and the linker warning is gone.



More information about the Info-vax mailing list