Re: gdb-4.18 for H8/300H

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Hansjuergen Dreuth wrote:
> 
> I tried removing the questionable lines of code in gdb/findvar.c:250
> as mentioned in the bug report (without really knowing what I do).
> This works for me and symbols are now recognized.

 Later I saw that it wasn't very clearly said what to do (in the attached
bug report). When I installed it, I just compared the code with 4.17.x and
gdb-snapshots equivalents and then it was clear... A pure diff or the code
after the fix would have been better... Nice you managed to install it...
 
> I also tried to download several current snapshots of gdb from
> ftp://sourceware.cygnus.com/pub/gdb
> 
> For reasons I do not understand I was not able to unpack these
> *.bz2 files although appearently the bzip2 version of my SuSe Linux
> Distribution 6.3 is up to date (version 0.9.5). I tried several
> downloads but bzip2 always complained the file was corrupt.

 I have bzip-0.9.0c and haven't had problems with it. Has somebody
managed to 'bunzip2' with 0.9.5 ?

 Perhaps the reason is in the downloads, or the bzip2 is broken. But
rebuilding it or the 0.9.0c, or downloading another prebuilt one would
help.

Cheers, Kai

PS. If someone else wants to patch gdb-4.18, here is the problem and the
fix to it :

---------------------------- clip --------------------------------------
Newsgroups: gnu.gdb.bug
Subject: m68k: dereferencing arrays and function evaluation did not work
From: Bart.Durinck@icos.be
Date: Fri, 17 Dec 1999 11:31:27 +0100

 I found two problems in gdb 4.18. We are working in a x86-Linux host -
embedded m68k target environment, with a stub derived from gdb/m68k-stub.c.

1. The address calculation of symbols is wrong. The most annoying
consequence is that dereferencing array expression does not work.

code:
int a[2] = {123, 456);

(gdb) print a[0]
$1 = 578934

(gdb) print &a
$2 = 0x0

This is clearly wrong.

I found out that a strange piece of code in gdb/findvar.c:250 is
responsible for problem 1; the address of every symbol evaluates to be
0x0.

void
store_address (addr, len, val)
     PTR addr;
     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);
}

I threw the whole if-construct out and it works now!
---------------------------- clip --------------------------------------

 What Bart meaned was that the function should simply be :

void
store_address (addr, len, val)
     PTR addr;
     int len;
     LONGEST val;
{
  store_unsigned_integer (addr, len, val);
}

 The 'if {....}' code was not present in gdb 4.17 and it disappeared in
the gdb snapshots. So this really was an 'added' bug...

 The second problem with the 'm68k-stub' can be found via the 'gnu.gdb.bug'
newsgroup...


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