[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR

From: Klaus Rudolph
Subject: Re: Simulator for GCC Testing [was: RE: [Fwd: Re: [avr-gcc-list]GCC-AVR Register optimisations]]
Date: Wed, 16 Jan 2008 08:27:39 +0100
User-agent: Thunderbird (Windows/20071031)

Hi all,

I also however know that libbfd is a pain for us the way we use it
becuase over time it changes in ways we often don't care about, but
cuases trouble for our simulavrxx users who have to cause it to be built
and installed...then simulavrxx has to find and use it x-p
There has nothing changed which was a problem for simulavrxx. The only trouble comes from mixing headers with different libs.

I'm pretty sure one of my build clean-up activities should include just
including a suitable version of libbfd sources in simulavrxx
Oh no! We have discussed that a lot of times and I will not include any! sources from foreign projects. Not TCL/TK and not libbfd. There is no reason for it! The only problem is that we have the corresponding bfd.h with the libbfd compiled for avr. Nothing more must be fulfilled.

For a gcc test suite simulavrxx and simulavr are nearly the same. The decoder uses the same instruction set (sleep is not supported, but this instruction will not be part of any standard c code and also writing flash is not inside, but this is not what the compiler is interested in:-)

I have not understood why we need a reduced smaller simulavrxx for a test suite? Is the size a problem?

Back to the point of build tools:
Bill had done a lot for building the tool on different plattforms and a lot of searching all the dependencies. But all that work results actually in a very complex build system. As Knut allready mentioned, we actually have a build tool chain which must have python to build the tcl examples. That sounds very terrible for me and makes things much to complex.

From my point of view:
I use my own old Makefile with one config file which contains 2 lines of informations: path to libbfd and path to tcl/tk. Thats all. No need for any! kind of external tooling (autotools) and so on. Making things "automated simple" could result in complex results :-)

For a gcc test suite there is also no need for having tcl/tk or python or any other scripting language available. Simply read the elf-files and watch the results of simulation with some environment for automation. If there is a need for a more elaborate solution: let me know! Maybe I can do that for you!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]