www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - To avoid some linking errors

reply "bearophile" <bearophileHUGS lycos.com> writes:
This code compiles with no errors, and then later the linker 
gives a "Symbol Undefined":


abstract class A {
     public void foo();
}
class B : A {}
void main() {}


In this bug report I have asked for the compiler to give an error:
http://d.puremagic.com/issues/show_bug.cgi?id=5129


But Walter has answered it's not a bug:

 This is not a bug, as in another module there could be a class 
 C that derives
 from B and implements foo().
 
 As documented, D accepts non-abstract functions with no body 
 declared as:
 
    void foo();
 
 with the idea that the user will be supplying a body somewhere 
 else - perhaps
 even a C function or an assembler one. It's another way of 
 doing encapsulation
 by having an opaque implementation. In fact, it's used by the 
 TypeInfo's.

Stewart Gordon suggests:
 I think the underlying problem is that there's no mandatory 
 explicit notation
 for externally defined functions.

So isn't it better to require (similarly to annotations like "override") the programmer to write in B an "extern" or "abstract" or something similar to state that the implementation is elsewhere (and give a nice compilation error if it's missing)? abstract class A { public void foo(); } class B : A { extern foo; } void main() {} Or: abstract class A { public void foo(); } class B : A { abstract foo; } void main() {} Bye, bearophile
Oct 28 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2012 6:39 AM, bearophile wrote:
 This code compiles with no errors, and then later the linker gives a "Symbol
 Undefined":
 [...]
 (and give a nice compilation error if it's missing)?

It already gives a nice error "Symbol Undefined". I don't understand why this is a problem. void foo() { } // defined here void foo(); // defined elsewhere No need for anything more.
Oct 28 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 28/10/2012 18:17, Walter Bright a écrit :
 On 10/28/2012 6:39 AM, bearophile wrote:
 This code compiles with no errors, and then later the linker gives a
 "Symbol
 Undefined":
 [...]

It already gives a nice error "Symbol Undefined". I don't understand why this is a problem. void foo() { } // defined here void foo(); // defined elsewhere No need for anything more.

As Andrei stated, the linker's native language is encrypted klingon.
Oct 28 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 28 2012
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 28.10.2012 22:38, schrieb David Nadlinger:
 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 It baffles me that programmers would find "undefined symbol" hard to
 make sense of.

Do really think that your typical Java programmer is familiar with the term »symbol« in the compiler/linker sense? Also, don't underestimate the perceived scariness/ugliness of mangled names in linker error messages. I'm pretty much fluent in reading D mangled names by now, but most newcomers definitely aren't. That, coupled with the absence of the typical source location information (IDE integration!), is probably enough to make encountering such errors a significantly more unpleasant experience for most people than compiler errors. Again, maybe not for you, maybe not for me, but I think it is clear that this is a problem to some, so the discussion should not be about talking the problem away, but rather about evaluating possible solutions/mitigation strategies in terms of feasibility (e.g. name demangling in linker output?). David

VisualD has a command line tool that demangels linker error messages and makes them more readable. Kind Regards Benjamin Thaut
Oct 28 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2012 2:38 PM, David Nadlinger wrote:
 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 It baffles me that programmers would find "undefined symbol" hard to make
 sense of.

Do really think that your typical Java programmer is familiar with the term »symbol« in the compiler/linker sense?

I am baffled why a programmer with even a modest skill level in any language would not know what a symbol in a programming language is.
 Also, don't underestimate the perceived
 scariness/ugliness of mangled names in linker error messages. I'm pretty much
 fluent in reading D mangled names by now, but most newcomers definitely aren't.

I see the point of that, and at one point optlink did demangle names. But that didn't change anything. There was also a filter one could run the linker output through that would demangle the names, but nobody found that useful, either, and it fell by the wayside. You'll see the same complaints from the same people appearing for C code being linked, which does not have mangled names.
 That, coupled with the absence of the typical source location information (IDE
 integration!), is probably enough to make encountering such errors a
 significantly more unpleasant experience for most people than compiler errors.

 Again, maybe not for you, maybe not for me, but I think it is clear that this
is
 a problem to some, so the discussion should not be about talking the problem
 away, but rather about evaluating possible solutions/mitigation strategies in
 terms of feasibility (e.g. name demangling in linker output?).

There is this, which is linked to from the faq: http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined I even wrote an entry in this book http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484 about it. *Every* programmer should know what a linker does.
Oct 28 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-28 22:57, Walter Bright wrote:

 I am baffled why a programmer with even a modest skill level in any
 language would not know what a symbol in a programming language is.

Welcome to the real world :)
 I see the point of that, and at one point optlink did demangle names.
 But that didn't change anything. There was also a filter one could run
 the linker output through that would demangle the names, but nobody
 found that useful, either, and it fell by the wayside.

 You'll see the same complaints from the same people appearing for C code
 being linked, which does not have mangled names.

