Hi!
I believe this is a known problem. A search via
http://sourceware.cygnus.com/ml/bug-gdb in the messages of the bug-gdb
mailing list for "store_address" gives two hits describing a similar
problem (and fix).
The first describes this problem with the same config (Linux-x86 host,
PowerPc target). The second is about the similar problem with a Linux-x86
host and a m68k target (This messages was sent by me ;-) They share the
property that they have different endianess on host and debugger.
We are now using GDB 4.18 with a patch similar to yours and it works great.
After I reported the bug last December, I also checked the latest CVS
version of GDB. The code for store_address was different and fixed the
problem AFAIK.
So the problem will also most likely be solved in GDB 5.0 (due soon ?!)...
Bart
"Philip O'Carroll" <[EMAIL PROTECTED]> on 03/28/2000 04:07:46 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Bart Durinck/ICOS)
Subject: Endian problem on linux-power
Hello,
I have built GDB 4.18 as a Linux based PowerPC cross debugger using the
config
line
--host=i686-pc-linux-gnu --target=powerpc-eabi
Here is the output of gdb -v
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=powerpc-eabi".
I am very pleased and grateful to have this tool. However I am haing
trouble
getting the address of variables in ELF executables. My executables are
built
with GCC 2.95.2 built as a cross compiler with the same config line as GDB.
When I try to get the address of a global variable I get zero e.g.:
(gdb) p &G_time
$1 = (uint32*) 0x0
(uint32 is a typedef to unsigned long, the real address is 0x77580)
Now stepping through cross-gdb I found the address value got lost
in function store_address in find_var.c and I was able to hack this
function to give the right value
(gdb) p &G_time
$1 = (uint32*) 0x77580
In store_address there is code which seems to be intended truncate a 64 bit
address to fit into a 32 bit value which is then stored. I changed the call
to
store_unsigned_integer to use coerce[0] instead of one and all worked fine.
I
can't tell from the code whether the problem is in the config if the code
is
mixing up target and host byte order.
I have attached store_address function with MY_HACK to show what I mean
/* Store the literal address "val" into
gdb-local memory pointed to by "addr"
for "len" bytes. */
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;
#ifdef MY_HACK
store_unsigned_integer (addr, len, coerce[0] ); /* BIG_ENDIAN code!
*/
#else /* orignal code */
store_unsigned_integer (addr, len, coerce[1] ); /* BIG_ENDIAN code!
*/
#endif
return;
}
}
store_unsigned_integer (addr, len, val);
}
Many thanks for a great debugging tool!
Philip O'Carroll
Raidtec Corporation
Little Island,
Cork,
Ireland
--
