This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/19087] Overflowed address in dwarf debug line information
- From: "dwatkins at tascsystems dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Mar 2005 16:31:27 -0000
- Subject: [Bug target/19087] Overflowed address in dwarf debug line information
- References: <20041220095410.19087.tsandnes@atmel.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From dwatkins at tascsystems dot com 2005-03-07 16:31 -------
Hello,
I have an update. Torlief sent me a beta set of AS4 parser DLLs built to work
ONLY with 32 bit address sizes in dwarf information. I tried it out and
noticed the following differences.
1. Single stepping through my program now appears to work much better. I no
longer observe jumping back and forth between two source files as before.
2. Disassembler view shows the source for the code above 0x00008000 (word
address) in the proper locations with code above 0x00008000.
I also noticed the following side effects which don't directly bear on the
subject of this bug, but may be related to the same root causes.
1. On my development PC using latest WinAVR distribution and AS4.11 with the
distribution parser DLLs, in one source module, I can hover over a global
variable and see the address and value. On my quarantined environment I use to
experiment / debug the tool suite, I observe "invalid location" when I hover
over the same variables.
2. On my development PC, in the same source module, when I hover over a local
(automatic) variable, no "hover-over" popup information is displayed. On my
quarantined environment, when I hover over the same variables, I see data
values.
I must mention something about my quarantined environment. I built it just
before the latest WinAVR release so I think I want to make sure that it is in
sync with all the same patches used for the latest WinAVR before concluding my
test here, ... but so far the results appear very promising.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087