You still don't get any source location.
 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined

That's only for optlink.
 I even wrote an entry in this book


 http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

 about it. *Every* programmer should know what a linker does.

I agree with you, but again, that's not the world we live in. On the other hand, why does, say, an PHP (insert your favorite dynamic programming language that doesn't use a linker) programmer need to know what a linker is? -- /Jacob Carlborg
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 2:49 AM, Jacob Carlborg wrote:
 You'll see the same complaints from the same people appearing for C code
 being linked, which does not have mangled names.

You still don't get any source location.

It's usually pretty obvious, but when it isn't, I use: grep -r symbol_name *.d or whatever search function your IDE has.
 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined

That's only for optlink.

True, but the suggestions for what to do next apply to any linker.
 *Every* programmer should know what a linker does.

I agree with you, but again, that's not the world we live in. On the other hand, why does, say, an PHP (insert your favorite dynamic programming language that doesn't use a linker) programmer need to know what a linker is?

Because it's a fundamental tool for programmers, despite PHP not using it. It's like knowing what a CPU register is.
Oct 29 2012
parent reply Faux Amis <faux amis.com> writes:
On 29/10/2012 18:38, Walter Bright wrote:
 On 10/29/2012 2:49 AM, Jacob Carlborg wrote:
  >> You'll see the same complaints from the same people appearing for C
 code
  >> being linked, which does not have mangled names.
  >
  > You still don't get any source location.

 It's usually pretty obvious, but when it isn't, I use:

      grep -r symbol_name *.d

 or whatever search function your IDE has.


  >>
 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined
  >
  > That's only for optlink.

 True, but the suggestions for what to do next apply to any linker.


  >> *Every* programmer should know what a linker does.
  >
  > I agree with you, but again, that's not the world we live in. On the
 other hand,
  > why does, say, an PHP (insert your favorite dynamic programming
 language that
  > doesn't use a linker) programmer need to know what a linker is?

 Because it's a fundamental tool for programmers, despite PHP not using
 it. It's like knowing what a CPU register is.

difference between the stack and the heap but still are able to write useful code. You really seem to be lurking way too much on newsgroups with knowledgeable people ;)
Oct 29 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-29 19:05, Faux Amis wrote:

 Haha, I know a lot of professional programmers who do not know the
 difference between the stack and the heap but still are able to write
 useful code.
 You really seem to be lurking way too much on newsgroups with
 knowledgeable people ;)

I completely agree. I can probably count the number of PHP developer who know what a CPU resister is on one hand. Let me add to that: Ruby, JavaScript, Python and a bunch of other languages. -- /Jacob Carlborg
Oct 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-29 20:00, H. S. Teoh wrote:

 The kind of code the average "professional" programmer produces is ...
 shall I say, underwhelming? It's the kind of thing that makes me
 consider career switches. Raising the bar for programmer qualification
 will do the world a lot of good.

Absolutely. The bar is not set very high. -- /Jacob Carlborg
Oct 29 2012
prev sibling parent Faux Amis <faux amis.com> writes:
On 29/10/2012 20:00, H. S. Teoh wrote:
 On Mon, Oct 29, 2012 at 07:05:33PM +0100, Faux Amis wrote:
 On 29/10/2012 18:38, Walter Bright wrote:
 On 10/29/2012 2:49 AM, Jacob Carlborg wrote:


 I agree with you, but again, that's not the world we live in. On
 the other hand, why does, say, an PHP (insert your favorite
 dynamic programming language that doesn't use a linker) programmer
 need to know what a linker is?

Because it's a fundamental tool for programmers, despite PHP not using it. It's like knowing what a CPU register is.

difference between the stack and the heap but still are able to write useful code.

The kind of code the average "professional" programmer produces is ... shall I say, underwhelming? It's the kind of thing that makes me consider career switches. Raising the bar for programmer qualification will do the world a lot of good. T

But, I have seen people who know all the ins and outs of their machine create horrible code which I will never allow to merge and people who barely know what a pointer is generate very clean, readable and usable code.
Oct 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-28 22:38, David Nadlinger wrote:

 Do really think that your typical Java programmer is familiar with the
 term »symbol« in the compiler/linker sense? Also, don't underestimate
 the perceived scariness/ugliness of mangled names in linker error
 messages. I'm pretty much fluent in reading D mangled names by now, but
 most newcomers definitely aren't.

 That, coupled with the absence of the typical source location
 information (IDE integration!), is probably enough to make encountering
 such errors a significantly more unpleasant experience for most people
 than compiler errors.

 Again, maybe not for you, maybe not for me, but I think it is clear that
 this is a problem to some, so the discussion should not be about talking
 the problem away, but rather about evaluating possible
 solutions/mitigation strategies in terms of feasibility (e.g. name
 demangling in linker output?).

I completely agree. I can handle the mangled symbols as well but it would be much nicer with demangled symbols, source location and so on. Just because I can read HTML I'm not surfing the web with "curl", I use a GUI browser that renders the HTML. It's much nicer that way. -- /Jacob Carlborg
Oct 29 2012
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 29-Oct-12 01:38, David Nadlinger wrote:
 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 It baffles me that programmers would find "undefined symbol" hard to
 make sense of.

Do really think that your typical Java programmer is familiar with the term »symbol« in the compiler/linker sense? Also, don't underestimate the perceived scariness/ugliness of mangled names in linker error messages. I'm pretty much fluent in reading D mangled names by now, but most newcomers definitely aren't.

 That, coupled with the absence of the typical source location
 information (IDE integration!), is probably enough to make encountering
 such errors a significantly more unpleasant experience for most people
 than compiler errors.

 Again, maybe not for you, maybe not for me, but I think it is clear that
 this is a problem to some, so the discussion should not be about talking
 the problem away, but rather about evaluating possible
 solutions/mitigation strategies in terms of feasibility (e.g. name
 demangling in linker output?).

Indeed, when dmd works as a driver and invokes a linker can't it just pipe its output through ddemangle? -- Dmitry Olshansky
Oct 29 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/12 2:10 PM, Peter Alexander wrote:
 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 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.

_D3yeah9whats82__T4soS36_D4hard4toFZv9__lambda1FNaNbNfiiZbVE3understand9about12this ;-) Seriously though, it's irrelevant. The fact is a lot of programmers, especially new programmers or ones from programming languages that don't use linkers find link errors scary and confusing. Pretending otherwise gets us nowhere. Saying it baffles you why things are this way gets us nowhere. Saying that "they should understand" gets us nowhere.

