This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: ppc-eabi: interaction betwen section name attributes and -msdata



jtc@redback.com (J.T. Conklin) writes:

> >>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:
> >> Would it be reasonable for gcc to pay attention to section attributes
> >> to solve these problems?  I'm thinking along the lines of the small
> >> data relocs being used used if:
> >> 
> >> * the size size of the data object is below the threshold and no
> >> section attribute was specified.
> >> or:
> >> 
> >> * the section attribute was one of the small data sections.
> 
> Geoff> I'd rather have an explicit __attribute__((sdata)) and
> Geoff> __attribute__((nosdata)), or something.
> 
> If I understand correctly, there isn't support for a "no" prefix for
> attributes.  Thus "sdata" and "nosdata" would be separate attributes,
> allowing the ambiguity of __attribute__((sdata, nosdata)).  Nothing a
> little documentation couldn't solve, but I'm a bit uncomfortable with
> it.

Perhaps

__attribute__((sdata(0)))
__attribute__((sdata(1)))

?

I'm not sure what happens in similar situations.  I wonder if

__attribute__((packed, align))

really works?

> Geoff> That way you don't have to parse section names in GCC.
> 
> It appears that rs6000_encode_section_info() does exactly that.  I'm
> not sure how much good it does only there.  I was thinking of moving
> that bit of code into it's own function, and re-using in the other
> functions/macros that compare size against g_switch_value.

Yes.  When I said it wasn't a good idea, I was speaking from painful
experience :-).

I guess if you don't want to implement the new feature, splitting out
the existing code would be OK.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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