Patchwork [h8300] increase dwarf address size

login
register
mail settings
Submitter DJ Delorie
Date May 10, 2012, 12:27 a.m.
Message ID <201205100027.q4A0RELM022946@greed.delorie.com>
Download mbox | patch
Permalink /patch/158085/
State New
Headers show

Comments

DJ Delorie - May 10, 2012, 12:27 a.m.
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.
Jeff Law - May 10, 2012, 3:11 p.m.
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
DJ Delorie - May 10, 2012, 5:21 p.m.
> 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.
Jeff Law - May 11, 2012, 3:35 a.m.
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
DJ Delorie - May 11, 2012, 3:55 a.m.
> > 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.
Jeff Law - May 11, 2012, 3:58 a.m.
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
DJ Delorie - May 11, 2012, 4:03 a.m.
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.

Patch

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.