I agree (and was about to post something very close to this). I've heard many times about this particular baffling, and it's one of those cases in which clearly people who are otherwise competent have quite a bit of difficulty. So one reasonable resolution is "well that's how people are, and that you think differently doesn't solve the matter one bit, so let's see what steps to take on improving it". From what I can tell here's how to solve linker error issues: 1. Automatic demangling of the symbols involved must be in place. 2. For undefined symbols, there must be reference at source file and line level of where they are referred - /all/ places! 3. For multiply defined symbols, there must be reference at source file and line level for each definition. I understand there are technical difficulties in implementing the above, but that doesn't justify being baffled. Being baffled is not an option. Andrei
Oct 29 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-29 19:19, Andrei Alexandrescu wrote:

 I agree (and was about to post something very close to this). I've heard
 many times about this particular baffling, and it's one of those cases
 in which clearly people who are otherwise competent have quite a bit of
 difficulty. So one reasonable resolution is "well that's how people are,
 and that you think differently doesn't solve the matter one bit, so
 let's see what steps to take on improving it".

  From what I can tell here's how to solve linker error issues:

 1. Automatic demangling of the symbols involved must be in place.

 2. For undefined symbols, there must be reference at source file and
 line level of where they are referred - /all/ places!

 3. For multiply defined symbols, there must be reference at source file
 and line level for each definition.

 I understand there are technical difficulties in implementing the above,
 but that doesn't justify being baffled.

 Being baffled is not an option.

Well said. -- /Jacob Carlborg
Oct 29 2012
prev sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 29 Oct 2012, Andrei Alexandrescu wrote:
 On 10/29/12 2:10 PM, Peter Alexander wrote:
 On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 
 Seriously though, it's irrelevant. The fact is a lot of programmers,
 especially new programmers or ones from programming languages that don't
 use linkers find link errors scary and confusing.
 
 Pretending otherwise gets us nowhere.
 
 Saying it baffles you why things are this way gets us nowhere.
 
 Saying that "they should understand" gets us nowhere.

I agree (and was about to post something very close to this). I've heard many times about this particular baffling, and it's one of those cases in which clearly people who are otherwise competent have quite a bit of difficulty. So one reasonable resolution is "well that's how people are, and that you think differently doesn't solve the matter one bit, so let's see what steps to take on improving it". From what I can tell here's how to solve linker error issues: 1. Automatic demangling of the symbols involved must be in place. 2. For undefined symbols, there must be reference at source file and line level of where they are referred - /all/ places! 3. For multiply defined symbols, there must be reference at source file and line level for each definition. I understand there are technical difficulties in implementing the above, but that doesn't justify being baffled. Being baffled is not an option. Andrei

