* problems with insmod ...
@ 2000-10-21 2:50 Jun Sun
2000-10-21 3:11 ` Ralf Baechle
2000-10-21 4:12 ` Keith Owens
0 siblings, 2 replies; 10+ messages in thread
From: Jun Sun @ 2000-10-21 2:50 UTC (permalink / raw)
To: linux-mips
I am using modutils v2.1.121, generated by binutils 2.8.1/egcs
v1.0.3a/glibc 2.0.6.
I have several problems with it.
In obj/obj_mipsel.c arch_apply_relocation() function, the mips_hi16_list
is not initialized to NULL before it is used as a list head. So, later,
insmod dies at trying to access 0x41.
(BTW, it seems horrible to me that arch_apply_relocation() remaps
obj_file struct to a local mips_file struct, destroying the original ELF
header struct. Is this safe?)
I kind of hacked around this problem (I don't know the real fix), but I
got some other problems. This time it is at obj/obj_reloc.c:410 -
sec->contents is 0x0. It seems to me that this section should be
included in load list at the first place. Does somebody why it is
there?
I dumped the section info here :
(gdb) p/x *f->load_order->load_next->load_next
$22 = {
header = {
sh_name = 0x36,
sh_type = 0x70000006,
sh_flags = 0x2,
sh_addr = 0xc00000e0,
sh_offset = 0xd0,
sh_size = 0x18,
sh_link = 0x0,
sh_info = 0x0,
sh_addralign = 0x4,
sh_entsize = 0x1
},
name = 0x1001bf26,
contents = 0x0,
load_next = 0x1001bd88,
idx = 0x5
}
=======
BTW, I seem to remember someone said the modutils 2.1.121 is not good
MIPS. Which version is good?
Jun
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: problems with insmod ...
2000-10-21 2:50 problems with insmod Jun Sun
@ 2000-10-21 3:11 ` Ralf Baechle
2000-10-21 4:12 ` Keith Owens
1 sibling, 0 replies; 10+ messages in thread
From: Ralf Baechle @ 2000-10-21 3:11 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips
On Fri, Oct 20, 2000 at 07:50:03PM -0700, Jun Sun wrote:
> In obj/obj_mipsel.c arch_apply_relocation() function, the mips_hi16_list
> is not initialized to NULL before it is used as a list head. So, later,
> insmod dies at trying to access 0x41.
>
> (BTW, it seems horrible to me that arch_apply_relocation() remaps
> obj_file struct to a local mips_file struct, destroying the original ELF
> header struct. Is this safe?)
>
> I kind of hacked around this problem (I don't know the real fix), but I
> got some other problems. This time it is at obj/obj_reloc.c:410 -
> sec->contents is 0x0. It seems to me that this section should be
> included in load list at the first place. Does somebody why it is
> there?
>
> I dumped the section info here :
>
> (gdb) p/x *f->load_order->load_next->load_next
> $22 = {
> header = {
> sh_name = 0x36,
> sh_type = 0x70000006,
> sh_flags = 0x2,
> sh_addr = 0xc00000e0,
> sh_offset = 0xd0,
> sh_size = 0x18,
> sh_link = 0x0,
> sh_info = 0x0,
> sh_addralign = 0x4,
> sh_entsize = 0x1
> },
> name = 0x1001bf26,
> contents = 0x0,
> load_next = 0x1001bd88,
> idx = 0x5
> }
This is a .reginfo section. MIPS specific and guaranteed to be useless.
The ABI says we should load it but they're useless, so inside the kernel
simply ignore it.
> BTW, I seem to remember someone said the modutils 2.1.121 is not good
> MIPS. Which version is good?
There are patched versions of 2.1.121 available which are usable. I've
uploaded source and binaries of 2.1.131 and Keith Owen's latest version
into oss.sgi.com:/pub/linux/mips/modutils.
Ralf
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: problems with insmod ...
2000-10-21 2:50 problems with insmod Jun Sun
2000-10-21 3:11 ` Ralf Baechle
@ 2000-10-21 4:12 ` Keith Owens
2000-10-23 18:45 ` Jun Sun
1 sibling, 1 reply; 10+ messages in thread
From: Keith Owens @ 2000-10-21 4:12 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips
On Fri, 20 Oct 2000 19:50:03 -0700,
Jun Sun <jsun@mvista.com> wrote:
>I am using modutils v2.1.121, generated by binutils 2.8.1/egcs
>v1.0.3a/glibc 2.0.6.
>
>BTW, I seem to remember someone said the modutils 2.1.121 is not good
>MIPS. Which version is good?
2.1.121 is over two years old and is missing several mips patches.
There is no good reason to use 2.1.121, modutils 2.3 is backwards
compatible.
The last mips specific patch was in modutils 2.3.15. 2.3.18 ignores
empty relocate sections which I believe were a problem for several
architectures, possibly including mips. 2.3.19 will be released this
weekend and includes a mips patch to fix a minor problem which I doubt
anybody has ever hit. If you need modutils now, use 2.3.18, if you can
wait 48 hours, wait for 2.3.19.
ftp://ftp.<country>.kernel.org/pub/linux/kernel/utils/modutils/v2.3.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: problems with insmod ...
2000-10-21 4:12 ` Keith Owens
@ 2000-10-23 18:45 ` Jun Sun
2000-10-23 22:32 ` Keith Owens
2000-10-23 22:42 ` Brady Brown
0 siblings, 2 replies; 10+ messages in thread
From: Jun Sun @ 2000-10-23 18:45 UTC (permalink / raw)
To: Keith Owens; +Cc: linux-mips
Keith Owens wrote:
>
> On Fri, 20 Oct 2000 19:50:03 -0700,
> Jun Sun <jsun@mvista.com> wrote:
> >I am using modutils v2.1.121, generated by binutils 2.8.1/egcs
> >v1.0.3a/glibc 2.0.6.
> >
> >BTW, I seem to remember someone said the modutils 2.1.121 is not good
> >MIPS. Which version is good?
>
> 2.1.121 is over two years old and is missing several mips patches.
> There is no good reason to use 2.1.121, modutils 2.3 is backwards
> compatible.
>
> The last mips specific patch was in modutils 2.3.15. 2.3.18 ignores
> empty relocate sections which I believe were a problem for several
> architectures, possibly including mips. 2.3.19 will be released this
> weekend and includes a mips patch to fix a minor problem which I doubt
> anybody has ever hit. If you need modutils now, use 2.3.18, if you can
> wait 48 hours, wait for 2.3.19.
>
> ftp://ftp.<country>.kernel.org/pub/linux/kernel/utils/modutils/v2.3.
I tried with 2.3.19, and now I am having problem with out of bound index
in symbol table. See the output below.
---------
sh-2.03# insmod hello.o
hello.o: local symbol gcc2_compiled. with index 10 exceeds
local_symtab_size 10
hello.o: local symbol __gnu_compiled_c with index 11 exceeds
local_symtab_size 10
hello.o: local symbol __module_kernel_version with index 12 exceeds
local_symtab_size 10
---------
I took a look. It appears that there is bug fix in v2.3.19 that checks
the symbol index against the table size, which in turn discovers this
bug.
Is this a ld bug? The sh_info field is indeed 10, but there are more
symbols.
I included the symbol table below, and the command line that I generate
the module.
----------
SYMBOL TABLE:
00000000 l d .modinfo 00000000
00000000 l d .rodata 00000000
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l d *ABS* 00000000
00000000 l d *ABS* 00000000
00000000 l d .note 00000000
00000000 l d .comment 00000000
00000000 l .text 00000000 gcc2_compiled.
00000000 l .text 00000000 __gnu_compiled_c
00000000 l O .modinfo 0000001b __module_kernel_version
00000000 g F .text 00000048 init_module
00000000 O *UND* 00000000 printk
00000048 g F .text 00000040 cleanup_module
-----------
Make command:
mips_5000_le-gcc -Wall -DMODULE -D__KERNEL__ -DLINUX -fno-pic -c hello.c
Jun
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: problems with insmod ...
2000-10-23 18:45 ` Jun Sun
@ 2000-10-23 22:32 ` Keith Owens
2000-10-24 0:40 ` Ralf Baechle
2000-10-23 22:42 ` Brady Brown
1 sibling, 1 reply; 10+ messages in thread
From: Keith Owens @ 2000-10-23 22:32 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips
On Mon, 23 Oct 2000 11:45:22 -0700,
Jun Sun <jsun@mvista.com> wrote:
>I tried with 2.3.19, and now I am having problem with out of bound index
>in symbol table. See the output below.
>
>---------
>sh-2.03# insmod hello.o
>hello.o: local symbol gcc2_compiled. with index 10 exceeds
>local_symtab_size 10
>hello.o: local symbol __gnu_compiled_c with index 11 exceeds
>local_symtab_size 10
>---------
It is a toolchain bug, I think it is in the assembler. I have a dim
distant memory from about a month ago that somebody on linux-mips found
the problem. Ask the toolchain experts.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: problems with insmod ...
2000-10-23 22:32 ` Keith Owens
@ 2000-10-24 0:40 ` Ralf Baechle
2000-10-24 1:08 ` Jun Sun
0 siblings, 1 reply; 10+ messages in thread
From: Ralf Baechle @ 2000-10-24 0:40 UTC (permalink / raw)
To: Keith Owens; +Cc: Jun Sun, linux-mips
On Tue, Oct 24, 2000 at 09:32:03AM +1100, Keith Owens wrote:
> On Mon, 23 Oct 2000 11:45:22 -0700,
> Jun Sun <jsun@mvista.com> wrote:
> >I tried with 2.3.19, and now I am having problem with out of bound index
> >in symbol table. See the output below.
> >
> >---------
> >sh-2.03# insmod hello.o
> >hello.o: local symbol gcc2_compiled. with index 10 exceeds
> >local_symtab_size 10
> >hello.o: local symbol __gnu_compiled_c with index 11 exceeds
> >local_symtab_size 10
> >---------
>
> It is a toolchain bug, I think it is in the assembler. I have a dim
> distant memory from about a month ago that somebody on linux-mips found
> the problem. Ask the toolchain experts.
It's a bug bug in ld, one in BFD and a sillyness in IRIX ELF which the linker
uses. IRIX ELF uses different sorting rules for the symbol table, see
mips_elf_sym_is_global in bfd/elf32-mips.c.
- Bug one: ld generated output should follow the same rules as assembler
generated output.
- Bug two is more a design flaw - why does Linux/MIPS and most other
MIPS ELF configurations use IRIX and not ABI ELF?
- Bug three is that mips_elf_sym_is_global applies these IRIX ELF sorting
rules even to ABI ELF.
Ralf
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: problems with insmod ...
2000-10-24 0:40 ` Ralf Baechle
@ 2000-10-24 1:08 ` Jun Sun
2000-10-24 1:18 ` Ralf Baechle
0 siblings, 1 reply; 10+ messages in thread
From: Jun Sun @ 2000-10-24 1:08 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Keith Owens, linux-mips
Ralf Baechle wrote:
>
> On Tue, Oct 24, 2000 at 09:32:03AM +1100, Keith Owens wrote:
>
> > On Mon, 23 Oct 2000 11:45:22 -0700,
> > Jun Sun <jsun@mvista.com> wrote:
> > >I tried with 2.3.19, and now I am having problem with out of bound index
> > >in symbol table. See the output below.
> > >
> > >---------
> > >sh-2.03# insmod hello.o
> > >hello.o: local symbol gcc2_compiled. with index 10 exceeds
> > >local_symtab_size 10
> > >hello.o: local symbol __gnu_compiled_c with index 11 exceeds
> > >local_symtab_size 10
> > >---------
> >
> > It is a toolchain bug, I think it is in the assembler. I have a dim
> > distant memory from about a month ago that somebody on linux-mips found
> > the problem. Ask the toolchain experts.
>
> It's a bug bug in ld, one in BFD and a sillyness in IRIX ELF which the linker
> uses. IRIX ELF uses different sorting rules for the symbol table, see
> mips_elf_sym_is_global in bfd/elf32-mips.c.
>
> - Bug one: ld generated output should follow the same rules as assembler
> generated output.
> - Bug two is more a design flaw - why does Linux/MIPS and most other
> MIPS ELF configurations use IRIX and not ABI ELF?
> - Bug three is that mips_elf_sym_is_global applies these IRIX ELF sorting
> rules even to ABI ELF.
>
> Ralf
This sounds like a serious problem to me. So here are the questions :
1) is it fixed in the latest binutils?
2) is it worth fixed for binutil v2.8.1?
I might be able to fix this problem, but I surely need some fill-ins.
Jun
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: problems with insmod ...
2000-10-24 1:08 ` Jun Sun
@ 2000-10-24 1:18 ` Ralf Baechle
2000-10-24 1:18 ` Ralf Baechle
0 siblings, 1 reply; 10+ messages in thread
From: Ralf Baechle @ 2000-10-24 1:18 UTC (permalink / raw)
To: Jun Sun; +Cc: Keith Owens, linux-mips
On Mon, Oct 23, 2000 at 06:08:35PM -0700, Jun Sun wrote:
> > > Jun Sun <jsun@mvista.com> wrote:
> > > >I tried with 2.3.19, and now I am having problem with out of bound index
> > > >in symbol table. See the output below.
> > > >
> > > >---------
> > > >sh-2.03# insmod hello.o
> > > >hello.o: local symbol gcc2_compiled. with index 10 exceeds
> > > >local_symtab_size 10
> > > >hello.o: local symbol __gnu_compiled_c with index 11 exceeds
> > > >local_symtab_size 10
> > > >---------
> > >
> > > It is a toolchain bug, I think it is in the assembler. I have a dim
> > > distant memory from about a month ago that somebody on linux-mips found
> > > the problem. Ask the toolchain experts.
> >
> > It's a bug bug in ld, one in BFD and a sillyness in IRIX ELF which the linker
> > uses. IRIX ELF uses different sorting rules for the symbol table, see
> > mips_elf_sym_is_global in bfd/elf32-mips.c.
> >
> > - Bug one: ld generated output should follow the same rules as assembler
> > generated output.
> > - Bug two is more a design flaw - why does Linux/MIPS and most other
> > MIPS ELF configurations use IRIX and not ABI ELF?
> > - Bug three is that mips_elf_sym_is_global applies these IRIX ELF sorting
> > rules even to ABI ELF.
> >
> > Ralf
>
> This sounds like a serious problem to me. So here are the questions :
>
> 1) is it fixed in the latest binutils?
No, all binutils ever are affected.
> 2) is it worth fixed for binutil v2.8.1?
Probably not. I believe modulo some testing current CVS binutils are ready
for more serious use than just binutils fixing. In any case fixing should
be easy.
Ralf
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: problems with insmod ...
2000-10-24 1:18 ` Ralf Baechle
@ 2000-10-24 1:18 ` Ralf Baechle
0 siblings, 0 replies; 10+ messages in thread
From: Ralf Baechle @ 2000-10-24 1:18 UTC (permalink / raw)
To: Jun Sun; +Cc: Keith Owens, linux-mips
On Mon, Oct 23, 2000 at 06:08:35PM -0700, Jun Sun wrote:
> > > Jun Sun <jsun@mvista.com> wrote:
> > > >I tried with 2.3.19, and now I am having problem with out of bound index
> > > >in symbol table. See the output below.
> > > >
> > > >---------
> > > >sh-2.03# insmod hello.o
> > > >hello.o: local symbol gcc2_compiled. with index 10 exceeds
> > > >local_symtab_size 10
> > > >hello.o: local symbol __gnu_compiled_c with index 11 exceeds
> > > >local_symtab_size 10
> > > >---------
> > >
> > > It is a toolchain bug, I think it is in the assembler. I have a dim
> > > distant memory from about a month ago that somebody on linux-mips found
> > > the problem. Ask the toolchain experts.
> >
> > It's a bug bug in ld, one in BFD and a sillyness in IRIX ELF which the linker
> > uses. IRIX ELF uses different sorting rules for the symbol table, see
> > mips_elf_sym_is_global in bfd/elf32-mips.c.
> >
> > - Bug one: ld generated output should follow the same rules as assembler
> > generated output.
> > - Bug two is more a design flaw - why does Linux/MIPS and most other
> > MIPS ELF configurations use IRIX and not ABI ELF?
> > - Bug three is that mips_elf_sym_is_global applies these IRIX ELF sorting
> > rules even to ABI ELF.
> >
> > Ralf
>
> This sounds like a serious problem to me. So here are the questions :
>
> 1) is it fixed in the latest binutils?
No, all binutils ever are affected.
> 2) is it worth fixed for binutil v2.8.1?
Probably not. I believe modulo some testing current CVS binutils are ready
for more serious use than just binutils fixing. In any case fixing should
be easy.
Ralf
--OgqxwSJOaUobr8KG--
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: problems with insmod ...
2000-10-23 18:45 ` Jun Sun
2000-10-23 22:32 ` Keith Owens
@ 2000-10-23 22:42 ` Brady Brown
1 sibling, 0 replies; 10+ messages in thread
From: Brady Brown @ 2000-10-23 22:42 UTC (permalink / raw)
To: Jun Sun; +Cc: Keith Owens, linux-mips
Jun Sun wrote:
> Keith Owens wrote:
> >
> > On Fri, 20 Oct 2000 19:50:03 -0700,
> > Jun Sun <jsun@mvista.com> wrote:
> > >I am using modutils v2.1.121, generated by binutils 2.8.1/egcs
> > >v1.0.3a/glibc 2.0.6.
> > >
> > >BTW, I seem to remember someone said the modutils 2.1.121 is not good
> > >MIPS. Which version is good?
> >
> > 2.1.121 is over two years old and is missing several mips patches.
> > There is no good reason to use 2.1.121, modutils 2.3 is backwards
> > compatible.
> >
> > The last mips specific patch was in modutils 2.3.15. 2.3.18 ignores
> > empty relocate sections which I believe were a problem for several
> > architectures, possibly including mips. 2.3.19 will be released this
> > weekend and includes a mips patch to fix a minor problem which I doubt
> > anybody has ever hit. If you need modutils now, use 2.3.18, if you can
> > wait 48 hours, wait for 2.3.19.
> >
> > ftp://ftp.<country>.kernel.org/pub/linux/kernel/utils/modutils/v2.3.
>
> I tried with 2.3.19, and now I am having problem with out of bound index
> in symbol table. See the output below.
>
> ---------
> sh-2.03# insmod hello.o
> hello.o: local symbol gcc2_compiled. with index 10 exceeds
> local_symtab_size 10
> hello.o: local symbol __gnu_compiled_c with index 11 exceeds
> local_symtab_size 10
> hello.o: local symbol __module_kernel_version with index 12 exceeds
> local_symtab_size 10
> ---------
>
> I took a look. It appears that there is bug fix in v2.3.19 that checks
> the symbol index against the table size, which in turn discovers this
> bug.
>
> Is this a ld bug? The sh_info field is indeed 10, but there are more
> symbols.
>
> I included the symbol table below, and the command line that I generate
> the module.
>
> ----------
> SYMBOL TABLE:
> 00000000 l d .modinfo 00000000
> 00000000 l d .rodata 00000000
> 00000000 l d .text 00000000
> 00000000 l d .data 00000000
> 00000000 l d .bss 00000000
> 00000000 l d *ABS* 00000000
> 00000000 l d *ABS* 00000000
> 00000000 l d .note 00000000
> 00000000 l d .comment 00000000
> 00000000 l .text 00000000 gcc2_compiled.
> 00000000 l .text 00000000 __gnu_compiled_c
> 00000000 l O .modinfo 0000001b __module_kernel_version
> 00000000 g F .text 00000048 init_module
> 00000000 O *UND* 00000000 printk
> 00000048 g F .text 00000040 cleanup_module
> -----------
>
> Make command:
>
> mips_5000_le-gcc -Wall -DMODULE -D__KERNEL__ -DLINUX -fno-pic -c hello.c
>
> Jun
There is a known issue right now with the .elf format generated by the mips
assembler. The assembler has the local symbol table ordering and size field
out of sync, consequently when insmod tries to install it, it fails because
there are more local symbols in the file than the 'inf' field in the file
header indicates. I think this is being looked into. As a 'dirty' work
around - the linker does appear to generate correct elf outputs so I am
currently linking all of my modules using the -r command line switch so the
output remains re-locatable. The readelf utility shows the symbol table
stuff if you are interested. After the incremental link the files insmod's
fine.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brady Brown (bbrown@ti.com) Work:(801)619-6103
Texas Instruments: Broadband Access Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2000-10-24 1:20 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-10-21 2:50 problems with insmod Jun Sun
2000-10-21 3:11 ` Ralf Baechle
2000-10-21 4:12 ` Keith Owens
2000-10-23 18:45 ` Jun Sun
2000-10-23 22:32 ` Keith Owens
2000-10-24 0:40 ` Ralf Baechle
2000-10-24 1:08 ` Jun Sun
2000-10-24 1:18 ` Ralf Baechle
2000-10-24 1:18 ` Ralf Baechle
2000-10-23 22:42 ` Brady Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox