http://d.puremagic.com/issues/show_bug.cgi?id=3453
--- Comment #6 from Michel Fortin <[email protected]> 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: -------