There's another angle to this: 1) It's been stated more than once that one of the goals for D is to achieve a user base of over 1 million users. 2) I assert that there aren't more than 1 million programmers with the level of expertise and experience required to understand what happens during compilation to a sufficient degree that they feel comfortable with the tool chains that D (and c and c++) have today. Conclusion, the tool chains must get more user friendly.
Oct 29 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 1:19 PM, Brad Roberts wrote:
 There's another angle to this:

 1) It's been stated more than once that one of the goals for D is to
 achieve a user base of over 1 million users.

 2) I assert that there aren't more than 1 million programmers with the
 level of expertise and experience required to understand what happens
 during compilation to a sufficient degree that they feel comfortable with
 the tool chains that D (and c and c++) have today.

 Conclusion, the tool chains must get more user friendly.

Stroustrup estimates "more than 3 million" C++ users in 2004. http://www.stroustrup.com/bs_faq.html#number-of-C++-users There are probably more than that many C users.
Oct 29 2012
next sibling parent Faux Amis <faux amis.com> writes:
On 29/10/2012 22:34, Walter Bright wrote:
 On 10/29/2012 1:19 PM, Brad Roberts wrote:
  > There's another angle to this:
  >
  > 1) It's been stated more than once that one of the goals for D is to
  > achieve a user base of over 1 million users.
  >
  > 2) I assert that there aren't more than 1 million programmers with the
  > level of expertise and experience required to understand what happens
  > during compilation to a sufficient degree that they feel comfortable
 with
  > the tool chains that D (and c and c++) have today.
  >
  > Conclusion, the tool chains must get more user friendly.


 Stroustrup estimates "more than 3 million" C++ users in 2004.

 http://www.stroustrup.com/bs_faq.html#number-of-C++-users

 There are probably more than that many C users.

In 2004 C++ was on the top of its game. http://www.tiobe.com/content/paperinfo/tpci/C__.html But, I also think 1 million is on the low side. It is probably closer to 5 (third=C,C++,alike of 15) million, excluding the "feel comfortable" part of course. http://stackoverflow.com/questions/453880/how-many-developers-are-there-in-the-world I also wanted to say some thing about expectations and reasons to switch..
Oct 29 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 3:11 PM, Brad Roberts wrote:
 It's friction.  It needs to be reduced.

Short of building the linking code into dmd, the options are fairly limited. Note that I did build the librarian code into dmd, instead of leaving it as a separate utility (lib.exe, ar), and have been pretty pleased with the results. But the librarian is a trivial piece of code.
Oct 29 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/12 6:13 PM, Walter Bright wrote:
 On 10/29/2012 3:11 PM, Brad Roberts wrote:
 It's friction. It needs to be reduced.

Short of building the linking code into dmd, the options are fairly limited.

Why can't the linking code be built into dmd? I am baffled :o). Andrei
Oct 29 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 4:37 PM, Andrei Alexandrescu wrote:> On 10/29/12 6:13 PM, Walter 
Bright wrote:
 On 10/29/2012 3:11 PM, Brad Roberts wrote:
 It's friction. It needs to be reduced.

Short of building the linking code into dmd, the options are fairly limited.

Why can't the linking code be built into dmd? I am baffled :o).

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.
Oct 29 2012
parent Jacob Carlborg <doob me.com> writes:
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
Oct 30 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 6:43 PM, Brad Roberts wrote:
 To be clear, I'm certain that Andrei was kidding / making a joke at
 Walter's expense.

Andrei never jokes about programming :-)
Oct 29 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/12 10:57 PM, Walter Bright wrote:
 On 10/29/2012 6:43 PM, Brad Roberts wrote:
 To be clear, I'm certain that Andrei was kidding / making a joke at
 Walter's expense.

Andrei never jokes about programming :-)

The question was fair. The "backatcha" baffling was one of my better jokes. Well I have my moments. Andrei
Oct 29 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Oct 30 2012
parent Jacob Carlborg <doob me.com> writes:
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
Oct 30 2012
prev sibling next sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 29 Oct 2012, Walter Bright wrote:

 On 10/29/2012 1:19 PM, Brad Roberts wrote:
 There's another angle to this:

 1) It's been stated more than once that one of the goals for D is to
 achieve a user base of over 1 million users.

 2) I assert that there aren't more than 1 million programmers with the
 level of expertise and experience required to understand what happens
 during compilation to a sufficient degree that they feel comfortable with
 the tool chains that D (and c and c++) have today.

 Conclusion, the tool chains must get more user friendly.

Stroustrup estimates "more than 3 million" C++ users in 2004. http://www.stroustrup.com/bs_faq.html#number-of-C++-users There are probably more than that many C users.

Think there's any chance that 1/3 of the existing c++ users are going to switch to d? In the next year? Me neither. The majority of D users are newish developers or developers w/out history in the C style compilation model. It's just foreign and the majority aren't interested in having to learn about issues that the higher level languages don't require. It's friction. It needs to be reduced. I say all of the above having been essentially an member of the C style compilation model, exclusively.
Oct 29 2012
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Tue, 30 Oct 2012, bearophile wrote:
 Andrei Alexandrescu:
 
 Why can't the linking code be built into dmd? I am baffled :o).

