Loading ...
Sorry, an error occurred while loading the content.
 

Stuck with make file - and need a helping hand...

Expand Messages
  • Mark Butcher
    Hi All I have been using the GNU tool chain successfully for some time but was using a very simple bat file for compiling. It compiled and built the complete
    Message 1 of 4 , May 12 9:52 AM
      Hi All

      I have been using the GNU tool chain successfully for some time but
      was using a very simple bat file for compiling. It compiled and built
      the complete project every time - this is of course highly inefficient.

      Recently I took some time studying the details of make and linker
      files and have had some success with the GNU tool chain for ARM and
      the Coldfire, where I use a proper make file so that only the modified
      files are recompiled.

      So I though it was finally time to clean up the project for the
      M9S12NE64 - but it has proved to be a dead end attempt at the moment
      and I really need some help from more experienced users.

      Here's the story:
      1. The old bat file was calling the compiler with an endless list of
      files and out came a linked ELF file.

      m6811-elf-gcc -IC:\MJBC\Internal\uTaskerBeta\Applications\uTaskerV1.3
      -D _HW_NE64 -D _GNU -g -Os -m68hcs12 -mshort
      -Wl,-m,m68hc12elfb,--defsym,vectors_addr=0xff80,-Map=uTaskerV1.3.map,--no-gc-sections
      -nostartfiles -o uTaskerV1.3.elf ..\..\..\uTasker\uTasker.c
      ..\..\..\uTasker\driver.c ..\..\..\uTasker\eth_drv.c
      ..\..\..\uTasker\watchdog.c ..\..\..\uTasker\umalloc.c
      ..\..\..\uTasker\GlobalTimer.c ..\..\..\uTasker\uFile.c
      ..\..\..\uTasker\low_power.c ..\..\..\uTasker\uNetwork.c
      ..\..\..\Hardware\NE64\NE64.c ..\..\..\uTasker\tty_drv.c
      ..\..\..\uTasker\iic_drv.c ..\..\..\stack\ethernet.c
      ..\..\..\stack\arp.c ..\..\..\stack\ip.c ..\..\..\stack\ip_utils.c
      ..\..\..\stack\icmp.c ..\..\..\stack\udp.c ..\..\..\stack\tcp.c
      ..\..\..\stack\smtp.c ..\..\..\stack\dns.c ..\..\..\stack\ftp.c
      ..\..\..\stack\tftp.c ..\..\..\stack\http.c ..\..\..\stack\telnet.c
      ..\..\..\stack\dhcp.c ..\..\..\stack\webutils.c ..\webInterface.c
      ..\application.c ..\debug.c ..\NetworkIndicator.c ..\KeyScan.c
      ..\LCD.c crt0.s

      The important things to note are the following:
      - the linking of the vector table at 0xff80
      - the nostartfiles so that my own crt0.s is used (with a certain
      memory initialisation which is important)
      - --no-gc-sections - I don't actually know whether this does anything
      but it was suggested by someone a long time ago and has been used since.
      - Normally I have the map file generation step removed. It does
      generate the map but crashes when I do use it.
      - there is a variable called _end which is used in the program code to
      locate the first location of unused RAM. I don't know where this
      actually comes from but it has always been available and is shown in
      the map file as follows:
      0x00002d7c PROVIDE (_end, .)

      I have always used a simple memory.x (from Freescale) as follows:

      MEMORY
      {
      ioports (!x) : org = 0x0000, l = 0x0400
      eeprom (!i) : org = 0x, l = 0x
      page0 (rwx) : ORIGIN = 0x400, LENGTH = 0x4000 - 0x400
      data : ORIGIN = 0x2000 + 2*0x400 + 0x400, LENGTH = 0x2000 -
      2*0x400 - 0x400
      text (rx) : ORIGIN = 0x4000, LENGTH = 0xb780
      /* 0xc000 - 0x880 */
      page1 (rwx) : ORIGIN = 0xff80, LENGTH = 256
      }

      SECTIONS
      {
      .text : { *(.text) } > text
      }

      /* Setup the stack on the top of the data internal ram (not used). */
      PROVIDE (_stack = 0x4000-1);
      PROVIDE (_io_ports = 0x1000);





      Now to the new make file. Now I have the standard list of dependencies
      for the crt0.s and the C-files (just 2 are shown for reference) - and
      these compile correctly and object files are places into my directory
      called "build"

      eg. of C-compile dependency in make:
      Build\application.o: ..\application.c $(DEPENDS) ..\application.h
      m6811-elf-gcc $(C_FLAGS) -I..\..\uTaskerV1.3 -D _GNU -D _HW_NE64 -g
      -c -Os ..\application.c -o Build\application.o

      eg. of Assembler dependeny in make:
      Build\crt0.o: ..\..\..\Hardware\NE64\crt0.s memory.x
      m6811-elf-gcc $(C_FLAGS) -D _GNU -D _HW_NE64 -g -c -Os
      ..\..\..\Hardware\NE64\crt0.s -o Build\crt0.o


      The problem that I have is with the linking step, where I have tried
      for many hours to get it doing what I want but with no real success.
      Here is the present state of it.

      m6811-elf-gcc $(C_FLAGS)
      -Wl,-m,m68hc12elfb,--defsym,vectors_addr=0xff80,-nostartfiles,-Map=uTaskerV1.3.map,--no-gc-sections
      -Tmemory.x -o uTaskerV1.3.elf $(OBJS)


      It has the following problems:
      - the nostartfiles option doesn't seem to be working. I am getting
      multiple _starts (one from the library and one from my crt0)
      - _end is no longer being generated.
      - there are various other linking errors which seem to be from
      libraries and assembler routines which I have never seem before - the
      errors are at the end if anyone would like to see them:

      When I look at the new map file contents it seems to include
      references to crt1.o which I never had before.

      I think that real questions that I have are
      - why is _end generated by the first method but not by the second?
      - Why is there a problem with removing system startup files with the
      second method?
      - And what are the additional linking errors which were not an issue
      with the first method?

      (Note that the map generation does not crash when this make file is used)


      I am sorry if I am making a silly mistake somewhere but I have read
      documents and experimented for a long time but am just not getting
      anywhere so really do need a tip from a GNU expert.

      Thanks in advance.

      regards

      Mark Butcher















      LINKER ERRORS


      Build\crt0.o(.install0+0x0): In function `_start':
      : multiple definition of `_start'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\crt1.o(.install0+0x0):
      first defined here
      Build\NE64.o(.text+0x10): In function `main':
      ../../../Hardware/NE64/NE64.c:320: undefined reference to `_end'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_map_data.o)(.install2+0x1):
      In function `__map_data_section':
      config/m68hc11/larith.asm:1095: undefined reference to `__data_image'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_map_data.o)(.install2+0x4):config/m68hc11/larith.asm:1096:
      undefined reference to `__data_section_start'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_map_data.o)(.install2+0x7):config/m68hc11/larith.asm:1097:
      undefined reference to `__data_section_size'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_init_bss.o)(.install2+0x1):
      In function `__init_bss_section':
      config/m68hc11/larith.asm:1125: undefined reference to `__bss_size'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_init_bss.o)(.install2+0x6):config/m68hc11/larith.asm:1127:
      undefined reference to `__bss_start'
      collect2: ld returned 1 exit status
      Build\crt0.o(.install0+0x0): In function `_start':
      : multiple definition of `_start'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\crt1.o(.install0+0x0):
      first defined here
      Build\NE64.o(.text+0x10): In function `main':
      ../../../Hardware/NE64/NE64.c:320: undefined reference to `_end'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_map_data.o)(.install2+0x1):
      In function `__map_data_section':
      config/m68hc11/larith.asm:1095: undefined reference to `__data_image'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_map_data.o)(.install2+0x4):config/m68hc11/larith.asm:1096:
      undefined reference to `__data_section_start'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_map_data.o)(.install2+0x7):config/m68hc11/larith.asm:1097:
      undefined reference to `__data_section_size'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_init_bss.o)(.install2+0x1):
      In function `__init_bss_section':
      config/m68hc11/larith.asm:1125: undefined reference to `__bss_size'
      C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\m68hc12/mshort\libgcc.a(_init_bss.o)(.install2+0x6):config/m68hc11/larith.asm:1127:
      undefined reference to `__bss_start'
    • Jefferson Smith
      ... -Wl,-m,m68hc12elfb,--defsym,vectors_addr=0xff80,-Map=uTaskerV1.3.map,--no-gc-sections ... I m real sorry that I don t have time to work on this, but here
      Message 2 of 4 , May 18 10:10 AM
        --- In gnu-m68hc11@yahoogroups.com, "Mark Butcher" <markbutcher@...>
        wrote:

        > Here's the story:
        > 1. The old bat file was calling the compiler with an endless list of
        > files and out came a linked ELF file.
        >
        > m6811-elf-gcc -IC:\MJBC\Internal\uTaskerBeta\Applications\uTaskerV1.3
        > -D _HW_NE64 -D _GNU -g -Os -m68hcs12 -mshort
        >
        -Wl,-m,m68hc12elfb,--defsym,vectors_addr=0xff80,-Map=uTaskerV1.3.map,--no-gc-sections
        > -nostartfiles -o uTaskerV1.3.elf ..\..\..\uTasker\uTasker.c
        > ..\..\..\uTasker\driver.c ..\..\..\uTasker\eth_drv.c
        > ..\..\..\uTasker\watchdog.c ..\..\..\uTasker\umalloc.c
        > ..\..\..\uTasker\GlobalTimer.c ..\..\..\uTasker\uFile.c
        > ..\..\..\uTasker\low_power.c ..\..\..\uTasker\uNetwork.c
        > ..\..\..\Hardware\NE64\NE64.c ..\..\..\uTasker\tty_drv.c
        > ..\..\..\uTasker\iic_drv.c ..\..\..\stack\ethernet.c
        > ..\..\..\stack\arp.c ..\..\..\stack\ip.c ..\..\..\stack\ip_utils.c
        > ..\..\..\stack\icmp.c ..\..\..\stack\udp.c ..\..\..\stack\tcp.c
        > ..\..\..\stack\smtp.c ..\..\..\stack\dns.c ..\..\..\stack\ftp.c
        > ..\..\..\stack\tftp.c ..\..\..\stack\http.c ..\..\..\stack\telnet.c
        > ..\..\..\stack\dhcp.c ..\..\..\stack\webutils.c ..\webInterface.c
        > ..\application.c ..\debug.c ..\NetworkIndicator.c ..\KeyScan.c
        > ..\LCD.c crt0.s
        >
        > The important things to note are the following:
        > - the linking of the vector table at 0xff80
        > - the nostartfiles so that my own crt0.s is used (with a certain
        > memory initialisation which is important)
        > - --no-gc-sections - I don't actually know whether this does
        > anything but it was suggested by someone a long time ago and
        > has been used since.
        > - Normally I have the map file generation step removed. It does
        > generate the map but crashes when I do use it.
        > - there is a variable called _end which is used in the program
        > code to locate the first location of unused RAM. I don't know
        > where this actually comes from but it has always been available
        > and is shown in the map file as follows:
        > 0x00002d7c PROVIDE (_end, .)

        I'm real sorry that I don't have time to work on this, but here are
        some beginning observations:

        1. I guess the reason you feed a boatload of src files into a single
        gcc command is only because that seemed more efficient to avoid
        calling gcc repeatedly with the same options. You will want, however,
        to get used to the fact that one commandline typically compiles only
        one src file. Also, another seperate gcc command links all compiled
        object files together, passing only linker options.

        2. I notice that you are trying to manually pass some options that
        perhaps are only needed by the linker 'ld'. It will help a great deal
        if you study the commandline options for 'gcc', and note that there
        are many linking options which are only passed by you to gcc, and then
        it automatically handles what options to pass to ld.

        3. Although GEL examples may not seem useful for any practical
        purpose, they are extremely valuable for learning these exact things
        I've mentioned above. Study GEL as it builds in the "src" and
        "example" subdirs [thought things may only build for HC11], and try to
        figure out how things get done. Honestly I was just as naive as the
        worst of us, until I figured out how GEL Makefiles work.
      • Mark Butcher
        Hi ... The reason was not for efficiency since every file was being compiled even if not modified - but I did get it to work quite easily. Also there are no
        Message 3 of 4 , May 27 3:23 PM
          Hi

          > 1. I guess the reason you feed a boatload of src files into a single
          > gcc command is only because that seemed more efficient to avoid
          > calling gcc repeatedly with the same options. You will want, however,
          > to get used to the fact that one commandline typically compiles only
          > one src file. Also, another seperate gcc command links all compiled
          > object files together, passing only linker options.

          The reason was not for efficiency since every file was being compiled
          even if not modified - but I did get it to work quite easily. Also
          there are no object files left since these are only intermediates in
          the process (the down side is that the map shows the source files as
          very wierd, almost random numbers, since they are only temporary. All
          intermediate objects are cleaned up automatically.

          I now have a more classic make file with a directory collecting the
          objects so that make can work.

          >
          > 2. I notice that you are trying to manually pass some options that
          > perhaps are only needed by the linker 'ld'. It will help a great deal
          > if you study the commandline options for 'gcc', and note that there
          > are many linking options which are only passed by you to gcc, and then
          > it automatically handles what options to pass to ld.
          >
          > 3. Although GEL examples may not seem useful for any practical
          > purpose, they are extremely valuable for learning these exact things
          > I've mentioned above. Study GEL as it builds in the "src" and
          > "example" subdirs [thought things may only build for HC11], and try to
          > figure out how things get done. Honestly I was just as naive as the
          > worst of us, until I figured out how GEL Makefiles work.
          >


          I seem to have been able to work out the two linker problems.
          Here is the new ld command

          m6811-elf-gcc $(C_FLAGS) -nostartfiles
          -Wl,-m,m68hc12elfb,--defsym,vectors_addr=0xff80,--no-gc-sections
          -Tm68hc12elfb.x -o uTaskerV1.3.elf $(OBJS)

          1. I had to remove the -nostartfiles option outside of the -W1 list -
          putting it as first option solved the _start double define.
          2. I had to specify m68hc12elfb.x as the linker command file because
          this is defining the _end which was otherwise missing. It then calls
          the memory.x linker file as an include.

          Now the elf is correctly generated.

          There are however 2 problems still.
          1. When the map file is generated it crashes. This was happening with
          the original bat file build also. The map file is generated though, so
          its output is useable.
          2. objcopy is now failing.

          objcopy --only-section=.data --only-section=.init --only-section=.text
          --only-section=.rodata --only-section=.vectors --output-target=srec
          uTaskerV1.3.elf uTaskerV1.3.s19

          ERROR MESSAGE
          process_begin: CreateProcess((null), objcopy --only-section=.data
          --only-section=.init --only-section=.text --only-section=.rodata
          --only-section=.vectors --output-target=srec uTaskerV1.3.elf
          uTaskerV1.3.s19, ...) failed.
          make (e=2): The system can not find the specified data.
          make: *** [uTaskerV1.3.elf] Error 2


          I have seen that the ELF which is now being generated is not exactly
          the same size as the ELF being generated by the old bat file. I assume
          that the objcopy is also failing due to some invalid content.

          I have seen this CreateProcess((null) error once before but could
          never work out why it can happen.

          Any one have any ideas how to continue?

          Regards

          Mark
        • Jeff Smith
          Here are some quick observations... ... I don t see why you need both -Wl,-m,m68hc12elfb and -Tm68hc12elfb.x because the -m m68hc12elfb indicates to use
          Message 4 of 4 , May 27 6:44 PM
            Here are some quick observations...

            --- Mark Butcher <markbutcher@...> wrote:
            > I seem to have been able to work out the two linker problems.
            > Here is the new ld command
            >
            > m6811-elf-gcc $(C_FLAGS) -nostartfiles
            > -Wl,-m,m68hc12elfb,--defsym,vectors_addr=0xff80,--no-gc-sections
            > -Tm68hc12elfb.x -o uTaskerV1.3.elf $(OBJS)
            >
            > 1. I had to remove the -nostartfiles option outside of the -W1 list -
            > putting it as first option solved the _start double define.
            > 2. I had to specify m68hc12elfb.x as the linker command file because
            > this is defining the _end which was otherwise missing. It then calls
            > the memory.x linker file as an include.

            I don't see why you need both "-Wl,-m,m68hc12elfb" and "-Tm68hc12elfb.x"
            because the "-m m68hc12elfb" indicates to use the default script
            "m68hc12elfb.x". You only add -T if you need to override the default name.

            The doc seems to indicate that you would not need "--no-gc-sections"
            because it says that is the default (unless somewhere else you are
            enabling gc-sections):

            ==== from ld documentation ====
            --no-gc-sections
            --gc-sections
            Enable garbage collection of unused input sections. It is ignored on
            targets that do not support this option. This option is not compatible
            with `-r'. The default behaviour (of not performing this garbage
            collection) can be restored by specifying `--no-gc-sections' on the
            command line.
            ==== end ld documentation ====

            > Now the elf is correctly generated.
            >
            > There are however 2 problems still.
            > 1. When the map file is generated it crashes. This was happening with
            > the original bat file build also. The map file is generated though, so
            > its output is useable.

            Don't you hate when that happens? Seems to be a serious problem, but the
            option such as -Map just does not work until someone figures out how to
            fix it. I think it has to do with some lookup returning an invalid pointer
            or something.






            ____________________________________________________________________________________Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
            http://answers.yahoo.com/dir/?link=list&sid=396545469
          Your message has been successfully submitted and would be delivered to recipients shortly.