View mode: basic / threaded / horizontal-split · Log in · Help
October 30, 2012
Re: To avoid some linking errors
"Walter Bright" <newshound2@digitalmars.com> wrote in message 
news:k6o0fd$25mm$1@digitalmars.com...
> On 10/29/2012 11:08 PM, Daniel Murphy wrote:
>> void foo();
>
> There will be no line information for the above.
>
> > void main()
> > {
> >    foo();
>
> For this, yes, but that is not what is being asked for.

It isn't?  Oops, my bad.
October 30, 2012
Re: To avoid some linking errors
On 2012-10-30 02:58, Brad Roberts wrote:

> If someone wanted to take on an ambitious task, one of the key problems
> with output munging is the parseability of the output (which applies to
> the compiler, linker, etc.. all the compiler chain tools).  Few (none?) of
> them output text that's designed for parsability (though some make it
> relatively easy).  It would be interesting to design a structured format
> and write scripts to sit between the various components to handle adapting
> the output.
>
> Restated via an example:
>
> today:
>    compiler invokes tools and just passes on output
>
> ideal (_an_ ideal, don't nitpick):
>    compiler invokes tool which returns structured output and uses that
>
> intermediate that's likely easier to achieve:
>    compiler invokes script that invokes tool (passing args) and fixes
> output to match structured output

Even better, in my opinion: Both the linker and compiler is built as a 
library. The compiler just calls a function from the linker library, 
like any other function, to do the linking. The linker uses the 
appropriate exception handling mechanism as any other function would. No 
need for tools calling each other and parsing output data.

-- 
/Jacob Carlborg
October 30, 2012
Re: To avoid some linking errors
On 2012-10-30 03:48, Walter Bright wrote:

> No need for :o), it's a fair question.
>
> The linking process itself is pretty simple. The problems come from
> designers who can't resist making things as complicated as possible.
> Just look at the switches for the various linkers, and what they purport
> to do. Then, look at all the complicated file formats it deals with:
>
> res files
> def files
> linker script files
> dwarf
> codeview
> magic undocumented formats
> pe files
> shared libraries
> eh formats
>
> And that's just the start.

The linker should not be directly built into the compiler. It should be 
build as a library, like the rest of the tool chain. The compiler then 
calls a function in the linker library to do the linking.

See one of my other replies:

http://forum.dlang.org/thread/jxiupltnfbmbvyxherca@forum.dlang.org?page=5#post-k6o4en:242bld:241:40digitalmars.com

-- 
/Jacob Carlborg
October 30, 2012
Re: To avoid some linking errors
Le 28/10/2012 21:59, Walter Bright a écrit :
> On 10/28/2012 1:34 PM, deadalnix wrote:
>> As Andrei stated, the linker's native language is encrypted klingon.
>
> It baffles me that programmers would find "undefined symbol" hard to
> make sense of.

Undefined symbol is the clear part of the message.

The mangled madness that follow that is supposed to help finding what 
symbol we are dealing with is the unclear part.

Not to mention ddemangle is unable to demangle many D mangling.
October 30, 2012
Re: To avoid some linking errors
On Tuesday, 30 October 2012 at 08:53:49 UTC, Jacob Carlborg wrote:
> On 2012-10-30 03:48, Walter Bright wrote:
>
>> No need for :o), it's a fair question.
>>
>> The linking process itself is pretty simple. The problems come 
>> from
>> designers who can't resist making things as complicated as 
>> possible.
>> Just look at the switches for the various linkers, and what 
>> they purport
>> to do. Then, look at all the complicated file formats it deals 
>> with:
>>
>> res files
>> def files
>> linker script files
>> dwarf
>> codeview
>> magic undocumented formats
>> pe files
>> shared libraries
>> eh formats
>>
>> And that's just the start.
>
> The linker should not be directly built into the compiler. It 
> should be build as a library, like the rest of the tool chain. 
> The compiler then calls a function in the linker library to do 
> the linking.
>
> See one of my other replies:
>
> http://forum.dlang.org/thread/jxiupltnfbmbvyxherca@forum.dlang.org?page=5#post-k6o4en:242bld:241:40digitalmars.com

