www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3453] New: Linking order affects proper execution

reply d-bugmail puremagic.com writes:
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: -------
Oct 29 2009
next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 31 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jan 31 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 03 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 04 2010
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 08 2010