View mode: basic / threaded / horizontal-split · Log in · Help
April 08, 2006
Re: On processors for D ~ decoupling
Dave wrote:
> Might want to take a look at the gcc '-s' switch as well. Man page (under gcc
> linking options):
> 
> -s  Remove all symbol table and relocation information from the executable.
> 
> It dramatically reduces the size of the executables on my system. Don't have
> much experience with it yet though.

I would rather that not be done automatically, as often the symbols are 
needed. I think the user can run strip afterwards anyway to get the same 
result.
April 08, 2006
Re: On processors for D ~ decoupling
Walter Bright wrote:
> Dave wrote:
>> Might want to take a look at the gcc '-s' switch as well. Man page 
>> (under gcc
>> linking options):
>>
>> -s  Remove all symbol table and relocation information from the 
>> executable.
>>
>> It dramatically reduces the size of the executables on my system. 
>> Don't have
>> much experience with it yet though.
> 
> I would rather that not be done automatically, as often the symbols are 
> needed. I think the user can run strip afterwards anyway to get the same 
> result.

Ok - just thought I'd throw that out there.

- Dave
April 08, 2006
Re: On processors for D ~ decoupling
Sean Kelly wrote:
> Dave wrote:
>> Sean Kelly wrote:
>>> Walter Bright wrote:
>>>>
>>>> BTW, internal\dmain2.d also uses printf to print out an error 
>>>> message relating to any uncaught exceptions.
>>>
>>> Ares currently uses fprintf for this purpose, which is essentially 
>>> the same thing.  And as you say, it would be easy enough to hook the 
>>> function if this behavior isn't desirable.
>>>
>>> I'm glad the compiler issues came to light however.  I don't suppose 
>>> this will have any impact on the template code generation problem in 
>>> libraries?
>>
>> Sean - could you point me to some links or post some example code on 
>> this?
> 
> http://svn.dsource.org/projects/ares/trunk/src/dmdrt/dmain2.d
> 
> See the "catch" blocks near the end of the file.
> 
> 
> Sean

I still don't understand in the context of this message - what are the 
error messages you're getting?

Thanks,

- Dave
April 08, 2006
Re: On processors for D
Walter Bright wrote:
> This capability of linkers (eliminating unreferenced functions) first 
> appeared in the late 80's, and quickly became standard practice. If 
> you've got a linker that doesn't support that, you're likely to have 
> many other serious problems with it, as D (and C++) depend on other 
> linker features introduced in the late 80's.
> 
> D doesn't require anything of a linker that C++ doesn't already 
> realistically require.

Last 3 years I had to use Microsoft linker (from VS98, VS2003) and it 
really foolish (especially if compared with DMC optimizing linker).

I fulfilled investigations and it seems MS linker uses "hungry" 
algorithm - it wants any extern symbol declared in module, even if it is 
not used, then walk though all objects in libs in search for those 
symbols; meanwhile it includes all data found in that objects. After 
this cycle,  /optref switch tries to drop unreferenced functions - but a 
lot of data get linked in anyway and sometimes this unnecessary data 
references a lot of code.
Most problems we had with static objects of virtual classes - when only 
existence of such object added references for all its virtual methods 
and so on.

The only solution against this awful linker strategy was to split 
modules into *very* small files and manually predict dependencies and 
try to prevent linker from wanting something that nobody else wants.
It was hard. For previous 3 years with DMC I never needed such handwork.

Digital Mars linker is great in this field, but you definitely cannot 
assume that all linkers sing late 80's are as smart as DMC.

Nic Tiger.
April 08, 2006
Re: On processors for D
Nic Tiger wrote:
> Walter Bright wrote:
>> This capability of linkers (eliminating unreferenced functions) first 
>> appeared in the late 80's, and quickly became standard practice. If 
>> you've got a linker that doesn't support that, you're likely to have 
>> many other serious problems with it, as D (and C++) depend on other 
>> linker features introduced in the late 80's.
>>
>> D doesn't require anything of a linker that C++ doesn't already 
>> realistically require.
> Digital Mars linker is great in this field, but you definitely cannot 
> assume that all linkers sing late 80's are as smart as DMC.

I must say I'm surprised that 15+ year old linker technology that is 
easy to implement and once upon a time was much discussed (idiotically 
dubbed 'smart linking') seems to have fallen by the wayside.

