public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: IPv4 NAT doesn't compile in 2.4.4
Date: Sat, 28 Apr 2001 22:21:45 +0100	[thread overview]
Message-ID: <20010428222145.I21792@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20010428172554.H21792@flint.arm.linux.org.uk> <15083.12585.159124.505983@pizda.ninka.net>
In-Reply-To: <15083.12585.159124.505983@pizda.ninka.net>; from davem@redhat.com on Sat, Apr 28, 2001 at 02:07:53PM -0700

On Sat, Apr 28, 2001 at 02:07:53PM -0700, David S. Miller wrote:
> Why would ip_nat_cleanup() be removed by the linker?

Because we explicitly tell the linker to drop all code marked as
__exit:

#define __exit          __attribute__ ((unused, __section__(".text.exit")))


>From x86 vmlinux.lds:

  /* Sections to be discarded */
  /DISCARD/ : {
        *(.text.exit)
        *(.data.exit)
        *(.exitcall.exit)
        }

>  All the "unused"
> attribute should do is shut up gcc if the thing is marked static yet
> not called.  The GCC manual even states "... means that the function
> is meant to be possibly unused.  GNU CC will not produce a warning
> for this function."  It makes no mention of any effect on the actual
> code output, or that the linker will delete it.

I quote from the ld info pages:

   The special output section name `/DISCARD/' may be used to discard
input sections.  Any input sections which are assigned to an output
section named `/DISCARD/' are not included in the output file.

> It doesn't remove the function on any platform I could test this on.

Try x86.

> If the linker removed it, why did it give a relocation truncation
> error instead of a missing symbol error?  And more importantly, what
> specifically was the reason that the linker removed the function on
> ARM, what made this happen?

Architecture independent linker behaviour.

> Please explain this in detail so we don't have to guess as I have
> seen no other report of this.

The reason it shows up on ARM is because the relocation is not 32-bit
long, and therefore the relocation it is trying to encode generates
an error.

(I'm presuming that it was allocating the symbol an address of zero,
but I haven't checked this since trying to call a non-present section
seems a bit stupid to start with).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2001-04-28 21:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-28 16:25 IPv4 NAT doesn't compile in 2.4.4 Russell King
2001-04-28 21:07 ` David S. Miller
2001-04-28 21:21   ` Russell King [this message]
2001-04-28 21:24     ` David S. Miller
2001-05-02  4:57 ` Rusty Russell

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=20010428222145.I21792@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=davem@redhat.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