[ell-i-developers] Re: Ellduino Emulator: Fixing issues for Linux (Ubuntu 12.04 LTS)

  • From: Asif Sardar <engr.asif.sardar@xxxxxxxxxxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Sun, 2 Mar 2014 21:31:00 +0200

Hello Pekka,

*> Hence, I presume the linker, which I think collect2 calls directly,
determines it itself from the other options.  [...]  Correction:  The >
linker seems to store the default linker script internally;*

You were right... the default linker script that GNU 'ld' uses resides
inside /usr/lib/ldscripts named as elf_x86_64.xc. It is also attached to
this email with lines 61-64 added about start and end peripherals ...


Now, the problem is that still making emulator with this default linker
script is not solved yet ...

1- The problem is that:
    system_init.c:111: undefined reference to `__peripheral_start'
    system_init.c:111: undefined reference to `__peripheral_end'

is still there.

2- seeing the default script with ld --verbose shows no changes made to
this linker file -> elf_x86_64.xc

3- I may be writing those lines for start and end peripherals at wrong
place.

Please see the changed elf_x86_64.xc file attached to this e-mail.


On Wed, Feb 26, 2014 at 8:14 AM, Pekka Nikander <pekka.nikander@xxxxxx>wrote:

> > I meant to say that the file is printed on command line only. I cannot
> find the file in the directory (to open and change it manually). What I was
> doing was to copy from command line and paste in my ../emulator/ld/linux.ld
> file. However, I noticed that I was using the script file from "ld
> --verbose" command ... But, in the emulator.mk file when I put --verbose
> to the LDFLAGS, I get correct GCC version used ...
>
> I still don't quite understand.  See below:
>
> > g++ -m32 -march=i386 -m32 -demangle --verbose -o sketch  main.o sketch.o
> ellduino.o "-L." "-L../variants/ellduino" "-lstm32f0" -lstdc++
> > ...
> > /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id
> --eh-frame-hdr -m elf_i386 --hash-style=gnu --as-needed -dynamic-linker
> /lib/ld-linux.so.2 -z relro -o sketch
> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu/crt1.o
> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu/crti.o
> /usr/lib/gcc/x86_64-linux-gnu/4.7/32/crtbegin.o -L. -L../variants/ellduino
> -L/usr/lib/gcc/x86_64-linux-gnu/4.7/32
> -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu
> -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib32 -L/lib/i386-linux-gnu
> -L/lib/../lib32 -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib32
> -L/usr/lib/gcc/x86_64-linux-gnu/4.7
> -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu
> -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -L/lib/i386-linux-gnu
> -L/usr/lib/i386-linux-gnu main.o sketch.o ellduino.o -lstm32f0 -lstdc++
> -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
> /usr/lib/gcc/x86_64-linux-gnu/4.7/32/crtend.o
> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu/crtn.o
>
> I don't see the linker script given above.  Hence, I presume the linker,
> which I think collect2 calls directly, determines it itself from the other
> options.  [...]  Correction:  The linker seems to store the default linker
> script internally; see below.
>
> > One other issue I wanted to share with you is that I found some linker
> script files at /usr/lib/ldscripts in my Ubuntu version of Linux ... most
> of the files were elfxx_i386 ... or elfxx_x86-64 and some files are
> i386linux.xx. From there I copied the linker script i386linux.x to
> ../emulator/ld/linux.ld and building emulator gives:
>
> I presume i386linux.x is simply guessed wrong.  Please try to get the
> compiler to be even more verbose so that you could really see what linker
> script is used.  I tested briefly with the arm-gcc, and with -Xlinker
> --verbose it spits out an internal linker script that I presume can be
> copy-pasted.
>
> You seem to have such output in your "ld-linker-script" attachment.  Are
> you sure your linux.ld file starts with the comment line "/* Script for -z
> ..." and you don't include the ======== delimiters?
>
> > Once this issue is being solved, then I guess the only problem that is
> left will be to put the memory locations for __peripheral_start and
> __peripheral_end in the linker script file to build the emulator
> successfully.
>
> I presume so.  There may be other minor issues, but most probably nothing
> as large as this.
>
> To me it looks like that you are almost there, you seem to be very close.
>
> --Pekka
>
>
>


-- 



*With Best Regards,Asif Sardar.+358 43 8265795*

Attachment: elf_x86_64.xc
Description: Binary data

Other related posts: