This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/2406: avr gdb accessing ram instead of eeprom


>Number:         2406
>Category:       gdb
>Synopsis:       avr gdb accessing ram instead of eeprom
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          patch
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 17 09:58:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     tomas.vanek@fbl.cz
>Release:        from at least gdb 6.6 up to 6.7.50.20080117-cvs
>Organization:
>Environment:
not dependent on host system
from at least gdb 6.6 up to current cvs
GDB was configured as "--host=i686-pc-linux-gnu --target=avr"
>Description:
AVR uses concept of different gdbarch_ptr_bit and gdbarch_addr_bit.
gdbarch_ptr_bit is set to 16 and represents the size of a pointer on the target.
gdbarch_addr_bit is set to 32 and as the size of a target address as represented in gdb.

If gdb is accessing a pointer on the target the avr_address_to_pointer() or avr_pointer_to_address() conversion is the only way. The problem is that gdb cuts the address to pointer size even for internal purposes, in expression evaluator. Evaluating a reference operator (&) should store full target address, however it builds internal struct value typed as pointer filled by only 16 bit of address.

EEPROM segment is on AVR normally at 0x810000, RAM is from 0x800000.
>How-To-Repeat:
Lets have the code:

int eeVar __attribute__((section(".eeprom"))) = 123;
int eeArray[2] __attribute__((section(".eeprom"))) = { 34, 56 };
int main() {}


avr-nm shows the addresses:
00810002 D eeArray
00810000 D eeVar

Now inspect variables in gdb:

(gdb) p eeVar
$1 = 123

Good.


(gdb) p &eeVar
$2 = (int *) 0x800000

Wrong. It's a RAM address. 0x800000 prefix is added in avr_pointer_to_address()


(gdb) p *&eeVar
$3 = 0

Wrong. Value is read from RAM instead form EEPROM.

Of course there is no point in using *& construction. But wait. gdb uses similar technique to access array elements:

(gdb) p eeArray
$4 = {34, 56}

Good.


(gdb) p eeArray [1]
$5= 0

Wrong. Value goes from RAM again.

Same problem is for writing values, they go to RAM, not to EEPROM.
>Fix:
Store gdbarch_addr_bit() bits of address instead gdbarch_ptr_bit() to any struct value representing a pointer. The size of the pointer type in type info have to stay unchanged! We should just treat internal data value.aliner.contents as gdbarch_addr_bit() long, instead of gdbarch_ptr_bit() long. It looks weird but it is exactly what we need:

p sizeof(&eeVar) returns 2, as appropriate on the target.
p &eeVar returns 0x810000, right address in EEPROM.

The attached patch should not have any influence on targets with gdbarch_addr_bit() equal to gdbarch_ptr_bit().
There are more architectures using different gdbarch_ptr_bit() and gdbarch_addr_bit():
Reneas H8/300, M32C
Motorola 68hc11
Sanyo Xstormy16a
The patch should be verified against them.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-patch; name="avr-gdb-eeprom.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="avr-gdb-eeprom.patch"

