Build error on 2.5.20 under unstable debian

Build error on 2.5.20 under unstable debian

[Joseph Pingenot]

ld -m elf_i386 -T /usr/local/src/kernel/linux-2.5.20/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/init.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o /usr/local/src/kernel/linux-2.5.20/arch/i386/lib/lib.a /usr/local/src/kernel/linux-2.5.20/lib/lib.a /usr/local/src/kernel/linux-2.5.20/arch/i386/lib/lib.a drivers/built-in.o sound/sound.o arch/i386/pci/pci.o net/network.o --end-group -o vmlinux
drivers/built-in.o(.rodata+0x20298): undefined reference to `local symbols in discarded section .text.exit'
make: *** [vmlinux] Error 1

Not sure how to debug this further.  Anyone know how to fix this or how
  to get more info?

Thanks!

-Joseph
-- 
Joseph======================================================jap3003@ksu.edu
"Ich bin ein Penguin."  --/. poster mmarlett, responding to news that the
  Bundestag will move to IBM/SuSE Linux.  
                      http://slashdot.org/comments.pl?sid=33588&cid=3631032

Re: Build error on 2.5.20 under unstable debian

[Joseph Pingenot]

>From Joseph Pingenot on Tuesday, 04 June, 2002:
>ld -m elf_i386 -T /usr/local/src/kernel/linux-2.5.20/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/init.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o /usr/local/src/kernel/linux-2.5.20/arch/i386/lib/lib.a /usr/local/src/kernel/linux-2.5.20/lib/lib.a /usr/local/src/kernel/linux-2.5.20/arch/i386/lib/lib.a drivers/built-in.o sound/sound.o arch/i386/pci/pci.o net/network.o --end-group -o vmlinux
>drivers/built-in.o(.rodata+0x20298): undefined reference to `local symbols in discarded section .text.exit'
>make: *** [vmlinux] Error 1

I just also got the same error with 2.5.19.
-- 
Joseph======================================================jap3003@ksu.edu
"Ich bin ein Penguin."  --/. poster mmarlett, responding to news that the
  Bundestag will move to IBM/SuSE Linux.  
                      http://slashdot.org/comments.pl?sid=33588&cid=3631032

Re: Build error on 2.5.20 under unstable debian

[Keith Owens]

