From: antispam@fricas.org
Dan Cross wrote:
> In article <109mep8$84ft$1@paganini.bofh.team>,
> Waldek Hebisch wrote:
>>Dan Cross wrote:
>>> In article <109g1s1$3jb20$1@paganini.bofh.team>,
>>> Waldek Hebisch wrote:
>>>>Lawrence Dâ??Oliveiro wrote:
>>>>> On Fri, 5 Sep 2025 21:32:01 -0000 (UTC), Waldek Hebisch wrote:
>>>>>
>>>>>> All indicates that GNU assembler can not handle simple symbol
>>>>>> equality as intended.
>>>>>
>>>>> I tried creating a source file test.s containing just your two problem
>>>>> lines:
>>>>>
>>>>> .globl _ZN10__cxxabiv117__array_type_infoD1Ev
>>>>> _ZN10__cxxabiv117__array_type_infoD1Ev =
>>_ZN10__cxxabiv117__array_type_infoD2E
>>>>>
>>>>> and when I try to assemble it,
>>>>>
>>>>> gcc -c test.s
>>>>>
>>>>> there is no error, and test.o is created OK. Trying objdump on it
>>>>>
>>>>> objdump -t test.o
>>>>>
>>>>> shows it has the correct symbol reference in it, albeit undefined:
>>>>>
>>>>> test.o: file format elf64-x86-64
>>>>>
>>>>> SYMBOL TABLE:
>>>>> 0000000000000000 *UND* 0000000000000000
>>_ZN10__cxxabiv117__array_type_infoD2E
>>>>>
>>>>> So no, the issue is not with those two particular lines on their own.
>>>>> Something else is involved.
>>>>
>>>>Yes. AFAICS main issue is creating alias name for an exported
>>>>function. Internal aliases work fine. Probably data aliases too.
>>>
>>> I caution against putting it in those terms. What you are doing
>>> in GNU `as` when you use the `a = e` syntax is creating a symbol
>>> called "a" from that is set to the evalue of some expression.
>>> In this contrived example, that expression is just "e", which I
>>> used as a stand-in for any arbitrary expression, but if taken
>>> literally, would just be valuated to the value of some other
>>> symbol, called "e". If "e" was not defined already, it is
>>> assumed to be an external.
>>>
>>> When you assemble troll's file, an object file is generated; the
>>> results from `objdump` above show that there is a single symbol
>>> in that object file's symbol table, one you referred to when
>>> creating '_ZN10__cxxabiv117__array_type_infoD2E'. But note that
>>> '_ZN10__cxxabiv117__array_type_infoD2E' itself (the symbol that
>>> you created when you assigned to it) is not in the symbol table.
>>>
>>> However, the symbol that you created is not in the symbol table,
>>> which is the fundamental problem.
>>
>>Well, one issue is if needed construct is supported at all.
>>
>>Other platforms have code like:
>>
>> .text
>> .globl exp_fun
>> .type exp_fun, @function
>>exp_fun:
>> ret
>>.LFE0:
>> .size exp_fun, .-exp_fun
>> .globl alias_fun
>> .set alias_fun,exp_fun
>>
>>Assembling this on x86 Linux gives object file exporting two symbols:
>>exp_fun and alias_fun. IIUC this behaviour is wanted by C++
>>compiler.
>>
>>Alpha VMS needs more complicated function definition. And more
>>important: '.set alias_fun,exp_fun' causes assembler message
>>about wrong syntax.
>>
>>In DEC assembler '=' apparently gives effect that you describe:
>>new name is not exported. In DEC assembler '==' apparently creates
>>an alias, but as a data symbol. I am not aware of DEC construct
>>to get effect of '.set' as in x86 Linux example above (but up
>>to now I did not look into macro manual). So '=' probably is
>>wrong syntatx, I do not know why gcc uses it.
>
> So the GNU `as` documentation says that `a = e` has the same
> semamtics as `.set a, e`. Why isn't the Alpha version exporting
> that symbol? I don't know off the top of my head. But it's not
> specific to Alpha: my experiments were on x86. My suspcion
> is that its because it is not used in the file itself.
GNU assembler has four similar constructs: .set, .eqv, = and ==.
Generically .set is claimed to be the same as =, .eqv is claimed
to be the same as ==. But on some platforms .set and = differ
and Alpha VMS seem to one of such platforms.
I tried now '==' and it is possible that this is needed: using
it I get two text symbols which resolve to the same address.
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