This is possible, but a better question is how much work is required to do this? Walter was very slowly translating the current linker from disassembly to C. If and once that program is all C, it's probably not too much hard to convert it to D, merge it with the dmd binary, and improve it in some ways. Bye, bearophile

Built in? Absolutely not. There's no way that it's architectually wise to have the linker as a part of the compiler binary. Able to usefully interact with the linker? Absolutely. To be clear, I'm certain that Andrei was kidding / making a joke at Walter's expense.
Oct 29 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
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.
Oct 30 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 It baffles me that programmers would find "undefined symbol" 
 hard to make sense of.

Do really think that your typical Java programmer is familiar with the term »symbol« in the compiler/linker sense? Also, don't underestimate the perceived scariness/ugliness of mangled names in linker error messages. I'm pretty much fluent in reading D mangled names by now, but most newcomers definitely aren't. That, coupled with the absence of the typical source location information (IDE integration!), is probably enough to make encountering such errors a significantly more unpleasant experience for most people than compiler errors. Again, maybe not for you, maybe not for me, but I think it is clear that this is a problem to some, so the discussion should not be about talking the problem away, but rather about evaluating possible solutions/mitigation strategies in terms of feasibility (e.g. name demangling in linker output?). David
Oct 28 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 28 October 2012 at 20:59:25 UTC, Walter Bright wrote:
 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.

_D3yeah9whats82__T4soS36_D4hard4toFZv9__lambda1FNaNbNfiiZbVE3understand9about12this ;-) Seriously though, it's irrelevant. The fact is a lot of programmers, especially new programmers or ones from programming languages that don't use linkers find link errors scary and confusing. Pretending otherwise gets us nowhere. Saying it baffles you why things are this way gets us nowhere. Saying that "they should understand" gets us nowhere.
Oct 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 29, 2012 at 07:05:33PM +0100, Faux Amis wrote:
 On 29/10/2012 18:38, Walter Bright wrote:
On 10/29/2012 2:49 AM, Jacob Carlborg wrote:


 I agree with you, but again, that's not the world we live in. On
 the other hand, why does, say, an PHP (insert your favorite
 dynamic programming language that doesn't use a linker) programmer
 need to know what a linker is?

Because it's a fundamental tool for programmers, despite PHP not using it. It's like knowing what a CPU register is.

difference between the stack and the heap but still are able to write useful code.

The kind of code the average "professional" programmer produces is ... shall I say, underwhelming? It's the kind of thing that makes me consider career switches. Raising the bar for programmer qualification will do the world a lot of good. T -- In theory, there is no difference between theory and practice.
Oct 29 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/29/12, Brad Roberts <braddr puremagic.com> wrote:
 Conclusion, the tool chains must get more user friendly.

Yep. Just compare: $ dmd -c test.d -oftest.obj Optlink: $ link test.obj
 test.obj(test)
  Error 42: Symbol Undefined _D4test1A3fooMFZv

Unilink: $ ulink test.obj
 Error: Unresolved external 'test.A.foo()' referenced from 'test.obj'

Oct 29 2012
prev sibling next sibling parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Sunday, 28 October 2012 at 13:39:26 UTC, bearophile wrote:
 This code compiles with no errors, and then later the linker 
 gives a "Symbol Undefined":


 abstract class A {
     public void foo();
 }
 class B : A {}
 void main() {}

Interestingly, adding abstract to the method will result in no linker error for compiling. And if a new B is created then a compiler error is provided instead of a linker error. I'm for getting some line numbers over the less informative linker error.
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 2:28 PM, Jesse Phillips wrote:
 On Sunday, 28 October 2012 at 13:39:26 UTC, bearophile wrote:
 This code compiles with no errors, and then later the linker gives a "Symbol
 Undefined":


 abstract class A {
     public void foo();
 }
 class B : A {}
 void main() {}

Interestingly, adding abstract to the method will result in no linker error for compiling.

That's because by saying "abstract" you're telling the compiler that there is no implementation for A.foo(), which is fundamentally different from saying that A.foo() is defined elsewhere. The compiler inserts a 0 in the vtbl[] slot for it, even though it won't let you try to call it.
 And if a new B is created then a compiler error is provided instead
 of a linker error.

Abstract types are really a different thing from "it's defined somewhere else."
 I'm for getting some line numbers over the less informative linker error.

The object file format does not support line numbers for symbol references and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, MsCoff) have that. Even the symbolic debug info doesn't have line numbers for references, just for definitions.
Oct 29 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:k6mun3$a8h$1 digitalmars.com...
 The object file format does not support line numbers for symbol references 
 and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, MsCoff) 
 have that. Even the symbolic debug info doesn't have line numbers for 
 references, just for definitions.

