Building SID

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

Building SID

Michael Ambrus-2
Hi,
I'm new to sid and I'm having some problems building the project from
CVS sources.

My first attempt was with a cross-compiler which worked. except that
the I couldn't get the simulation to work properly (when setting CPU
registers in the simulated code and then queried the same with GDB,
the registers would still have the value 0). I thought if not setting
--target, it would make it work better. The documentation says that if
--target is not set, sid will try to build all the available CPU's.

What I'm not clear about is if one needs a cross compilers or not, and
in the case one does - would that be for every possible CPU sid
supports?

If cross compilers are meant to be used, which name should one use for
--target? I'm confused over that the canonical name for an x86
tool-chain normally would be i[[3456789]]86-*-*, but sid seems to use
the name x86 (or at least for the component i.e.).

A list of supported main architectures would be helpful.

Hers comes the lines where the build breaks:

make[4]: Entering directory `/home/ambrmi09/projects/sid/_BUILD/sid/bsp'
make[4]: *** No rule to make target `sh64-elf-sid', needed by `all-am'.  Stop.
make[4]: Leaving directory `/home/ambrmi09/projects/sid/_BUILD/sid/bsp'

The directory is there, but there's no trace of sh64. The ones existing:

arm-elf-sid
i386-elf-sid
m32r-elf-sid
  m68k-elf-sid
mt-elf-sid
xstormy16-elf-sid

The ChangeLog mentions  'sh-elf-sid,sh5-elf-sid,sh64-elf-sid: New
files' so I'm guessing the files were just not committed yet.

Regards
/Michael Anbrus
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Frank Ch. Eigler
Hi -

On Sun, Feb 25, 2007 at 08:37:41PM +0100, Michael Ambrus wrote:
> I'm new to sid and I'm having some problems building the project from
> CVS sources.

Welcome!

> My first attempt was with a cross-compiler which worked. except that
> the I couldn't get the simulation to work properly (when setting CPU
> registers in the simulated code and then queried the same with GDB,
> the registers would still have the value 0).

Are you sure you had gdb connected properly (target remote ...) and
all?  Which target?

> I thought if not setting --target, it would make it work better.

Actually, that should not improve this situation.

> The documentation says that if --target is not set, sid will try to
> build all the available CPU's.

That's correct.

> What I'm not clear about is if one needs a cross compilers or not, and
> in the case one does - would that be for every possible CPU sid
> supports?

No, we don't run cross-compilers during a sid build.  Only in order to
build programs that run on the various cpu models would one need them.

> [...]
> A list of supported main architectures would be helpful.

See the sid/components/CATALOG file.

> Hers comes the lines where the build breaks:
> make[4]: *** No rule to make target `sh64-elf-sid', needed by `all-am'.  
> The ChangeLog mentions  'sh-elf-sid,sh5-elf-sid,sh64-elf-sid: New
> files' so I'm guessing the files were just not committed yet.

That's probably right, it must be an oversight.

- FChE

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
On 2/26/07, Frank Ch. Eigler <[hidden email]> wrote:
> Hi -
>
> On Sun, Feb 25, 2007 at 08:37:41PM +0100, Michael Ambrus wrote:
> > I'm new to sid and I'm having some problems building the project from
> > CVS sources.
>
> Welcome!

Thanx :)

>
> > My first attempt was with a cross-compiler which worked. except that
> > the I couldn't get the simulation to work properly (when setting CPU
> > registers in the simulated code and then queried the same with GDB,
> > the registers would still have the value 0).
>
> Are you sure you had gdb connected properly (target remote ...) and
> all?  Which target?

Pretty much. The target tried was i386-hixs-elf (hixs is a layer that
replaces the syscalls with "hooked" versions - i.e. function
pointers). I haven't worked with x86 for years, so it might be me
forgetting something (protected mode stuff?).

I just swapped the target from an existing PowerPC set-up because I'm
currently in an area not strictly architecture dependant and I needed
something faster than the remote GDB box I'm currently using.

> > I thought if not setting --target, it would make it work better.
>
> Actually, that should not improve this situation.

yes, I figured that too.

