Linker problems with arm-wince, need help/info

[Pedro Alves]

One more thing.
There is usually a #define USER_LABEL_PREFIX "_" or #define USER_LABEL_PREFIX ""
in gcc/config/$arch/someheader.h. In cegcc it is defined as USER_LABEL_PREFIX "".
Maybe that isn't being used in the D frontend and an '_' is preppended unconditionally?


Pedro Alves wrote:

> Chad J wrote:
>
>> pedro alves wrote:
>>
>>> That's what I meant :) An extern (C) main in phobos that does all 
>>> the setup and then calls a _Dmain. I even guessed the name right :)
>>>
>>> $ grep main 1nm.txt 00000024 R __D3gcc6config21dirent_remaining_sizek
>>> 00000a38 T __D3std4math9remainderFeeZe
>>>         U _remainder
>>> dgccmain2.o:
>>> 00000094 T __d_run_main
>>> 00000000 t __d_run_main2goFZv
>>> rundmain.o:
>>>         U __Dmain            <------- probably the D main in app code.
>>> 00000000 T __d_run_Dmain
>>>         U __d_run_main
>>> cmain.o:
>>>         U __Dmain
>>>         U ___gccmain
>>>         U __d_run_main
>>> 00000000 T _main           <------- look here, it is underscored :)
>>>
>>> So main is being underscored. Take a look at where that _main 
>>> (should be main in source form) is defined. I would guess,
>>> that it is implemented in D with extern (C). I think the D frontend 
>>> will need to be extended to support -fno-leading-underscore, at 
>>> least for
>>> extern (C) function calls/declarations, but I guess supporting it 
>>> for *all* function decls/calls will be easier, probably there will 
>>> be a single function that
>>> handles the mangling. Look for that.
>>
>>
>> I tried looking through the frontend.  There was a file dedicated to 
>> mangling (gcc/d/dmd/mangle.c).  I still can't figure out where the 
>> underscoring is handled, at least for C linkage.  I tried one obvious 
>> looking line change, but it didn't fix the C linkage at all.  I feel 
>> kinda helpless in the frontend, as I do not know much about compiler 
>> internals, much less GCC internals.  Maybe David can help here? Please?
>>
> Try putting a breakpoint there and stepping until the underscore is 
> prepended. I don't know much about these parts of gcc either.
>
>> I also don't understand why this would have any effect on D linkage 
>> like _D3std4file5writeFAaAvZv, at least that seems to be D linkage 
>> since it has the module name and the trailing type info.  
>
>
> Well, to the linker, it is just a symbol like all the others. The 
> mangling is there to make the function name unique, so you can have 
> overloading at the D level, but to the linker, it has
> no difference to any other C function or ASM function. The thing is, 
> the mangler converts (i'm guessing the name now) std.file.write(...) 
> into _D3std4file5writeFAaAvZv, but somewhere
> between that and the emitting to the .s file that gets passed to the 
> assembler, an underscore is prepended to the symbol, turning it into 
> __D3std4file5writeFAaAvZv.
> Find the place where this underscore is added, and disabled it. That's 
> the place the -fno-leading-underscore should be respected. You can 
> also grep the gcc sources to see
> where that switch is handled for c and c++, and do the same.
>
>> With respect to underscoring, does the linker handle symbols any 
>> differently than say, an x86 linker?
>
>
> With respect to underscoring, yes, it accounts for the underscore when 
> the target is underscored, and doesn't, when the target isn't. You can 
> look at binutils/ld/pe-dll.c to see it in action.
> I have some hacks in cegcc's version of binutils that are needed here. 
> Grep for "pedro" there if you are curious :)
>
> ...
>
> I looked at the attatchment you sent. Well, you definitily have an 
> underscoring mismatch.
>
> Another thing. If after you fix this underscoring business you stil 
> get errors like:
> /root/gcc/gdc-4.0.3/libphobos/std/typeinfo/ti_creal.d:31: variable 
> '___gtdf2' can't be auto-imported. Please read the documentation for 
> ld's --enable-auto-import for details.
>
> You will need to use the --enable-runtime-pseudo-reloc linker switch, 
> but that needs runtime support, that mamaich's toolchain doesn't have. 
> Luckily, cegcc has it :)
>
> Cheers,
> Pedro Alves