Possible problem with ia64 binutils

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible problem with ia64 binutils

H.J. Lu-27
I rebuilt 2.4.21-37.EL ia64 kernel with 20051214 binutils. I got
several problems:

1. vfat kernel module won't load:

# modprobe vfat
/lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o: init_module:
Invalid argument
Hint: insmod errors can be caused by incorrect module parameters,
including invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
      /lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o: insmod
      /lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o failed
      /lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o: insmod vfat
      failed

module_arch_init: archdata->segment_base out of bounds.

2. autofs doesn't work:

Dec 16 15:28:47 gnu-12 automount[3723]: mount(nfs): mkdir_path /net/gnu-20/export failed: Operation not permitted


H.J.
Reply | Threaded
Open this post in threaded view
|

"ld -r" is broken

H.J. Lu-27
On Fri, Dec 16, 2005 at 03:37:18PM -0800, H. J. Lu wrote:

> I rebuilt 2.4.21-37.EL ia64 kernel with 20051214 binutils. I got
> several problems:
>
> 1. vfat kernel module won't load:
>
> # modprobe vfat
> /lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o: init_module:
> Invalid argument
> Hint: insmod errors can be caused by incorrect module parameters,
> including invalid IO or IRQ parameters.
>       You may find more information in syslog or the output from dmesg
>       /lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o: insmod
>       /lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o failed
>       /lib/modules/2.4.21-37.EL.1.2/kernel/fs/vfat/vfat.o: insmod vfat
>       failed
>
> module_arch_init: archdata->segment_base out of bounds.
>
> 2. autofs doesn't work:
>
> Dec 16 15:28:47 gnu-12 automount[3723]: mount(nfs): mkdir_path /net/gnu-20/export failed: Operation not permitted
>
I believe it is caused by

http://sourceware.org/ml/binutils/2005-11/msg00350.html

I am enclosing a tar file. There are good.o and bad.o, which are
generated by

# ld -o [good.o|bad.o] -r namei.o vfatfs_syms.o

bad.o is generated by the new linker. Alan, can you take a look?

Thanks.


H.J.