>
> > The documentation says that if --target is not set, sid will try to
> > build all the available CPU's.
>
> That's correct.
>
> > What I'm not clear about is if one needs a cross compilers or not, and
> > in the case one does - would that be for every possible CPU sid
> > supports?
>
> No, we don't run cross-compilers during a sid build.  Only in order to
> build programs that run on the various cpu models would one need them.
>

Cool.

> > [...]
> > A list of supported main architectures would be helpful.
>
> See the sid/components/CATALOG file.
>

OK, thanx.

> > Hers comes the lines where the build breaks:
> > make[4]: *** No rule to make target `sh64-elf-sid', needed by `all-am'.
> > The ChangeLog mentions  'sh-elf-sid,sh5-elf-sid,sh64-elf-sid: New
> > files' so I'm guessing the files were just not committed yet.
>
> That's probably right, it must be an oversight.
>
> - FChE
>
>

/Michael
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Dave Brolley-2
In reply to this post by Frank Ch. Eigler
Frank Ch. Eigler wrote:

>  
>> Hers comes the lines where the build breaks:
>> make[4]: *** No rule to make target `sh64-elf-sid', needed by `all-am'.  
>> The ChangeLog mentions  'sh-elf-sid,sh5-elf-sid,sh64-elf-sid: New
>> files' so I'm guessing the files were just not committed yet.
>>    
>
> That's probably right, it must be an oversight.
>
>  
You're right. It was an oversight. Now corrected.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
I've got the files thanx. They seem broken however....

The following is the first place where it breaks (I noticed that the
build system will not respect neither 'make -S'  nor  'export
MAKEFLAGS="-S" &&  make' - it seems that the recursive build is using
'make -k' no matter what I do).

../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error:
'sh_common_model' was not declared in this scope
../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error: wrong
number of template arguments (8, should be 5)
:
:
Which leads to this:

:
:
../../../../src/sid/component/cgen-cpu/sh/sh4-nofpu-defs.h:22: error:
forward declaration of 'class sh4_nofpu::sh4_nofpu_cpu'
../../../../src/sid/component/cgen-cpu/compCGEN.cxx:418: error:
invalid use of undefined type 'class sh4a_nofpu::sh4a_nofpu_cpu'
../../../../src/sid/component/cgen-cpu/sh/sh4a-nofpu-defs.h:22: error:
forward declaration of 'class sh4a_nofpu::sh4a_nofpu_cpu'
../../../../src/sid/component/cgen-cpu/compCGEN.cxx:426: error: cannot
convert 'sh5::sh5_compact_cpu*' to 'sid::component*' in return
../../../../src/sid/component/cgen-cpu/compCGEN.cxx:428: error: cannot
convert 'sh5::sh5_32media_cpu*' to 'sid::component*' in return
../../../../src/sid/component/cgen-cpu/compCGEN.cxx:430: error: cannot
convert 'sh5::sh5_64media_cpu*' to 'sid::component*' in return
make[7]: *** [compCGEN.lo] Error 1
make[6]: *** [all-recursive] Error 1
make[5]: *** [all] Error 2

gcc used is the native one for my system which is  i486-linux-gnu
(version 4.0). Note that the standard for forward declarations to
templates has changed (in case you're using an older compiler).

Best
/Michael


On 2/26/07, Dave Brolley <[hidden email]> wrote:

> Frank Ch. Eigler wrote:
> >
> >> Hers comes the lines where the build breaks:
> >> make[4]: *** No rule to make target `sh64-elf-sid', needed by `all-am'.
> >> The ChangeLog mentions  'sh-elf-sid,sh5-elf-sid,sh64-elf-sid: New
> >> files' so I'm guessing the files were just not committed yet.
> >>
> >
> > That's probably right, it must be an oversight.
> >
> >
> You're right. It was an oversight. Now corrected.
>
> Dave
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Dave Brolley-2
Michael Ambrus wrote:

> I've got the files thanx. They seem broken however....
>
> The following is the first place where it breaks (I noticed that the
> build system will not respect neither 'make -S'  nor  'export
> MAKEFLAGS="-S" &&  make' - it seems that the recursive build is using
> 'make -k' no matter what I do).
>
> ../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error:
> 'sh_common_model' was not declared in this scope
> ../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error: wrong
> number of template arguments (8, should be 5)
Compiles fine for me using

 >> gcc --version
gcc (GCC) 4.1.2 20060612 (prerelease) (GNUPro 06r1)

I can't tell for sure, because I don't know which file you were
compiling at the time, but it looks to me like sh_common_model is in the
global namespace, so I'm not sure why it can't be found. Perhaps a

'using namespace ::'

 is needed before the declaration of sh2_cpu?


> :
> :
> Which leads to this:
>
> :
> :
> ../../../../src/sid/component/cgen-cpu/sh/sh4-nofpu-defs.h:22: error:
> forward declaration of 'class sh4_nofpu::sh4_nofpu_cpu'
This forward declaration is intentional. Any idea why it would not be
allowed?
> gcc used is the native one for my system which is  i486-linux-gnu
> (version 4.0). Note that the standard for forward declarations to
> templates has changed (in case you're using an older compiler).
>
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Frank Ch. Eigler
In reply to this post by Michael Ambrus-2
Hi -

On Mon, Feb 26, 2007 at 01:44:54AM +0100, Michael Ambrus wrote:

> [...] The target tried was i386-hixs-elf (hixs is a layer that
> replaces the syscalls with "hooked" versions - i.e. function
> pointers). I haven't worked with x86 for years, so it might be me
> forgetting something (protected mode stuff?).

OK, you should be able to use --target=i386-elf and not bother with
all the other targets.

Since the i386 model is an import from BOCHS, its integration with the
other facilities (i.e., remote debugging) in sid may not have been
quite right.  Try running sid in a highly verbose mode - with
particular attention to the gdb-interface component.

- FChE

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
In reply to this post by Dave Brolley-2
On 2/26/07, Dave Brolley <[hidden email]> wrote:

> Michael Ambrus wrote:
> > I've got the files thanx. They seem broken however....
> >
> > The following is the first place where it breaks (I noticed that the
> > build system will not respect neither 'make -S'  nor  'export
> > MAKEFLAGS="-S" &&  make' - it seems that the recursive build is using
> > 'make -k' no matter what I do).
> >
> > ../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error:
> > 'sh_common_model' was not declared in this scope
> > ../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error: wrong
> > number of template arguments (8, should be 5)
> Compiles fine for me using
>
>  >> gcc --version
> gcc (GCC) 4.1.2 20060612 (prerelease) (GNUPro 06r1)
>
> I can't tell for sure, because I don't know which file you were
> compiling at the time, but it looks to me like sh_common_model is in the
> global namespace, so I'm not sure why it can't be found. Perhaps a
>

Oh sorry, here comes a longer version of the breaking:

make[7]: Entering directory
`/home/ambrmi09/projects/sid/_BUILD/sid/component/cgen-cpu'
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../../../src/sid/component/cgen-cpu -I. -I. -I..
-I../../../../src/sid/component/cgen-cpu/arm7t
-I../../../../src/sid/component/cgen-cpu/m32r
-I../../../../src/sid/component/cgen-cpu/mep
-I../../../../src/sid/component/cgen-cpu/mt
-I../../../../src/sid/component/cgen-cpu/sh
-I../../../../src/sid/component/cgen-cpu/xstormy16 -I../../include
-I../../../../src/sid/component/cgen-cpu/../../include -I../../../bfd
-I../../../../src/sid/component/cgen-cpu/../../../include   -g -O2
-MT compCGEN.lo -MD -MP -MF ".deps/compCGEN.Tpo" -c -o compCGEN.lo
../../../../src/sid/component/cgen-cpu/compCGEN.cxx; \
        then mv -f ".deps/compCGEN.Tpo" ".deps/compCGEN.Plo"; else rm
-f ".deps/compCGEN.Tpo"; exit 1; fi
  g++ -DHAVE_CONFIG_H -I. -I../../../../src/sid/component/cgen-cpu -I.
-I. -I.. -I../../../../src/sid/component/cgen-cpu/arm7t
-I../../../../src/sid/component/cgen-cpu/m32r
-I../../../../src/sid/component/cgen-cpu/mep
-I../../../../src/sid/component/cgen-cpu/mt
-I../../../../src/sid/component/cgen-cpu/sh
-I../../../../src/sid/component/cgen-cpu/xstormy16 -I../../include
-I../../../../src/sid/component/cgen-cpu/../../include -I../../../bfd
-I../../../../src/sid/component/cgen-cpu/../../../include -g -O2 -MT
compCGEN.lo -MD -MP -MF .deps/compCGEN.Tpo -c
../../../../src/sid/component/cgen-cpu/compCGEN.cxx  -fPIC -DPIC -o
.libs/compCGEN.o
In file included from ../../../../src/sid/component/cgen-cpu/sh/sh_compact.h:9,
                 from ../../../../src/sid/component/cgen-cpu/sh/sh2.h:9,
                 from ../../../../src/sid/component/cgen-cpu/compCGEN.cxx:40:
../../../../src/sid/component/cgen-cpu/sh/sh.h:98:1: warning:
"CGEN_CPU_FPU" redefined
In file included from ../../../../src/sid/component/cgen-cpu/compCGEN.cxx:33:
../../../../src/sid/component/cgen-cpu/mep/mep_ext2.h:76:1: warning:
this is the location of the previous definition
../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error:
'sh_common_model' was not declared in this scope
../../../../src/sid/component/cgen-cpu/sh/sh2.h:16: error: wrong
number of template arguments (8, should be 5)

I.e. the file that breaks the build should be compCGEN.cxx (?).


> 'using namespace ::'
>
>  is needed before the declaration of sh2_cpu?
>
>
> > :
> > :
> > Which leads to this:
> >
> > :
> > :
> > ../../../../src/sid/component/cgen-cpu/sh/sh4-nofpu-defs.h:22: error:
> > forward declaration of 'class sh4_nofpu::sh4_nofpu_cpu'
> This forward declaration is intentional. Any idea why it would not be
> allowed?

I'm not a C++ expert, but I recognize this (or a seemingly similar
issue) from before. I'll have look in my notes (if I can find them)
and compare the code with yours.

In that particular case it was a syntax change of the standard. But
since you're using an even newer version of gcc than I do, then this
might not be the case here.

/Michael
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
In reply to this post by Frank Ch. Eigler
> OK, you should be able to use --target=i386-elf and not bother with
> all the other targets.
>

I'm not sure that I can, but I'll try. The reason is related to why
sid is an interesting project to me. What I was using the first time
was a cross compiler that, even though build,host and target main
architectures are the same, targets a different "system".

I had some more thinking yesterday and It's actually quite strange
that sid started at all since that compiler is seriously patched. The
syscalls and crt0.o among others are replaced (I'm working on an
embedded file system to be used in conjunction with newlib). This is
the reason I can't use gdb-type of simulators and also why I can't use
native tools either.

The code is not architecture dependant, but since it's just below the
syscalls level, I've had to run and debug on a real target so far.
This is becoming increasingly slow and I'm looking for something
faster.

I've tried QEMU which works, but it's unfortunately even slower than
the real target.

Does sid rely on the code being debugged to interact with the
simulator using normal file streams or is every OP-code executed in a
virtual machine?

/Michael
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
In reply to this post by Frank Ch. Eigler
I synced the source just a minute ago, but the same compile problem is
still there. I had some time left to look at the issue.

Regarding SH, the problem relates to the sh2_cpu class in the sh2.h file:

  class sh2_cpu: public
sh_compact_cpu<sh2_cpu,sh2_cpu_cgen,sh2_idesc,sh2_scache,sh_common_model<sh2_sh2_model,sh2_cpu,sh2_idesc,sh2_scache>
>

I didn't investigate further for now, but modified  tconfig.in:

//#define SIDTARGET_SH @sidtarget_sh@
//#define SIDTARGET_SH64 @sidtarget_sh64@

That omits the SH target it seems.

Since I would like to try sid for more than one target (ARM and x86) I
tried to figure out if there would be an option for including all
targets *but* specific ones. The way sidtargets.m4 is written however,
it seems possible only to add targets explicitly. I'll see if I can
rewrite the logic so that both explicit inclusion and explicit
omission would be possible (i.e. something like
--disable-targets=<LIST> would be nice).

The build is then OK until component ARM is compiled.

Compiling the files arm.cxx and compTIMERS.cxx both give the same error:

/home/ambrmi09/projects/sid/src/sid/component/timers/arm7t/arm7t-timer.h:142:
error: looser throw specifier for 'virtual
armTimerNoSched::~armTimerNoSched()'
/home/ambrmi09/projects/sid/src/sid/component/timers/arm7t/arm7t-timer.h:70:
error: overriding 'virtual armTimer::~armTimer() throw ()'

I made the following change:

Index: sid/component/timers/arm7t/arm7t-timer.h
===================================================================
RCS file: /cvs/src/src/sid/component/timers/arm7t/arm7t-timer.h,v
retrieving revision 1.3
diff -r1.3 arm7t-timer.h
70c70
<   ~armTimer() throw () { }
---
>   ~armTimer()  { throw (1); }

Have a look if the pach seems OK.

The build now succedes and I'm looking forward to try sid...

Best
/Michael
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Dave Brolley-2
Michael Ambrus wrote:

> I synced the source just a minute ago, but the same compile problem is
> still there. I had some time left to look at the issue.

Thanks. It's difficult for me to look into it since I can't reproduce it.

>
> Compiling the files arm.cxx and compTIMERS.cxx both give the same error:
>
> /home/ambrmi09/projects/sid/src/sid/component/timers/arm7t/arm7t-timer.h:142:
>
> error: looser throw specifier for 'virtual
> armTimerNoSched::~armTimerNoSched()'
> /home/ambrmi09/projects/sid/src/sid/component/timers/arm7t/arm7t-timer.h:70:
>
> error: overriding 'virtual armTimer::~armTimer() throw ()'
>
> I made the following change:
>
> Index: sid/component/timers/arm7t/arm7t-timer.h
> ===================================================================
> RCS file: /cvs/src/src/sid/component/timers/arm7t/arm7t-timer.h,v
> retrieving revision 1.3
> diff -r1.3 arm7t-timer.h
> 70c70
> <   ~armTimer() throw () { }
> ---
>
>>   ~armTimer()  { throw (1); }
>
>
> Have a look if the pach seems OK.

This relates to the removal of throw () specifiers from the SID API
recently. The correct patch is to remove the throw specifier on
~armTimer completely. I'll test it and commit it, hopefully today.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
> Thanks. It's difficult for me to look into it since I can't reproduce it.

yes, I figured. Glad to help as much as I can delousing the class.

>
> This relates to the removal of throw () specifiers from the SID API
> recently. The correct patch is to remove the throw specifier on
> ~armTimer completely. I'll test it and commit it, hopefully today.
>

Great, thanx.

I just had a try with sid using x86 and it works great. It's not
lightning fast executing the code, but at least it loads much faster
than a real target and that what's been the biggest bottleneck for me
so far. It already helped me finding 1 real bottleneck in the code and
one bug (and I've only used it for 45 minuets! :) ).

I've not reached to the parts beneath the system calls yet, so I still
cant tell if sid will work for me all the way. But it looks very
promising so far.

BTW wouldn't it be nice to have some interactive command component
(user interface) for the console that starts sid? Something that could
also be available via gdb monitor commands. I find it difficult to
send signals to the debugged process when using graphical front-ends
like kdevelop or Eclipse. I have that problem with most real remote
debuggers too (but not all) and I can't figure out why.

The effect is that I can't halt the execution without killing the
debugger, which forces me start the session all over from the very
start. Any ideas...?

Regards
/Michael
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Dave Brolley-2
In reply to this post by Dave Brolley-2
Dave Brolley wrote:

> Michael Ambrus wrote:
>
>
>>
>> Compiling the files arm.cxx and compTIMERS.cxx both give the same error:
>>
>> /home/ambrmi09/projects/sid/src/sid/component/timers/arm7t/arm7t-timer.h:142:
>>
>> error: looser throw specifier for 'virtual
>> armTimerNoSched::~armTimerNoSched()'
>> /home/ambrmi09/projects/sid/src/sid/component/timers/arm7t/arm7t-timer.h:70:
>>
>> error: overriding 'virtual armTimer::~armTimer() throw ()'
>
> This relates to the removal of throw () specifiers from the SID API
> recently. The correct patch is to remove the throw specifier on
> ~armTimer completely. I'll test it and commit it, hopefully today.
I reviewed this again and have committed the attached patch which adds
the correct throw specifier to the destructor of armTimerNoSched.

Dave

>

2007-03-02  Dave Brolley  <[hidden email]>

        * arm7t-timer.h (~armTimerNoSched): New virtual destructor with empty
        throw specifier.


Index: sid/component/timers/arm7t/arm7t-timer.h
===================================================================
RCS file: /cvs/src/src/sid/component/timers/arm7t/arm7t-timer.h,v
retrieving revision 1.3
diff -c -p -r1.3 arm7t-timer.h
*** sid/component/timers/arm7t/arm7t-timer.h 12 Feb 2005 16:25:47 -0000 1.3
--- sid/component/timers/arm7t/arm7t-timer.h 2 Mar 2007 17:01:37 -0000
*************** class armTimerNoSched: public armTimer
*** 142,147 ****
--- 142,148 ----
  {
  public:
    armTimerNoSched();
+   ~armTimerNoSched() throw () {}
 
  private:
    callback_pin<armTimerNoSched> clockpin;
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Frank Ch. Eigler
In reply to this post by Michael Ambrus-2
Hi -

> [...] It already helped me finding 1 real bottleneck in the code and
> one bug (and I've only used it for 45 minuets! :) ). [...]

Cool!

> BTW wouldn't it be nice to have some interactive command component
> (user interface) for the console that starts sid?  [..]

Have you tried tksm?

- FChE
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
sid verified to work underneath syscalls - i.e. I can use it (yay!).

> > BTW wouldn't it be nice to have some interactive command component
> > (user interface) for the console that starts sid?  [..]
>
> Have you tried tksm?

Not until now.

configrun-sid -cpu=x86 -gdb=1234 -tksm
/tmp/sid-14508.conf:44: component type sid-control-tksm unknown
/tmp/sid-14508.conf:110: component tksm not found
/tmp/sid-14508.conf:114: component tksm not found
/tmp/sid-14508.conf:117: component tksm not found
Configuration error.  Aborting.

Is it some tcl path that needs to be set? I configured the project
with --prefix, so perhaps I need to add some environment variable?

what does tksim do? I don't seem to be able to find any reference in
the manual except the little flag for configrun-sid.

Dave: I'm building the tools for ARM right now - I'll get back ASAP
with results regarding the throw patch.

/MA
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Frank Ch. Eigler
Hi -

> sid verified to work underneath syscalls - i.e. I can use it (yay!).

Great.

> >> BTW wouldn't it be nice to have some interactive command component
> >> (user interface) for the console that starts sid?  [..]
> >
> >Have you tried tksm?
>
> Not until now.
>
> configrun-sid -cpu=x86 -gdb=1234 -tksm
> /tmp/sid-14508.conf:44: component type sid-control-tksm unknown
> [...]

tksm is a little tk-based gui for sid.  It lets one gaze lovingly at
all the simulation components, and all their glorious attributes.
Those suffering from an aggressive fingertip can even modify said
attributes.  This allows e.g. time to be stopped (via schedulers'
attributes).

tksm is built as a tk script on top of the general tcl<->sid bridge
component.  That in turn requires tcl development libraries/headers to
be available at build time.  Were those around?  Did you run a "make
install" and see the tksm source files be copied over?

- FChE
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
> tksm is a little tk-based gui for sid.  It lets one gaze lovingly at
> all the simulation components, and all their glorious attributes.
> Those suffering from an aggressive fingertip can even modify said
> attributes.  This allows e.g. time to be stopped (via schedulers'
> attributes).

Nice 1!

> tksm is built as a tk script on top of the general tcl<->sid bridge
> component.  That in turn requires tcl development libraries/headers to
> be available at build time.  Were those around?  Did you run a "make
> install" and see the tksm source files be copied over?

I had tcl dev installed but for tk only run-time libs  (both 8.4) :/

Dave, regarding the thow patch: you reverted to the same as it was 2
revisions ago. It chokes gcc 4.0 for some reason (something about a
loose throw...). Can't you put the thow() inside the {}?

/MA
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Dave Brolley-2
Michael Ambrus wrote:

>
> Dave, regarding the thow patch: you reverted to the same as it was 2
> revisions ago. It chokes gcc 4.0 for some reason (something about a
> loose throw...). Can't you put the thow() inside the {}?

Hmmm -- I don't see any destructor for armTimerNoSched in any previous
revision. However, I think the problem is that I forgot to add a
destructor to armTimerSched. Try this patch and let me know if it works
for you.

Dave


Index: sid/component/timers/arm7t/arm7t-timer.h
===================================================================
RCS file: /cvs/src/src/sid/component/timers/arm7t/arm7t-timer.h,v
retrieving revision 1.4
diff -c -p -r1.4 arm7t-timer.h
*** sid/component/timers/arm7t/arm7t-timer.h 2 Mar 2007 17:02:07 -0000 1.4
--- sid/component/timers/arm7t/arm7t-timer.h 2 Mar 2007 18:39:51 -0000
*************** class armTimerSched: public armTimer
*** 160,165 ****
--- 160,166 ----
  {
  public:
    armTimerSched();
+   ~armTimerSched() throw () {}
 
  private:
    friend class scheduler_event_subscription<armTimerSched>;
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
>
> Hmmm -- I don't see any destructor for armTimerNoSched in any previous
> revision.

http://sourceware.org/cgi-bin/cvsweb.cgi/src/sid/component/timers/arm7t/arm7t-timer.h.diff?r1=1.1&r2=1.2&cvsroot=sid&f=h

> destructor to armTimerSched. Try this patch and let me know if it works
> for you.
>

I just did, and it compiles (O_o). How utterly odd, because that is
exactly how the code looked before I patched it the first time. Oh
well never mind, the intricacies and magics of C++ never stops to
amaze me (nor scare the bejesus out of me) ;)


Frankey:
make install

:
make[3]: Entering directory `/home/ambrmi09/projects/sid/debug/tcl/unix'
Installing libtcl8.4.a to /home/ambrmi09/bin/skiff//lib/
Installing tclsh as /home/ambrmi09/bin/skiff//bin/tclsh8.4
Installing tclConfig.sh to /home/ambrmi09/bin/skiff//lib/
Installing libtclstub8.4.a to /home/ambrmi09/bin/skiff//lib/
Installing header files
Installing library files to /home/ambrmi09/bin/skiff//share/tcl8.4
Installing library http1.0 directory
Installing library http2.4 directory
Installing library opt0.4 directory
Installing library msgcat1.3 directory
Installing library tcltest2.2 directory
Installing library encoding directory
Installing top-level (.1) docs
Cross-linking top-level (.1) docs
:

But still no tksm... ;(

Cheers
/MA
Reply | Threaded
Open this post in threaded view
|

Re: Building SID

Michael Ambrus-2
In reply to this post by Frank Ch. Eigler
> (For popular usage though it's usually better to join a more
> established similar project.)

That would depend on your personal interests I'd say. I've given it a
lot of thought (several years actually) and I came to the conclusion
that there isn't any similar project. Ive done a few deeply embedded
applications with Linux, enough to know that addressing targets
smaller than 4MB RAM + 2M Flash is just not worth the trouble .  As
far as I know there isn't any kernel that can do what TinKer does -
the one that comes closest is RTEMS.  But what would be the fun in
joining a humongous project? TinKer is my third kernel (I wrote the
first one in -89) but I still enjoy very much each time I bring a new
target to life.

> The ELF reader in sid assumes a loadable program image, and uses the
> various segment headers to populate the simulated memory.  It does not
> perform relocations in the object-file/linkage sense, and it also does
> not include support for runtime linkage like ld.so in linux.  What
> kind of relocation particularly do you need?
>

TinKer is growing from a kernel to an OS (I never thought it would,
but it's within grasp so I figured why not). I.e. code needs to be
either loaded to virtual memory regions or relocated into a new memory
offset at load time (both techniques have existed for decades). I
spent some time today playing around with ELF and various linking
options and it turns out that I can relocate certain output formats
rather easily, especially PIC formats normally used for dynamic
libraries since given certain limitations, it can be used for
executables as well (PIE).

Reading various ELF specs is tremendously boring (especially those
written by Sun or Motorola), but I found the works of this great
author that is both fun reading and a great inspiration. If you enjoy
good reading and a few laughs: http://www.iecc.com/linker/

Cheers
/Michael

P.S. I still can't get -tksm to work. I've tried rebuilding without
--prefix and installing as root, patching the tclConfig.sh and
tkConfig.sh - nothing helps. I can't figure this one out... P.S.
12