At least the linkers D uses (optlink and newer versions of ld) support 
it. Optlink does it by default, and ld via a badly underdocumented 
obscure switch.
April 08, 2006
Re: On processors for D ~ decoupling
Dave wrote:
> Sean Kelly wrote:
>> Dave wrote:
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>>
>>>>> BTW, internal\dmain2.d also uses printf to print out an error 
>>>>> message relating to any uncaught exceptions.
>>>>
>>>> Ares currently uses fprintf for this purpose, which is essentially 
>>>> the same thing.  And as you say, it would be easy enough to hook the 
>>>> function if this behavior isn't desirable.
>>>>
>>>> I'm glad the compiler issues came to light however.  I don't suppose 
>>>> this will have any impact on the template code generation problem in 
>>>> libraries?
>>>
>>> Sean - could you point me to some links or post some example code on 
>>> this?
>>
>> http://svn.dsource.org/projects/ares/trunk/src/dmdrt/dmain2.d
>>
>> See the "catch" blocks near the end of the file.
> 
> I still don't understand in the context of this message - what are the 
> error messages you're getting?

Oops, I think I misunderstood.  Were you asking about the template link 
problems?  See this thread:

http://www.digitalmars.com/d/archives/digitalmars/D/23685.html


Sean
April 08, 2006
Re: On processors for D
Walter Bright wrote:
> 
> I must say I'm surprised that 15+ year old linker technology that is 
> easy to implement and once upon a time was much discussed (idiotically 
> dubbed 'smart linking') seems to have fallen by the wayside.
> 
> At least the linkers D uses (optlink and newer versions of ld) support 
> it. Optlink does it by default, and ld via a badly underdocumented 
> obscure switch.

I think this is one cause of the confusion about how Optlink behaves. 
But I do think that it is quite reasonable to expect such behavior, much 
as one expects optimization features in compilers.


Sean
April 14, 2006
Re: On processors for D ~ decoupling
Walter Bright wrote:
> kris wrote:
> 
>> Yes, that's correct. But typeinfo is a rather rudimetary part of the 
>> language support. Wouldn't you agree? If I, for example, declare an 
>> array of 10 bytes (static byte[10]) then I'm bound over to import 
>> std.string ~ simply because TypeInfo_StaticArray wants to use 
>> std.string.toString(int), rather than the C library version of itoa() 
>> or a "low-level support" version instead.
> 
> 
> It has nothing to do with having a static byte[10] declaration. For the 
> program:
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> The only things referenced by the object file are _main, __acrtused_con, 
> and __Dmain. You can verify this by running obj2asm on the output, which 
> gives:

> 
> It's just not a big deal. Try the following:
> 
> extern (C) int printf(char* f, ...) { return 0; }
> 
> void main()
> {
>     static byte[10] b;
> }
> 
> and compare the difference in exe file sizes, with and without the 
> printf stub.
> 
> 
>>> printf doesn't pull in the floating point library (I went to a lot of 
>>> effort to make that so!). It does pull in the C IO library, which is 
>>> very hard to not pull in (there always seems to be something 
>>> referencing it). It shouldn't pull in the C wide character stuff. D's 
>>> IO (writefln) will pull in C's IO anyway, so the only thing extra is 
>>> the integer version of the specific printf code (about 4K).
>>
>> How can it convert %f, %g and so on if it doesn't use FP support at all? 
> 
> 
> It's magic! Naw, it's just that if you actually use floating point in a 
> program, the compiler emits a special extern reference (to __fltused) 
> which pulls in the floating point IO formatting code. Otherwise, it 
> defaults to just a stub. Try it.
> 
>> Either way, it's not currently possible to build a D program without a 
>> swathe of FP support code,
>> printf,
>> the entire C IO package,
>> wide-char support,
>> and a whole lot more besides. I'd assumed the linked FP support was 
>> for printf, but perhaps it's for std.string instead? I've posted the 
>> linker maps (in the past) to illustrate exactly this.
> 
> 
> My point is that assuming what is pulled in by what is about as reliable 
> as guessing where the bottlenecks in one's code is.
Next ›   Last »
5 6 7 8 9
Top | Discussion index | About this forum | D home