FLTK demo apps on uClinux-MMU

Hi,

--- Quote Start ---

And is there another possible solution than building the libnano-X dynamically?

--- Quote End ---

This problem is caused by the incomplete implementation of 'tool chains' and there is no way of work-around except to implement those correctly.

And moreover, there is a problem that the size of GOT(Global Offset Table) is limited within 32Kbytes. This fact is not documented at all, but last week I had finally trodden on the tiger's tail.

 nios2-wrs-linux-gnu-gcc -I/mnt/usr/include -Wl,-rpath /mnt/usr/lib -g -shared  .libs/gtkquery.o .libs/gtksearchengine.o .libs/gtksearchenginesimple.o .libs/fnmatch.o .libs/gtkaboutdialog.o .libs/gtkaccelgroup.o .libs/gtkaccellabel.o .libs/gtkaccelmap.o .libs/gtkaccessible.o .libs/gtkaction.o .libs/gtkactiongroup.o .libs/gtkadjustment.o .libs/gtkalignment.o .libs/gtkarrow.o .libs/gtkaspectframe.o 
...............
.-Wl,--whole-archive xdgmime/.libs/libxdgmime.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gdk-pixbuf/.libs -Wl,--rpath -Wl,/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gdk/.libs -Wl,--rpath -Wl,/mnt/usr//lib -Wl,--rpath -Wl,/home/hamada/nios2-linux/uClinux-dist/staging/usr/lib -Wl,--rpath -Wl,/mnt/usr/lib -Wl,--rpath -Wl,/mnt/usr/lib -Wl,--rpath -Wl,/mnt/usr//lib -Wl,--rpath -Wl,/home/hamada/nios2-linux/uClinux-dist/staging/usr/lib -L/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gdk-pixbuf/.libs -L/mnt/usr/lib/ ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so -L/mnt/usr/lib ../gdk/.libs/libgdk-x11-2.0.so -L/mnt/usr//lib -L/home/hamada/nios2-linux/uClinux-dist/staging/usr/lib/ -L/home/hamada/nios2-linux/uClinux-dist/staging/usr/lib /mnt/usr//lib/libpangocairo-1.0.so /mnt/usr//lib/libpango-1.0.so /home/hamada/nios2-linux/uClinux-dist/staging/usr/lib/libX11.so /mnt/usr//lib/libXcomposite.so /mnt/usr//lib/libXdamage.so /mnt/usr//lib/libXfixes.so /mnt/usr//lib/libatk-1.0.so /mnt/usr/lib/libgobject-2.0.so /mnt/usr/lib/libgmodule-2.0.so /mnt/usr/lib/libglib-2.0.so /mnt/usr//lib/libcairo.so -lm  -Wl,-rpath -Wl,-soname -Wl,-version-script -Wl,.libs/libgtk-x11-2.0.ver -o .libs/libgtk-x11-2.0.so.0.1200.12
/home/hamada/nios2-linux/toolchain-mmu/x86-linux2/bin/../lib/gcc/nios2-wrs-linux-gnu/4.1.2/crtbeginS.o: In function `__do_global_dtors_aux':
crtstuff.c:(.text+0x2c): relocation truncated to fit: R_NIOS2_GOT16 against `__cxa_finalize@@GLIBC_2.10'
crtstuff.c:(.text+0x34): relocation truncated to fit: R_NIOS2_GOT16 against `__dso_handle'
crtstuff.c:(.text+0x3c): relocation truncated to fit: R_NIOS2_CALL16 against `__cxa_finalize@@GLIBC_2.10'
/home/hamada/nios2-linux/toolchain-mmu/x86-linux2/bin/../lib/gcc/nios2-wrs-linux-gnu/4.1.2/crtbeginS.o: In function `frame_dummy':
crtstuff.c:(.text+0xdc): relocation truncated to fit: R_NIOS2_GOT16 against `_Jv_RegisterClasses'
/home/hamada/nios2-linux/toolchain-mmu/x86-linux2/bin/../lib/gcc/nios2-wrs-linux-gnu/4.1.2/crtendS.o: In function `__do_global_ctors_aux':
crtstuff.c:(.text+0x18): relocation truncated to fit: R_NIOS2_GOT16 against `__CTOR_END__'
/home/hamada/nios2-linux/toolchain-mmu/x86-linux2/bin/../lib/gcc/nios2-wrs-linux-gnu/4.1.2/crtendS.o:(.init+0x0): relocation truncated to fit: R_NIOS2_CALL16 against `__do_global_ctors_aux'
.libs/gtkquery.o: In function `finalize':
/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gtk/gtkquery.c:44: relocation truncated to fit: R_NIOS2_CALL16 against `g_free'
.libs/gtkquery.o: In function `_gtk_query_init':
/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gtk/gtkquery.c:63: relocation truncated to fit: R_NIOS2_CALL16 against `_gtk_query_get_type'
.libs/gtkquery.o: In function `_gtk_query_new':
/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gtk/gtkquery.c:69: relocation truncated to fit: R_NIOS2_CALL16 against `_gtk_query_get_type'
.libs/gtkquery.o: In function `_gtk_query_set_text':
/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gtk/gtkquery.c:83: relocation truncated to fit: R_NIOS2_CALL16 against `g_free'
.libs/gtkquery.o: In function `_gtk_query_set_location':
/home/hamada/nios2-linux/uClinux-dist/lib/gtk+-2.12.12/gtk/gtkquery.c:97: additional relocation overflows omitted from the output
collect2: ld returned 1 exit status

