"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.

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

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

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.

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.

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.

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...

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.

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.

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