While this is true, you could scan the relocations for matching symbols, then use the debug information to get line numbers. This would work for all function calls at least.
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2012 9:51 PM, Daniel Murphy wrote:> "Walter Bright" 
<newshound2 digitalmars.com> wrote in message
 news:k6mun3$a8h$1 digitalmars.com...
 The object file format does not support line numbers for symbol references
 and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, MsCoff)
 have that. Even the symbolic debug info doesn't have line numbers for
 references, just for definitions.

While this is true, you could scan the relocations for matching symbols, then use the debug information to get line numbers. This would work for all function calls at least.

If the symbol is undefined, then there is no debug info for it.
Oct 29 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:k6npgi$1hsr$1 digitalmars.com...
 On 10/29/2012 9:51 PM, Daniel Murphy wrote:> "Walter Bright" 
 <newshound2 digitalmars.com> wrote in message
 news:k6mun3$a8h$1 digitalmars.com...
 The object file format does not support line numbers for symbol 
 references
 and definitions. None of the 4 supported ones (OMF, ELF, Mach-O, 
 MsCoff)
 have that. Even the symbolic debug info doesn't have line numbers for
 references, just for definitions.

While this is true, you could scan the relocations for matching symbols, then use the debug information to get line numbers. This would work for all function calls at least.

If the symbol is undefined, then there is no debug info for it.

There will be debug information for the call site if it is in the user's program. eg void foo(); void main() { foo(); }
dmd testx -g

OPTLINK (R) for Win32 Release 8.00.12 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html testx.obj(testx) Error 42: Symbol Undefined _D5testx3fooFZv --- errorlevel 1
objconv -dr testx.obj

Dump of file: testx.obj, type: OMF32 Checksums are zero LEDATA, LIDATA, COMDAT and FIXUPP records: LEDATA: segment $$SYMBOLS, Offset 0x0, Size 0x4B FIXUPP: Direct farword 32+16 bit, Offset 0x30, group FLAT. Symbol __Dmain (T6), inlin e 0x0:0x0 COMDAT: name , Offset 0x0, Size 0xD, Attrib 0x00, Align 0, Type 0, Base 0 FIXUPP: Relatv 32 bit, Offset 0x4, group FLAT. Symbol _D5testx3fooFZv (T6), inline 0x 1000E LEDATA: segment _DATA, Offset 0x0, Size 0xE LEDATA: segment FM, Offset 0x0, Size 0x4 FIXUPP: Direct 32 bit, Offset 0x0, group FLAT. Segment _DATA (T4), inline 0x0 LEDATA: segment $$TYPES, Offset 0x0, Size 0x16 The FIXUPP record gives Offset 0x4 for the address _D5testx3fooFZv, and the debug information for main will give the line number of that offset. I wouldn't want to implement it in assembly though.
Oct 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 30 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Oct 30 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 2:13 PM, Jesse Phillips wrote:
 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.

Not sure I'm following but essentially if foo() is undefined the most interesting file/line references would be for all calls to foo(). The lines declaring foo() are nice to have but much less interesting. Andrei
Oct 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 5:07 PM, Brad Roberts wrote:
 On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:

 On 10/30/12 2:13 PM, Jesse Phillips wrote:
 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.

Not sure I'm following but essentially if foo() is undefined the most interesting file/line references would be for all calls to foo(). The lines declaring foo() are nice to have but much less interesting. Andrei

I don't think I agree. The key questions that come to mind from an undefined symbol error at link time are: 1) Why did the compiler believe it would be? If it didn't think it was a valid usable symbol, it would have already errored at the call site during semantic analysis.

Not getting this at all. All I'm saying is that if the compiler says "I can't find that foo() you're asking for", the most interesting piece of information for me is "where did I ask for it?"
 2) what's the fully qualified name of the symbol?  Maybe the compiler is
 matching a different symbol than expected.  However, if that was the case,
 either it'd link against the unexpected match successfully, or see also
 #1.

That's in the symbol. Andrei
Oct 30 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 5:40 PM, Brad Roberts wrote:
 On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:

 On 10/30/12 5:07 PM, Brad Roberts wrote:
 1) Why did the compiler believe it would be?  If it didn't think it was a
 valid usable symbol, it would have already errored at the call site during
 semantic analysis.

Not getting this at all. All I'm saying is that if the compiler says "I can't find that foo() you're asking for", the most interesting piece of information for me is "where did I ask for it?"

Ok, so it points to a place in the code where you used it. You look at that and say, yup, I did indeed use it. Not surprising.

In the presence of overloading, that is most often surprising. And usually it's not "I" who uses it, it's transitively called by some code I write. That's the hardest part.
 Now, why doesn't
 the linker find it?

Because it's declared but not explicitly made part of the project.
 Why did the compiler believe it existed?

