This is the mail archive of the
mailing list for the binutils project.
Re: Section symbols not getting created. Bug? Is attached patch correct fix?
On Thu, Apr 07, 2011 at 07:25:53AM +0200, John Marino wrote:
> Alan Modra wrote:
> >> Well, I think this is a case where the baby was thrown out with the
> >> bath water. I would have thought that backwards capability would
> >> have been provided with this change.
> > I don't recall anyone else complaining, and the change happened four
> > years ago.
> I don't know how to respond to that. It was a big change, one that
> ended up causing breaks, thus I would have expected backwards
> capability even if it were apparently unnecessary until now.
>From my viewpoint it wasn't a big change at all. I realize that you
might see things differently.
> >> Regarding the internal flag / .em suggestion, isn't that more or
> >> less equivalent to the patch on ldlang.c I provided earlier?
> >> Basically it would revert the behavior to work as binutils 2.17?
> > Yes, but based on a flag, only set for your particular target.
> "Target" means the thing getting linked? I assume you meant
> anything linked on a DragonFly OS. My modification to switch
> behavior based on the -shared / -Bshareable command-line switch
> seems to working so far.
What I meant by "target" was a bfd target, but I see now that you are
just using the standard i386 and x86_64 elf targets. It would
probably not be a good idea to create a special dragonfly target. On
the other hand, it's also not a great idea for you to go off and patch
your binutils, even if forking is the traditional way of resolving
conflicts in BSD land.
> > I do think that asking for __start_* and __stop_* to always be defined
> > for orphan sections is a rather odd requirement. What exactly do you
> > need them for? Surely not the dynamic loader?
> The kernel loader is using them. The file provided as a test case
> of the related bug report is a kernel module. It's beyond me, but I
> guess the loader is looking for these sections.
OK, so the correct thing to do is build your kernel modules with a
custom linker script that specifies the sections and required
symbols. That's quite easy, and you get to put the sections where you
want them rather than relying on ld's orhpan section placement.
Australia Development Lab, IBM