bug.tar.bz2 (41K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "ld -r" is broken

Alan Modra
On Fri, Dec 16, 2005 at 05:46:40PM -0800, H. J. Lu wrote:
> bad.o is generated by the new linker. Alan, can you take a look?

Sorry, not immediately.  I'm just about to leave for a week at the
beach with my family.

--
Alan Modra
IBM OzLabs - Linux Technology Centre
Reply | Threaded
Open this post in threaded view
|

Re: "ld -r" is broken

H.J. Lu-27
On Sat, Dec 17, 2005 at 12:46:44PM +1030, Alan Modra wrote:
> On Fri, Dec 16, 2005 at 05:46:40PM -0800, H. J. Lu wrote:
> > bad.o is generated by the new linker. Alan, can you take a look?
>
> Sorry, not immediately.  I'm just about to leave for a week at the
> beach with my family.
>

I opened a PR:

http://sourceware.org/bugzilla/show_bug.cgi?id=2065

and I am checking this testcase.


H.J.
---
2005-12-18  H.J. Lu  <[hidden email]>

        PR ld/2065
        * ld-elf/orphan2.d: New file.
        * ld-elf/orphan2.s: Likewise.

--- ld/testsuite/ld-elf/orphan2.d.xx 2005-12-18 14:32:46.000000000 -0800
+++ ld/testsuite/ld-elf/orphan2.d 2005-12-18 14:33:49.000000000 -0800
@@ -0,0 +1,8 @@
+#source: orphan2.s
+#ld: -r
+#readelf: -S --wide
+
+#...
+  \[[ 0-9]+\] \.text[ \t]+PROGBITS[ \t0-9a-f]+AX?.*
+  \[[ 0-9]+\] \.modinfo[ \t]+PROGBITS[ \t0-9a-f]+A.*
+#pass
--- ld/testsuite/ld-elf/orphan2.s.xx 2005-12-18 14:32:23.000000000 -0800
+++ ld/testsuite/ld-elf/orphan2.s 2005-12-18 14:31:56.000000000 -0800
@@ -0,0 +1,4 @@
+ .text
+ .long 0
+ .section .modinfo,"a","progbits"
+ .long 0
Reply | Threaded
Open this post in threaded view
|

PATCH:

H.J. Lu-27
On Sun, Dec 18, 2005 at 03:42:23PM -0800, H. J. Lu wrote:

> On Sat, Dec 17, 2005 at 12:46:44PM +1030, Alan Modra wrote:
> > On Fri, Dec 16, 2005 at 05:46:40PM -0800, H. J. Lu wrote:
> > > bad.o is generated by the new linker. Alan, can you take a look?
> >
> > Sorry, not immediately.  I'm just about to leave for a week at the
> > beach with my family.
> >
>
> I opened a PR:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=2065
>
> and I am checking this testcase.
>

The problem is introduced by

http://sourceware.org/ml/binutils/2005-11/msg00239.html

where the new prev field is never really set properly since the last
field used to set it points to the next field of the last element on
the list.

This hack seems to work for me. But I'd like to see the tail field in
lang_statement_list_type be removed if possible. Alan, can you take
a look after you come back?

Thanks.


H.J.
----
2005-12-18  H.J. Lu  <[hidden email]>

        PR ld/2065
        * ldlang.h (lang_statement_list_type): Add last.
        * ldlang.c (file_chain): Set the last field.
        (lang_list_init): Likewise.
        (lang_insert_orphan): Likewise.
        (lang_statement_append): Likewise.
        (output_statement_newfunc): Set os.prev with last.

--- ld/ldlang.c.prev 2005-12-18 09:40:59.000000000 -0800
+++ ld/ldlang.c 2005-12-18 14:29:57.000000000 -0800
@@ -89,7 +89,7 @@ static void lang_do_version_exports_sect
 lang_output_section_statement_type *abs_output_section;
 lang_statement_list_type lang_output_section_statement;
 lang_statement_list_type *stat_ptr = &statement_list;
-lang_statement_list_type file_chain = { NULL, NULL };
+lang_statement_list_type file_chain = { NULL, NULL, NULL };
 struct bfd_sym_chain entry_symbol = { NULL, NULL };
 static const char *entry_symbol_default = "start";
 const char *entry_section = ".text";
@@ -742,6 +742,7 @@ void
 lang_list_init (lang_statement_list_type *list)
 {
   list->head = NULL;
+  list->last = NULL;
   list->tail = &list->head;
 }
 
@@ -912,8 +913,10 @@ output_statement_newfunc (struct bfd_has
  (lang_statement_union_type *) &ret->os,
  &ret->os.header.next);
 
-  ret->os.prev = &((*lang_output_section_statement.tail)
-   ->output_section_statement);
+  if (lang_output_section_statement.last)
+    ret->os.prev
+      = &(lang_output_section_statement.last->output_section_statement);
+
   /* GCC's strict aliasing rules prevent us from just casting the
      address, so we store the pointer in a variable and cast that
      instead.  */
@@ -1531,7 +1534,10 @@ lang_insert_orphan (lang_input_statement
   /* Fix the global list pointer if we happened to tack our
      new list at the tail.  */
   if (*old->tail == add.head)
-    old->tail = add.tail;
+    {
+      old->last = add.last;
+      old->tail = add.tail;
+    }
 
   /* Save the end of this list.  */
   place->stmt = add.tail;
@@ -5836,6 +5842,7 @@ lang_statement_append (lang_statement_li
        lang_statement_union_type **field)
 {
   *(list->tail) = element;
+  list->last = element;
   list->tail = field;
 }
 
--- ld/ldlang.h.prev 2005-12-18 09:40:59.000000000 -0800
+++ ld/ldlang.h 2005-12-18 14:12:14.000000000 -0800
@@ -44,6 +44,7 @@ struct _fill_type
 typedef struct statement_list
 {
   union lang_statement_union *head;
+  union lang_statement_union *last;
   union lang_statement_union **tail;
 } lang_statement_list_type;