Grep takes care of that. Finding the declaration is never a problem.
 The site of the usage isn't remotely useful for answering either of those
 questions and those are the ones that form the disconnect between the
 compiler, who believed it existed and let the code pass to the next
 stage), and the linker.

Non-issue. Grep takes care of that. Finding the cross-references and the overloading part are the hard problems here. This is so clear to me for so many reasons, I am paralyzed by options. Andrei
Oct 30 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2012 2:49 PM, Andrei Alexandrescu wrote:
 On 10/30/12 5:40 PM, Brad Roberts wrote:
 On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:

 On 10/30/12 5:07 PM, Brad Roberts wrote:
 1) Why did the compiler believe it would be?  If it didn't think it was a
 valid usable symbol, it would have already errored at the call site during
 semantic analysis.

Not getting this at all. All I'm saying is that if the compiler says "I can't find that foo() you're asking for", the most interesting piece of information for me is "where did I ask for it?"

Ok, so it points to a place in the code where you used it. You look at that and say, yup, I did indeed use it. Not surprising.

In the presence of overloading, that is most often surprising. And usually it's not "I" who uses it, it's transitively called by some code I write. That's the hardest part.
 Now, why doesn't
 the linker find it?

Because it's declared but not explicitly made part of the project.
 Why did the compiler believe it existed?

Grep takes care of that. Finding the declaration is never a problem.

I find it ironic that you mention grep. Grep is what I suggested in the link to dealing with the issue, but nobody likes that answer. http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined
 The site of the usage isn't remotely useful for answering either of those
 questions and those are the ones that form the disconnect between the
 compiler, who believed it existed and let the code pass to the next
 stage), and the linker.

Non-issue. Grep takes care of that. Finding the cross-references and the overloading part are the hard problems here. This is so clear to me for so many reasons, I am paralyzed by options.

If you're missing a definition, you need to find the declaration, not the use, because that's where the missing definition needs to go. And finally, grepping for an un-mangled name doesn't work for overloaded names.
Oct 30 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/30/12 6:00 PM, Walter Bright wrote:
 I find it ironic that you mention grep. Grep is what I suggested in the
 link to dealing with the issue, but nobody likes that answer.

 http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#symbol_undefined

Mangling is the issue here.
 The site of the usage isn't remotely useful for answering either of
 those
 questions and those are the ones that form the disconnect between the
 compiler, who believed it existed and let the code pass to the next
 stage), and the linker.

Non-issue. Grep takes care of that. Finding the cross-references and the overloading part are the hard problems here. This is so clear to me for so many reasons, I am paralyzed by options.

If you're missing a definition, you need to find the declaration, not the use, because that's where the missing definition needs to go. And finally, grepping for an un-mangled name doesn't work for overloaded names.

Upon more thinking, I agree that BOTH declarations and call sites must be clearly pointed in the errors output by the linker. But I'll still point out that the real difficulty is finding the calls, not the declarations. I don't ever remember having a hard time "where is this declared?" Instead, the hard problem has always been "What is the call chain that leads to an undefined symbol?" Andrei
Oct 30 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-30 22:49, Andrei Alexandrescu wrote:

 Non-issue. Grep takes care of that. Finding the cross-references and the
 overloading part are the hard problems here. This is so clear to me for
 so many reasons, I am paralyzed by options.

Assuming you have a fairly unique symbols in a quite small project. This where an IDE would be great to have. It could point to all the locations of the actual symbol, not just all text that matches the symbol. -- /Jacob Carlborg
Oct 31 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/31/2012 12:39 AM, Jacob Carlborg wrote:> Assuming you have a fairly
unique 
symbols in a quite small project. This where
 an IDE would be great to have. It could point to all the locations of the
actual
 symbol, not just all text that matches the symbol.

Sure, but us long time command line users tend to write greppable names :-)
Oct 31 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 06:04:47PM -0400, Andrei Alexandrescu wrote:
 On 10/30/12 6:00 PM, Walter Bright wrote:

If you're missing a definition, you need to find the declaration, not
the use, because that's where the missing definition needs to go.
And finally, grepping for an un-mangled name doesn't work for
overloaded names.

Upon more thinking, I agree that BOTH declarations and call sites must be clearly pointed in the errors output by the linker. But I'll still point out that the real difficulty is finding the calls, not the declarations. I don't ever remember having a hard time "where is this declared?" Instead, the hard problem has always been "What is the call chain that leads to an undefined symbol?"

You're forgetting the case where the symbol *is* defined, but you forgot to include it in the list of source files to link. In that case, knowing where the declaration is will tell you which source file you probably forgot to add to the linker command line. T -- Life would be easier if I had the source code. -- YHL
Oct 30 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Why can't the linking code be built into dmd? I am baffled :o).

