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
>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
On Tue, 4 Jun 2002 10:36:34 -0500,
Joseph Pingenot <[email protected]> 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 <[email protected]>
#
# 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");
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
On Wed, 5 Jun 2002 02:25:59 -0500,
Joseph Pingenot <[email protected]> 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.
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
>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
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
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