http://d.puremagic.com/issues/show_bug.cgi?id=3453

           Summary: Linking order affects proper execution
           Product: D
           Version: 2.035
          Platform: x86_64
        OS/Version: Mac OS X
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: in-call@gmx.net


--- Comment #0 from Pablo Ripolles <in-call@gmx.net> 2009-10-29 16:08:57 PDT ---
Created an attachment (id=484)
sources, makefile and terminal window image capture

* Overview:

There are two source files, the main one (dependent) and the utility one
(dependency).  The separated compilation is successfully accomplished.  The
linking stage is also successfully accomplished but:

 1) If we proceed with this command:

 $ dmd -g utility.d main.d -ofhello

 Then on execution it fails.

 2) If we proceed with this command:

 $ dmd -g main.d utility.d -ofhello

 Then on execution it succeeds.

* Steps to Reproduce:

The attachment has the source files and a makefile with the second option disabled.  There is also a terminal window image capture with the CLI process.

Unzip the attachment.
$ make
$ ./hello

* Actual Results:

"Bus error"

* Expected Results:

"hello, world"

* Build Date & Platform:

Build 2009-10-30 on Mac OS 10.5.8

* Additional Builds and Platforms:

Does not occur on Build 2009-10-30 on GNU/Linux Debian 5.0.3

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453



--- Comment #1 from Michel Fortin <michel.fortin@michelf.com> 2010-01-01 10:00:16 EST ---
Created an attachment (id=540)
Simplified test case checking for uncalled static this.

Saw the same problem on Mac OS X 10.6.2. It looks like it's a static initializer problem: when the module with the main function is linked first static initializers are called, otherwise they aren't. The standard output stream isn't initialized correctly, causing an enforcement error to be thrown, but for some reason (perhaps the same reason) when this happens nothing is thrown and the program continues normally after 'throw' until it dereferences a null pointer.

Attached is a new simplified test case, which doesn't use std.stdio and isolate better the uncalled static initializer problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> 2010-01-01 12:23:42 PST ---
Sounds like the usual problem with the OSX ld linker, it has bugs putting sections into the order specified by the object file.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453



--- Comment #3 from Michel Fortin <michel.fortin@michelf.com> 2010-01-30 21:41:11 EST ---
I think I figured out what's happening. Indeed, the linker doesn't put the sections in the right order. The reason seems to be because dmd generates empty sections in all but the main object file, and those empty sections are skipped.

With the second "simplified" test case, if I compile other.d and use dumpobj to check the content of other.o, I get this:

[12] 000f4 0000 000564    2 0000   0 00000000 00 00 __minfo_beg __DATA
[13] 000f4 0004 000564    2 05e0   1 00000000 00 00 __minfodata __DATA
 0000:  20  0  0  0                                        ...
  [0] address x0000 section 2 pcrel 0 length 2 extern 0 type 0 RELOC_VANILLA
[14] 000f8 0000 000568    2 0000   0 00000000 00 00 __minfo_end __DATA

If on the other hand I take the "objdump -s" tool that comes with the developer tools, I see that it only sees __minfodata:

Contents of section LC_SEGMENT.__DATA.__minfodata:
 00f4 20000000                              ...

Looks like sections with no data in them are ignored. The reason it works when main.o is linked first is because in main.o sections __minfo_beg and __minfo_end are not empty.

So a solution could be to never leave a section empty. I hope this helps.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453



--- Comment #4 from Michel Fortin <michel.fortin@michelf.com> 2010-01-30 21:47:53 EST ---
Just a note to say that this also need to be fixed for the TLS segments.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453



--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2010-01-31 13:07:28 PST ---
You can see what order the sections wind up in the executable file by compiling with -map.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453



--- Comment #6 from Michel Fortin <michel.fortin@michelf.com> 2010-01-31 16:47:30 EST ---
(In reply to comment #5)
> You can see what order the sections wind up in the executable file by compiling with -map.

I did check the order in the executable (using the objdump system tool, not the -map option, but now I checked and they both give the same result). I agree this was missing form the previous report. Here is what -map gives me:

  0x00011F60    0x00000074    __DATA    __minfodata
  ...
  0x00012208    0x00000004    __DATA    __minfo_beg
  0x0001220C    0x00000004    __DATA    __minfo_end

So let me summarize what happens. What dmd generates, and what dumpobj (the
tool that comes with DMD) tells me is this (simplified view):

  other.o
  __minfo_beg, length 0
  __minfodata, length 4
  __minfo_end, length 0

  main.o
  __minfo_beg, length 4
  __minfodata, length 4
  __minfo_end, length 4

But what the system tool objdump tells me is this:

  other.o
  __minfodata, length 4

  main.o
  __minfo_beg, length 4
  __minfodata, length 4
  __minfo_end, length 4

Basically, it ignores zero-length sections.

Apparently the linker too ignores zero-length sections. You can conceptualize what the linker does in two steps. First it concatenates all object files:

  __minfodata, length 4
  __minfo_beg, length 4
  __minfodata, length 4
  __minfo_end, length 4

And then it merges sections with similar names:

  __minfodata, length 8
  __minfo_beg, length 4
  __minfo_end, length 4

And here you have the wrong order, similar to what is observed in the executable file. Linking main.o first doesn't exhibit this behaviour because its 'begin' and 'end' sections are not empty.

So a fix/workaround in DMD should be to make sure __minfo_beg and __minfo_end are never empty in generated object files. Can this be done?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453



--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> 2010-02-03 22:39:03 PST ---
changeset 363

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453



--- Comment #8 from Walter Bright <bugzilla@digitalmars.com> 2010-02-04 16:30:17 PST ---
Try again: changeset 365

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3453


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2010-03-08 22:25:24 PST ---
Fixed dmd 2.041

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------