| Message ID | 201205100027.q4A0RELM022946@greed.delorie.com |
|---|---|
| State | New |
| Headers | show |
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 was that the H8/300 only had a 64k address space and that the larger address spaces showed up in later processors (H8/300H). Regardless, shouldn't DWARF2_ADDR_SIZE be POINTER_SIZE / BITS_PER_UNIT? That'll give the larger DWARF2_ADDR_SIZE on the modern widgets, but still do the right thing for the ancient H8/300. My other relevant recollection was that we don't support C++ on the H8/300 series. jeff
> 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/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 processors in the family still support that mode. Jeff
> > 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 the models that have 16 bit pointers. No, they won't work on hardware, but we can't even *compile* them because of the dwarf limitation, which means all the other models can't support such large objects. I.e. the 2-byte dwarf addresses for H8/300 prevent us from supporting C++ on the larger H8/300SX processors.
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 single object is more than 64k for the models > that have 16 bit pointers. No, they won't work on hardware, but we > can't even *compile* them because of the dwarf limitation, which means > all the other models can't support such large objects. > > I.e. the 2-byte dwarf addresses for H8/300 prevent us from supporting > C++ on the larger H8/300SX processors. Right, so ISTM the way to fix this is to not build the C++ runtime for "normal" mode, rather than hack up the dwarf address size. Now I know there's currently no way to do that, but that seems to me to be the correct fix. Unfortunately it's going to probably look a whole lot like multilib exceptions... Ewwww. Jeff
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.
Index: h8300.h =================================================================== --- h8300.h (revision 187362) +++ h8300.h (working copy) @@ -126,12 +126,13 @@ extern const char * const *h8_reg_names; /* The return address is pushed on the stack. */ #define INCOMING_RETURN_ADDR_RTX gen_rtx_MEM (Pmode, gen_rtx_REG (Pmode, STACK_POINTER_REGNUM)) #define INCOMING_FRAME_SP_OFFSET (POINTER_SIZE / 8) #define DWARF_CIE_DATA_ALIGNMENT 2 +#define DWARF2_ADDR_SIZE 4 /* Define this if addresses of constant functions shouldn't be put through pseudo regs where they can be cse'd. Desirable on machines where ordinary constants are expensive but a CALL with constant address is cheap.