This is possible, but a better question is how much work is required to do this? Walter was very slowly translating the current linker from disassembly to C. If and once that program is all C, it's probably not too much hard to convert it to D, merge it with the dmd binary, and improve it in some ways. Bye, bearophile
Oct 29 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 30, 2012 01:45:31 bearophile wrote:
 Andrei Alexandrescu:
 Why can't the linking code be built into dmd? I am baffled :o).

This is possible, but a better question is how much work is required to do this? Walter was very slowly translating the current linker from disassembly to C. If and once that program is all C, it's probably not too much hard to convert it to D, merge it with the dmd binary, and improve it in some ways.

Depending, it should be fairly easy to just wrap the linker call and have dmd process its output and present something saner when there's an error. That could be a bit fragile though, since it would likely depend on the exact formatting of linker error messages. Better integration than that could be quite a bit more work. I think that it's fairly clear that in the long run, we want something like this, but I don't know if it's worth doing right now or not. - Jonathan M Davis
Oct 29 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Tue, 30 Oct 2012, Jonathan M Davis wrote:
 On Tuesday, October 30, 2012 01:45:31 bearophile wrote:
 Andrei Alexandrescu:
 Why can't the linking code be built into dmd? I am baffled :o).

This is possible, but a better question is how much work is required to do this? Walter was very slowly translating the current linker from disassembly to C. If and once that program is all C, it's probably not too much hard to convert it to D, merge it with the dmd binary, and improve it in some ways.

Depending, it should be fairly easy to just wrap the linker call and have dmd process its output and present something saner when there's an error. That could be a bit fragile though, since it would likely depend on the exact formatting of linker error messages. Better integration than that could be quite a bit more work. I think that it's fairly clear that in the long run, we want something like this, but I don't know if it's worth doing right now or not. - Jonathan M Davis

If someone wants to work on it, I'm sure no one would stop them. In fact, someone did a specific case already. But for the Top Men to engage on? Almost certainly not. I was working on "recognize that there's room for improvement" and "improvement is important for adoption" not "get working on it now". -- 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 pro: + compiler only needs to understand one format + one script per tool (also a con, but on the pro side, each script is focused in what it needs to understand and care about) + no need to tear into each tool to restructure it's i/o code cons: - will likely force some form of lowest common denominator - more overhead due to extra parsing and processes I used the term script, but don't read much into that, just implying that it's small and doesn't have to do much. Now that I've written it up.. might actually be fun to do, but I've got too many in-flight projects as it is, so I'll resist starting on it. Later, Brad
Oct 29 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Brad Roberts:

 To be clear, I'm certain that Andrei was kidding / making a 
 joke at Walter's expense.

Oh, I see, I have missed the joke again, sorry :-) Bye, bearophile
Oct 29 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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.
Oct 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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=10: 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 --=20 "A one-question geek test. If you get the joke, you're a geek: Seen on a Ca= lifornia license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - N= atural Intelligence, Inc.
Oct 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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...
Oct 30 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
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.
Oct 30 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
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.
Oct 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 30, 2012 at 08:55:26PM +0100, Jacob Carlborg wrote:
 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.

I have recently come to the conclusion that *all* programs should be written as (potential) libraries with thin executable wrappers. Any other approach will suffer from reusability issues down the road. T -- One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion
Oct 30 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:

 On 10/30/12 2:13 PM, Jesse Phillips wrote:
 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.

Not sure I'm following but essentially if foo() is undefined the most interesting file/line references would be for all calls to foo(). The lines declaring foo() are nice to have but much less interesting. Andrei

I don't think I agree. The key questions that come to mind from an undefined symbol error at link time are: 1) Why did the compiler believe it would be? If it didn't think it was a valid usable symbol, it would have already errored at the call site during semantic analysis. 2) what's the fully qualified name of the symbol? Maybe the compiler is matching a different symbol than expected. However, if that was the case, either it'd link against the unexpected match successfully, or see also #1. Having the location of some or all of the call sites might help you find #1, but that's a poor substitute for pointing directly at #1.
Oct 30 2012
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On Tue, 30 Oct 2012, Andrei Alexandrescu wrote:

 On 10/30/12 5:07 PM, Brad Roberts wrote:
 1) Why did the compiler believe it would be?  If it didn't think it was a
 valid usable symbol, it would have already errored at the call site during
 semantic analysis.

Not getting this at all. All I'm saying is that if the compiler says "I can't find that foo() you're asking for", the most interesting piece of information for me is "where did I ask for it?"

Ok, so it points to a place in the code where you used it. You look at that and say, yup, I did indeed use it. Not surprising. Now, why doesn't the linker find it? Why did the compiler believe it existed? The site of the usage isn't remotely useful for answering either of those questions and those are the ones that form the disconnect between the compiler, who believed it existed and let the code pass to the next stage), and the linker.
Oct 30 2012