This is most likely the approach taken by Delphi and .NET.
October 30, 2012
Re: To avoid some linking errors
On Tue, Oct 30, 2012 at 09:51:34AM +0100, Jacob Carlborg wrote:
> On 2012-10-30 02:58, Brad Roberts wrote:
[...]
> >today:
> >   compiler invokes tools and just passes on output
> >
> >ideal (_an_ ideal, don't nitpick):
> >   compiler invokes tool which returns structured output and uses that
> >
> >intermediate that's likely easier to achieve:
> >   compiler invokes script that invokes tool (passing args) and fixes
> >output to match structured output
> 
> Even better, in my opinion: Both the linker and compiler is built
> as a library. The compiler just calls a function from the linker
> library, like any other function, to do the linking. The linker uses
> the appropriate exception handling mechanism as any other function
> would. No need for tools calling each other and parsing output data.
[...]

+1. This is 2012, we have developed the concept of libraries, why are we
still trying to parse output between two tools (compiler & linker) that
are so closely intertwined? Not the mention the advantages of having the
compiler and linker as a library: reusability in IDEs, adaptability to
*runtime* compilation, and a host of other powerful usages.


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - Natural Intelligence, Inc.
October 30, 2012
Re: To avoid some linking errors
On Tue, Oct 30, 2012 at 12:22:15PM +0100, deadalnix wrote:
> Le 28/10/2012 21:59, Walter Bright a écrit :
> >On 10/28/2012 1:34 PM, deadalnix wrote:
> >>As Andrei stated, the linker's native language is encrypted klingon.
> >
> >It baffles me that programmers would find "undefined symbol" hard to
> >make sense of.
> 
> Undefined symbol is the clear part of the message.
> 
> The mangled madness that follow that is supposed to help finding
> what symbol we are dealing with is the unclear part.
> 
> Not to mention ddemangle is unable to demangle many D mangling.

Yeah, what's up with that? I looked briefly at the code, and there's a
comment that says that it only demangles a certain subset of symbols
because the others are "useless" when it comes to ABI's, or something
like that. I have no idea what that means and why it matters. What's
wrong with demangle() demangling *everything*? Isn't that what it's
supposed to be doing anyway?


T

-- 
The early bird gets the worm. Moral: ewww...
October 30, 2012
Re: To avoid some linking errors
On 10/30/2012 7:46 AM, H. S. Teoh wrote:
> On Tue, Oct 30, 2012 at 09:51:34AM +0100, Jacob Carlborg wrote:
>> On 2012-10-30 02:58, Brad Roberts wrote:
> [...]
>>> today:
>>>   compiler invokes tools and just passes on output
>>>
>>> ideal (_an_ ideal, don't nitpick):
>>>   compiler invokes tool which returns structured output and uses that
>>>
>>> intermediate that's likely easier to achieve:
>>>   compiler invokes script that invokes tool (passing args) and fixes
>>> output to match structured output
>>
>> Even better, in my opinion: Both the linker and compiler is built
>> as a library. The compiler just calls a function from the linker
>> library, like any other function, to do the linking. The linker uses
>> the appropriate exception handling mechanism as any other function
>> would. No need for tools calling each other and parsing output data.
> [...]
> 
> +1. This is 2012, we have developed the concept of libraries, why are we
> still trying to parse output between two tools (compiler & linker) that
> are so closely intertwined? Not the mention the advantages of having the
> compiler and linker as a library: reusability in IDEs, adaptability to
> *runtime* compilation, and a host of other powerful usages.
> 
> 
> T
> 

I'm all for idealistic views, but neither of those matches reality in any meaningful way.  What I outlined is actually
practical.
October 30, 2012
Re: To avoid some linking errors
On Tuesday, 30 October 2012 at 07:43:41 UTC, Walter Bright wrote:
> On 10/29/2012 11:08 PM, Daniel Murphy wrote:
>> void foo();
>
> There will be no line information for the above.
>
> > void main()
> > {
> >    foo();
>
> For this, yes, but that is not what is being asked for.

Well, personally I think I would enjoy having this line number. 
The more information the better.
October 30, 2012
Re: To avoid some linking errors
On 2012-10-30 18:34, Brad Roberts wrote:

> I'm all for idealistic views, but neither of those matches reality in any meaningful way.  What I outlined is actually
> practical.

Well yes, for an already existing tool. But I see no reason why one 
wouldn't use this approach when developing a new tool. Lately, all my 
tools I write are built as libraries and a fairly thin executable that 
calls the library. Except that one can use the library in other tools it 
separates and modularize the code, easier to test and so on.

-- 
/Jacob Carlborg
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home