Of course, All sources are compiled with '-fPIC', but nios2's compiler generates the code for dynamic linking like

  g_free (query->priv->text);
 1ac:    e0bffe17     ldw    r2,-8(fp)
 1b0:    10800317     ldw    r2,12(r2)
 1b4:    11000017     ldw    r4,0(r2)
 1b8:    b0800017     ldw    r2,0(r22)
 1bc:    103ee83a     callr    r2

and the relocation information is like

00000198  0000181a R_NIOS2_PCREL_LO  00000000   _GLOBAL_OFFSET_TABLE_ + 4
000001b8  00001f17 R_NIOS2_CALL16    00000000   g_free + 0
000001c0  00000916 R_NIOS2_GOT16     00000000   _gtk_query_parent_clas + 0

.

So we can't have a GTO which size is more than 32Kbyte and this is caused by the incomplete compiler implementations for code generations.

---nios2.md---
;; FIXME:these uses look unnecessary.
(define_insn "pic_load_addr"
   UNSPEC_PIC_SYM))
  (use (match_dup 1))]
  "flag_pic"
  "ldw\\t%0, %%got(%2)(%1)")
(define_insn "pic_load_call_addr"
   UNSPEC_PIC_CALL_SYM))
   (use (match_dup 1))]
  "flag_pic"
  "ldw\\t%0, %%call(%2)(%1)")
;; TLS support

But who will repair those?

Kazu

Some time ago already...

thanks for your reply, Kazu.

Anyway, I decided to build the library as an shared object.

Thank you for the precise analysis!

Some additional comments:

1) http://www.altera.com/literature/hb/nios2/n2cpu_nii5v1.pdf 7-12 documents the 64KB GOT limit:

Because the GOT-relative and TP-relative relocations are 16-bit relocations, no single

object file can require more than 64 KB of GOT and no dynamic object using local

dynamic or local executable thread-local storage (TLS) can have more than 64 KB of

TLS data. New relocations might be added to support this in the future.

It may be time to think about the mentioned future support for larger GOT via -fPIC.

2) To date this limitation seems to mainly affect C++ programs. C++ apparently likes to generate lots of global symbols. This URL documents a C++ library with 200,000 global symbols: http://gcc.gnu.org/wiki/visibility. Clearly that would swamp a 64KB GOT table, at least when naively used. (-fsection-anchors sounds like an attempt to be smarter about such things, but is apparently not supported on Nios2, at least as yet.)

3) I have one report of -Os (or -O2) resolving a similar issue. This is a workaround rather than a fix, but might be useful all the same.

Hi,

--- Quote Start ---

1) http://www.altera.com/literature/hb/nios2/n2cpu_nii5v1.pdf 7-12 documents the 64KB GOT limit:

Because the GOT-relative and TP-relative relocations are 16-bit relocations, no single

object file can require more than 64 KB of GOT and no dynamic object using local

dynamic or local executable thread-local storage (TLS) can have more than 64 KB of

TLS data. New relocations might be added to support this in the future.

It may be time to think about the mentioned future support for larger GOT via -fPIC.

--- Quote End ---

I don't know the recent situation, but I've posted an implimentation

http://www.alteraforum.com/forum/showthread.php?t=26331

, though it is not so complete. And I experienced the problem when my program grew beyond 32KB GOT boundary, not 64KB.

Kazu

--- Quote Start ---

Hi,

I don't know the recent situation, but I've posted an implementation

http://www.alteraforum.com/forum/showthread.php?t=26331

--- Quote End ---

That's a slick-looking patch! I've forwarded it to Walter Goosens (nios2-dev) who has encountered a similar problem. (For the moment he seems to be able to get around it by using -Os.) I'd like to see it (or something similar) upstreamed to the mainline gcc codebase...

--- Quote Start ---

,

And I experienced the problem when my program grew beyond 32KB GOT boundary, not 64KB.

Kazu

--- Quote End ---

Yes, CodeSourcery pointed out to me today that the current limit is in fact 32KB because the compiler is not (yet) using a biased GOT pointer on Nios2. I had not been aware of that. (A week ago I wasn't aware of this issue at all. :-))

Do you have an example program you can share which overruns the GOT? I have the impression that C++ is doing something to generate a lot of globals and overrun the GOT quickly. (http://gcc.gnu.org/wiki/visibility mentions a C++ library with 200000 globals.)

Having a concrete example in hand to reproduce this problem would be helpful.

Possibly we really should be fixing g++ to be more economical about generating globals, instead-of / as-well-as supporting larger GOTs...?

Hi,

--- Quote Start ---

Do you have an example program you can share which overruns the GOT? I have the impression that C++ is doing something to generate a lot of globals and overrun the GOT quickly. (http://gcc.gnu.org/wiki/visibility mentions a C++ library with 200000 globals.)

--- Quote End ---

I encountered this problem when I tried to build GTK programs. Please see

http://www.alterawiki.com/wiki/linux_with_mmu_on_veek/t-pad

. 'tangogps' and its libraries are working with larger GOTs.

Kazu