On Tue, 4 Jun 2002 10:36:34 -0500, 
Joseph Pingenot <trelane@digitasaru.net> wrote:
>drivers/built-in.o(.rodata+0x20298): undefined reference to `local symbols in discarded section .text.exit'

Run this script to find out which low level object is causing the
problem.

#!/usr/bin/perl -w
#
# reference_discarded.pl (C) Keith Owens 2001 <kaos@ocs.com.au>
#
# List dangling references to vmlinux discarded sections.

use strict;
die($0 . " takes no arguments\n") if($#ARGV >= 0);

my %object;
my $object;
my $line;
my $ignore;

$| = 1;

printf("Finding objects, ");
open(OBJDUMP_LIST, "find . -name '*.o' | xargs objdump -h |") || die "getting objdump list failed";
while (defined($line = <OBJDUMP_LIST>)) {
	chomp($line);
	if ($line =~ /:\s+file format/) {
		($object = $line) =~ s/:.*//;
		$object{$object}->{'module'} = 0;
		$object{$object}->{'size'} = 0;
		$object{$object}->{'off'} = 0;
	}
	if ($line =~ /^\s*\d+\s+\.modinfo\s+/) {
		$object{$object}->{'module'} = 1;
	}
	if ($line =~ /^\s*\d+\s+\.comment\s+/) {
		($object{$object}->{'size'}, $object{$object}->{'off'}) = (split(' ', $line))[2,5]; 
	}
}
close(OBJDUMP_LIST);
printf("%d objects, ", scalar keys(%object));
$ignore = 0;
foreach $object (keys(%object)) {
	if ($object{$object}->{'module'}) {
		++$ignore;
		delete($object{$object});
	}
}
printf("ignoring %d module(s)\n", $ignore);

# Ignore conglomerate objects, they have been built from multiple objects and we
# only care about the individual objects.  If an object has more than one GCC:
# string in the comment section then it is conglomerate.  This does not filter
# out conglomerates that consist of exactly one object, can't be helped.

printf("Finding conglomerates, ");
$ignore = 0;
foreach $object (keys(%object)) {
	if (exists($object{$object}->{'off'})) {
		my ($off, $size, $comment, $l);
		$off = hex($object{$object}->{'off'});
		$size = hex($object{$object}->{'size'});
		open(OBJECT, "<$object") || die "cannot read $object";
		seek(OBJECT, $off, 0) || die "seek to $off in $object failed";
		$l = read(OBJECT, $comment, $size);
		die "read $size bytes from $object .comment failed" if ($l != $size);
		close(OBJECT);
		if ($comment =~ /GCC\:.*GCC\:/m) {
			++$ignore;
			delete($object{$object});
		}
	}
}
printf("ignoring %d conglomerate(s)\n", $ignore);

printf("Scanning objects\n");
foreach $object (keys(%object)) {
	my $from;
	open(OBJDUMP, "objdump -r $object|") || die "cannot objdump -r $object";
	while (defined($line = <OBJDUMP>)) {
		chomp($line);
		if ($line =~ /RELOCATION RECORDS FOR /) {
			($from = $line) =~ s/.*\[([^]]*).*/$1/;
		}
		if (($line =~ /\.text\.exit$/ ||
		     $line =~ /\.data\.exit$/ ||
		     $line =~ /\.exitcall\.exit$/) &&
		    ($from !~ /\.text\.exit$/ &&
		     $from !~ /\.data\.exit$/ &&
		     $from !~ /\.exitcall\.exit$/)) {
			printf("Error: %s %s refers to %s\n", $object, $from, $line);
		}
	}
	close(OBJDUMP);
}
printf("Done\n");

Re: Build error on 2.5.20 under unstable debian

[Joseph Pingenot]

Hey, thanks for the nifty tool.  What docs are available so that I can
  learn the Magic of the Script?  :)

Anyhow, the output for 2.5.20:

linux-2.5.20:9$ ./reference_discarded.pl 
Finding objects, 784 objects, ignoring 0 module(s)
Finding conglomerates, ignoring 102 conglomerate(s)
Scanning objects
Error: ./drivers/usb/host/uhci-hcd.o .rodata refers to 00000f98 R_386_32          .text.exit
Error: ./drivers/usb/host/built-in.o .rodata refers to 00000f98 R_386_32          .text.exit
Done

Looks like uhci-hcd.o and built-in.o are the culprits.  Now, if only
  I knew what the rest meant.  :)  They're referring to a symbol 
  R_386_32?  I'm going to assume this is an x86-based bit of stuff
  included from the x86-specific stuff.  Teach me.  ;)

-Joseph
--
Joseph======================================================jap3003@ksu.edu
"Ich bin ein Penguin."  --/. poster mmarlett, responding to news that the
  Bundestag will move to IBM/SuSE Linux.  
                      http://slashdot.org/comments.pl?sid=33588&cid=3631032

Re: Build error on 2.5.20 under unstable debian

[Keith Owens]

On Wed, 5 Jun 2002 02:25:59 -0500, 
Joseph Pingenot <trelane@digitasaru.net> wrote:
>Hey, thanks for the nifty tool.  What docs are available so that I can
>  learn the Magic of the Script?  :)

Years of hacking on ELF formats :(

>Error: ./drivers/usb/host/uhci-hcd.o .rodata refers to 00000f98 R_386_32          .text.exit
>Error: ./drivers/usb/host/built-in.o .rodata refers to 00000f98 R_386_32          .text.exit

Ignore drivers/usb/host/built-in.o, it is a conglomerate that contains
one object, the script cannot distinguish between that and a normal
object.

>Looks like uhci-hcd.o and built-in.o are the culprits.  Now, if only
>  I knew what the rest meant.  :)  They're referring to a symbol 
>  R_386_32?  I'm going to assume this is an x86-based bit of stuff
>  included from the x86-specific stuff.  Teach me.  ;)

R_386_32 is an ELF relocation type for ix86 binaries.  It means that
uhci-hcd.c has code that refers to a function defined as __exit.  The
only such function is uhci_hcd_cleanup but I cannot see where it is
being referenced.  The USB people should be able to track this one
down.

Re: Build error on 2.5.20 under unstable debian

[Adrian Bunk]

On Wed, 5 Jun 2002, Keith Owens wrote:

>...
> R_386_32 is an ELF relocation type for ix86 binaries.  It means that
> uhci-hcd.c has code that refers to a function defined as __exit.  The
> only such function is uhci_hcd_cleanup but I cannot see where it is
> being referenced.  The USB people should be able to track this one
> down.

uhci_stop is __devexit but the pointer to it doesn't use __devexit_p.
The fix is simple:

--- drivers/usb/host/uhci-hcd.c.old	Wed Jun  5 09:59:00 2002
+++ drivers/usb/host/uhci-hcd.c	Wed Jun  5 10:13:09 2002
@@ -2515,7 +2515,7 @@
 	suspend:		uhci_suspend,
 	resume:			uhci_resume,
 #endif
-	stop:			uhci_stop,
+	stop:			__devexit_p(uhci_stop),

 	hcd_alloc:		uhci_hcd_alloc,
 	hcd_free:		uhci_hcd_free,

cu
Adrian

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
								Alan Cox

Re: Build error on 2.5.20 under unstable debian

[Joseph Pingenot]

>From Adrian Bunk on Wednesday, 05 June, 2002:
>On Wed, 5 Jun 2002, Keith Owens wrote:
>uhci_stop is __devexit but the pointer to it doesn't use __devexit_p.
>The fix is simple:
>--- drivers/usb/host/uhci-hcd.c.old	Wed Jun  5 09:59:00 2002
>+++ drivers/usb/host/uhci-hcd.c	Wed Jun  5 10:13:09 2002
>@@ -2515,7 +2515,7 @@
> 	suspend:		uhci_suspend,
> 	resume:			uhci_resume,
> #endif
>-	stop:			uhci_stop,
>+	stop:			__devexit_p(uhci_stop),
>
> 	hcd_alloc:		uhci_hcd_alloc,
> 	hcd_free:		uhci_hcd_free,

Ah.  What does __devexit_p() do?  It looks to be some sort of macro,
  doing a cast?
And thanks, the patch solved the problem.  I'm currently running 2.5.20. :)

-Joseph
-- 
Joseph======================================================jap3003@ksu.edu
"Ich bin ein Penguin."  --/. poster mmarlett, responding to news that the
  Bundestag will move to IBM/SuSE Linux.  
                      http://slashdot.org/comments.pl?sid=33588&cid=3631032

Re: Build error on 2.5.20 under unstable debian

[Greg KH]

On Wed, Jun 05, 2002 at 10:18:52AM +0200, Adrian Bunk wrote:
> On Wed, 5 Jun 2002, Keith Owens wrote:
> 
> >...
> > R_386_32 is an ELF relocation type for ix86 binaries.  It means that
> > uhci-hcd.c has code that refers to a function defined as __exit.  The
> > only such function is uhci_hcd_cleanup but I cannot see where it is
> > being referenced.  The USB people should be able to track this one
> > down.
> 
> uhci_stop is __devexit but the pointer to it doesn't use __devexit_p.
> The fix is simple:

Applied to my tree, thanks.  I'll send to to Linus in a bit.

greg k-h

Re: Build error on 2.5.20 under unstable debian

[Adrian Bunk]

On Wed, 5 Jun 2002, Joseph Pingenot wrote:

> Ah.  What does __devexit_p() do?  It looks to be some sort of macro,
>   doing a cast?
>...

No, look at the definition in include/linux/init.h:

<--  snip  -->

...
/* Functions marked as __devexit may be discarded at kernel link time, depending
   on config options.  Newer versions of binutils detect references from
   retained sections to discarded sections and flag an error.  Pointers to
   __devexit functions must use __devexit_p(function_name), the wrapper will
   insert either the function_name or NULL, depending on the config options.
 */
#if defined(MODULE) || defined(CONFIG_HOTPLUG)
#define __devexit_p(x) x
#else
#define __devexit_p(x) NULL
#endif
...

<--  snip  -->


A bit more of explanation is in Documentation/pci.txt.


> -Joseph

cu
Adrian

-- 

You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
								Alan Cox