public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Josh McKinney <forming@home.com>
Cc: linux-kernel@vger.kernel.org, Jeff Garzik <jgarzik@mandrakesoft.com>
Subject: Re: Fwd: binutils in debian unstable is broken.
Date: Tue, 04 Dec 2001 21:42:46 -0800	[thread overview]
Message-ID: <3C0DB3D6.9C86B865@zip.com.au> (raw)
In-Reply-To: <20011205050513.GD1442@cy599856-a.home.com>

Josh McKinney wrote:
> 
> This seems to be a kernel bug which is shown with the new version of ld.  Thought I would
> forward this along so maybe it can get fixed.
> 
> ...
> drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols
> in discarded section .text.exit'

It is a kernel bug, and it's going to break a truckload
of PCI drivers, along with uhci_pci_remove().

What is happening is this:  a typical driver has:

static void __devexit remove_foo(...)
{}

static struct pci_driver foo_driver = {
	...
	remove: remove_foo;
};

The problem is that if foo.c is statically linked into the
kernel, and if CONFIG_HOTPLUG is not set, __devexit evaluates
to __exit.  And in vmlinux.lds we've asked the linker to
discard all the contents of section .text.exit.

The problem appears to be that the linker is now actually doing what
we asked it to do, so the `remove_foo' entry in that table now points
at a function which isn't going to be linked into the kernel.  Oh dear.

Workarounds are:

1) Enable CONFIG_HOTPLUG

2) Change vmlinux.lds so we don't drop the .text.exit section (this
   is effectively the same as 1)

3) Something else.  HJ's #ifdef MODULE works OK.  It has a rather
   internecine relationship with the workings of __devexit though.

  parent reply	other threads:[~2001-12-05  5:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05  5:05 Fwd: binutils in debian unstable is broken Josh McKinney
2001-12-05  5:20 ` Daniel T. Chen
2001-12-05  5:42 ` Andrew Morton [this message]
2001-12-05  6:41   ` Andrew Morton
2001-12-05  9:37     ` eddantes
2001-12-05 10:58     ` Mike Fedyk
2001-12-05  8:43   ` Alan Cox
2001-12-05  9:49     ` Jakub Jelinek
2001-12-05 13:34     ` Eric Lammerts
2001-12-05 14:18       ` Jeff Garzik
2001-12-06 15:09       ` Kai Germaschewski
2001-12-05 14:38 ` David Woodhouse
  -- strict thread matches above, loose matches on Subject: below --
2001-12-05  5:19 Frédéric L. W. Meunier
2001-12-05  5:25 ` Daniel T. Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C0DB3D6.9C86B865@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=forming@home.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox