gdb + 68360 + bdm

gdb + 68360 + bdm

[Stephane Dalton]

Hi there,

	I've succesfully compile gdb 4-18 with bdm patches and personal
tweaks to work with ICD cable and have correct access to MBAR register. Now
I've a couple of questions:

- I'm not able to trace code which access the vbr, sfc and dfc register and
trying to get the address of a variable allocated on the stack I get 0x0???

My target is 68360, am I the only one with this problem? (it seems that I'll
have to write a howto on this one too... :)

Any answer appreciated!

Thanks

P.S. (Is there any other lists I can send such a question and hope for
knowledgeable people to answer?)



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: gdb + 68360 + bdm

[Kai Ruottu]

Stephane Dalton wrote:
> 
> Hi there,
> 
> I've succesfully compile gdb 4-18 with bdm patches and personal tweaks to
> work with ICD cable and have correct access to MBAR register. Now  I've a
> couple of questions:
> 
> - I'm not able to trace code which access the vbr, sfc and dfc register and
> trying to get the address of a variable allocated on the stack I get 0x0???

 This sounds familiar, gdb-4.18 has a known bug, which causes variables
to be shown as '0x0'. The patch follows :

------------------ clip ----------------------------------------
*** /home3/src/gdb-4.18.1/gdb/findvar.c	Fri Jan 29 11:46:03 1999
--- ./findvar.c	Sat Dec 18 04:13:50 1999
***************
*** 252,276 ****
       int len;
       LONGEST val;
  {
-   if( TARGET_BYTE_ORDER == BIG_ENDIAN
-       &&  len != sizeof( LONGEST )) {
-     /* On big-endian machines (e.g., HPPA 2.0, narrow mode)
-      * just letting this fall through to the call below will
-      * lead to the wrong bits being stored.
-      *
-      * Only the simplest case is fixed here, the others just
-      * get the old behavior.
-      */
-     if( (len == sizeof( CORE_ADDR ))
- 	&&  (sizeof( LONGEST ) == 2 * sizeof( CORE_ADDR ))) {
-       /* Watch out!  The high bits are garbage! */
-       CORE_ADDR coerce[2];
-       *(LONGEST*)&coerce = val;
- 
-       store_unsigned_integer (addr, len, coerce[1] ); /* BIG_ENDIAN code! */
-       return;
-     }
-   }
    store_unsigned_integer (addr, len, val);
  }
  

--- 252,257 ----
------------------ clip ----------------------------------------

> My target is 68360, am I the only one with this problem? (it seems that I'll
> have to write a howto on this one too... :)

 Yes, please include this too, all those 'm68k-palmos-coff', 'PublicDomain-BDM'
etc. patches etc. are now for gdb-4.18, so it can be the 'expected' GDB for the
m68k users....

 BTW, I have totally forgotten to review your HowTo, but don't let this disturb
you, just release it, it will surely be needed...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: kind of cross compiling howto

[Germain Ivanoff-Trinadtzaty]

My cygwin is 1.1.0 (with cygwin-20000301.tar.gz) under windows 2K. My mounts are :

bash-2.03$ mount
Device              Directory           Type         Flags
d:\cygwin\bin       /usr/bin            user         binmode
d:\cygwin\lib       /usr/lib            user         binmode
d:\cygwin           /                   user         textmode
bash-2.03$

I'm trying to build a crossgcc cygwin X m68k-coff for several weeks. I read read your <gccm68k.txt> with great interest, and tried to make it the way you explain. Helas ...

- I could build binutils 2.9.1 (and also binutils-19990818 from mirror/cygwin/latest/binutils/binutils-19990818-1-src.tar.gz)

- Then I provide THIS symlink :

bash-2.03$ cd /usr/local/m68k-coff

bash-2.03$ ln -s /usr/local/src/newlib-1.8.2/newlib/libc/include sys-include

                                                                 ^^^^^^^^^^^

because if I create a symlink called include, building gcc fails, saying : can't cd to m68k-coff/sys-include. Am I right ?

- BUT I STILL CANNOT build gcc 2.95.2 ; here is error messages :

bash-2.03$ make > mymake.log
../../gcc-2.95.2-1/libiberty/pexecute.c: In function `pexecute':
../../gcc-2.95.2-1/libiberty/pexecute.c:418: warning: assignment discards qualifiers from pointer target type
../../gcc-2.95.2-1/gcc/gcc.c: In function `process_command':
../../gcc-2.95.2-1/gcc/gcc.c:2897: warning: passing arg 3 of `make_relative_prefix' discards qualifiers from pointer target type
../../../gcc-2.95.2-1/gcc/fixinc/fixincl.c: In function `initialize':
../../../gcc-2.95.2-1/gcc/fixinc/fixincl.c:349: `SIGIOT' undeclared (first use in this function)
../../../gcc-2.95.2-1/gcc/fixinc/fixincl.c:349: (Each undeclared identifier is reported only once
../../../gcc-2.95.2-1/gcc/fixinc/fixincl.c:349: for each function it appears in.)
make[2]: *** [fixincl.o] Error 1
../../gcc-2.95.2-1/gcc/libgcc1-test.c:101: warning: conflicting types for built-in function `memcpy'
cxxmain.c: In function `main':
cxxmain.c:4527: warning: assignment discards qualifiers from pointer target type
cxxmain.c:4530: warning: assignment discards qualifiers from pointer target type
../../gcc-2.95.2-1/gcc/cpp.texi: error 0
make[1]: *** [cpp.info] Error 2
make: *** [all-gcc] Error 2
bash-2.03

=> make breaks before building m68k-coff-gcc

So could you please tell me :

- what is your version of cygwin ?

- what are your mounts ?

- what version of gcc do you use ? I meam : where did you get the archive ?

  There several versions whose name is prefixed by gcc-2.95.2, depending on the site from where you downloaded it.

  Is there any pathes to apply against gcc, to fix fixincl.c ?

- Am I doing right for the symlink ?

Thank you very much,

Germain Ivanoff-Trinadtzaty




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com