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



--- Comment #6 from Michel Fortin <michel.for...@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: -------

Reply via email to