SW5kZXg6IGF2ci10ZGVwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9zcmMvc3JjL2dkYi9h
dnItdGRlcC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEwNgpkaWZmIC11IC1wIC1yMS4xMDYg
YXZyLXRkZXAuYwotLS0gYXZyLXRkZXAuYwkxMSBKYW4gMjAwOCAxMzoxOTo1OSAtMDAwMAkxLjEw
NgorKysgYXZyLXRkZXAuYwkxNyBKYW4gMjAwOCAwOTozMjoxNSAtMDAwMApAQCAtMjgwLDE3ICsy
ODAsMTggQEAgYXZyX2NvbnZlcnRfc2FkZHJfdG9fcmF3IChDT1JFX0FERFIgeCkKIHN0YXRpYyB2
b2lkCiBhdnJfYWRkcmVzc190b19wb2ludGVyIChzdHJ1Y3QgdHlwZSAqdHlwZSwgZ2RiX2J5dGUg
KmJ1ZiwgQ09SRV9BRERSIGFkZHIpCiB7CisgIC8qIFN0b3JlIHBvaW50ZXJzIGludGVybmFsbHkg
Z2RiYXJjaF9hZGRyX2JpdCBsb25nIGluc3RlYWQgb2YgVFlQRV9MRU5HVEggKHR5cGUpIGJ5dGUg
bG9uZyAqLwogICAvKiBJcyBpdCBhIGNvZGUgYWRkcmVzcz8gICovCiAgIGlmIChUWVBFX0NPREUg
KFRZUEVfVEFSR0VUX1RZUEUgKHR5cGUpKSA9PSBUWVBFX0NPREVfRlVOQwogICAgICAgfHwgVFlQ
RV9DT0RFIChUWVBFX1RBUkdFVF9UWVBFICh0eXBlKSkgPT0gVFlQRV9DT0RFX01FVEhPRCkKICAg
ICB7Ci0gICAgICBzdG9yZV91bnNpZ25lZF9pbnRlZ2VyIChidWYsIFRZUEVfTEVOR1RIICh0eXBl
KSwKKyAgICAgIHN0b3JlX3Vuc2lnbmVkX2ludGVnZXIgKGJ1ZiwgZ2RiYXJjaF9hZGRyX2JpdCAo
Y3VycmVudF9nZGJhcmNoKSAvIFRBUkdFVF9DSEFSX0JJVCwKIAkJCSAgICAgIGF2cl9jb252ZXJ0
X2lhZGRyX3RvX3JhdyAoYWRkciA+PiAxKSk7CiAgICAgfQogICBlbHNlCiAgICAgewogICAgICAg
LyogU3RyaXAgb2ZmIGFueSB1cHBlciBzZWdtZW50IGJpdHMuICAqLwotICAgICAgc3RvcmVfdW5z
aWduZWRfaW50ZWdlciAoYnVmLCBUWVBFX0xFTkdUSCAodHlwZSksCisgICAgICBzdG9yZV91bnNp
Z25lZF9pbnRlZ2VyIChidWYsIGdkYmFyY2hfYWRkcl9iaXQgKGN1cnJlbnRfZ2RiYXJjaCkgLyBU
QVJHRVRfQ0hBUl9CSVQsCiAJCQkgICAgICBhdnJfY29udmVydF9zYWRkcl90b19yYXcgKGFkZHIp
KTsKICAgICB9CiB9CkluZGV4OiB2YWx1ZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvc3Jj
L3NyYy9nZGIvdmFsdWUuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS41NgpkaWZmIC11IC1wIC1y
MS41NiB2YWx1ZS5jCi0tLSB2YWx1ZS5jCTE2IEphbiAyMDA4IDE2OjE2OjQ0IC0wMDAwCTEuNTYK
KysrIHZhbHVlLmMJMTcgSmFuIDIwMDggMDk6MzI6MTcgLTAwMDAKQEAgLTU2Niw5ICs1NjYsMTIg
QEAgdmFsdWVfY29weSAoc3RydWN0IHZhbHVlICphcmcpCiAgIHZhbC0+bW9kaWZpYWJsZSA9IGFy
Zy0+bW9kaWZpYWJsZTsKICAgaWYgKCF2YWx1ZV9sYXp5ICh2YWwpKQogICAgIHsKKyAgICAgIC8q
IGlmIHZhbHVlIGlzIGEgcG9pbnRlciBjb3B5IHJhdGhlciBnZGJhcmNoX2FkZHJfYml0KCkgYml0
cworCSBpbnN0ZWFkIG9mIFRZUEVfTEVOR1RIKCkgYnl0ZXMgdG8gcmV0YWluIGZ1bGwgaW50ZXJu
YWwgYWRkcmVzcyAqLwogICAgICAgbWVtY3B5ICh2YWx1ZV9jb250ZW50c19hbGxfcmF3ICh2YWwp
LCB2YWx1ZV9jb250ZW50c19hbGxfcmF3IChhcmcpLAotCSAgICAgIFRZUEVfTEVOR1RIICh2YWx1
ZV9lbmNsb3NpbmdfdHlwZSAoYXJnKSkpOwotCisJICAgICAgKFRZUEVfQ09ERSAoZW5jbF90eXBl
KSA9PSBUWVBFX0NPREVfUFRSKQorCQk/IGdkYmFyY2hfYWRkcl9iaXQgKGN1cnJlbnRfZ2RiYXJj
aCkgLyBUQVJHRVRfQ0hBUl9CSVQKKwkJOiBUWVBFX0xFTkdUSCAodmFsdWVfZW5jbG9zaW5nX3R5
cGUgKGFyZykpKTsKICAgICB9CiAgIHJldHVybiB2YWw7CiB9CkBAIC0xMDg0LDYgKzEwODcsMTQg
QEAgdmFsdWVfYXNfYWRkcmVzcyAoc3RydWN0IHZhbHVlICp2YWwpCiAgICAgcmV0dXJuIGdkYmFy
Y2hfaW50ZWdlcl90b19hZGRyZXNzIChjdXJyZW50X2dkYmFyY2gsIHZhbHVlX3R5cGUgKHZhbCks
CiAJCQkJICAgICAgIHZhbHVlX2NvbnRlbnRzICh2YWwpKTsKIAorICAvKiBpZiB2YWx1ZSBpcyBh
IHBvaW50ZXIgZXh0cmFjdCByYXRoZXIgZ2RiYXJjaF9hZGRyX2JpdCgpIGJpdHMKKyAgICAgaW5z
dGVhZCBvZiBUWVBFX0xFTkdUSCgpIGJ5dGVzIHRvIHJldGFpbiBmdWxsIGludGVybmFsIGFkZHJl
c3MgKi8KKworICBpZiAoVFlQRV9DT0RFICh2YWx1ZV90eXBlICh2YWwpKSA9PSBUWVBFX0NPREVf
UFRSKSB7CisgICAgcmV0dXJuIGV4dHJhY3RfdW5zaWduZWRfaW50ZWdlciAodmFsdWVfY29udGVu
dHMgKHZhbCksCisJCWdkYmFyY2hfYWRkcl9iaXQgKGN1cnJlbnRfZ2RiYXJjaCkgLyBUQVJHRVRf
Q0hBUl9CSVQpOworICB9CisKICAgcmV0dXJuIHVucGFja19sb25nICh2YWx1ZV90eXBlICh2YWwp
LCB2YWx1ZV9jb250ZW50cyAodmFsKSk7CiAjZW5kaWYKIH0K


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]