Whereas making dwarf addresses always 32 bits only affects debugging
info size (not rom image size) on the oldest and smallest H8/300
variant, where real-world code would have a limited amount of debug
information anyway.
On 05/10/2012 09:55 PM, DJ Delorie wrote:
That's the default. It doesn't work because pointers are still 16 bits.
Something's still not right then. The H8/300 has 16 bit pointers and a
64k address space and all the processors in the family still support
that mode.
The problem is when a sing
> > That's the default. It doesn't work because pointers are still 16 bits.
>
> Something's still not right then. The H8/300 has 16 bit pointers and a
> 64k address space and all the processors in the family still support
> that mode.
The problem is when a single object is more than 64k for t
On 05/10/2012 11:21 AM, DJ Delorie wrote:
Regardless, shouldn't DWARF2_ADDR_SIZE be POINTER_SIZE / BITS_PER_UNIT?
That's the default. It doesn't work because pointers are still 16 bits.
Something's still not right then. The H8/300 has 16 bit pointers and a
64k address space and all the proce
> Regardless, shouldn't DWARF2_ADDR_SIZE be POINTER_SIZE / BITS_PER_UNIT?
That's the default. It doesn't work because pointers are still 16 bits.
On 05/09/2012 06:27 PM, DJ Delorie wrote:
H8/300 cpus have a larger-than-64k address space, despite 16-bit
pointers. OK to apply? Ok for 4.7 branch?
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
* config/h8300/h8300.h (DWARF2_ADDR_SIZE): Define as 4 bytes.
My recollection
H8/300 cpus have a larger-than-64k address space, despite 16-bit
pointers. OK to apply? Ok for 4.7 branch?
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
* config/h8300/h8300.h (DWARF2_ADDR_SIZE): Define as 4 bytes.
Index: h8300.h
==
