Proper Place for builtin_define(__ELF__)

Proper Place for builtin_define(__ELF__)

[Joel Sherrill]

Hi

We are in the process of porting RTEMS to the Microblaze and gcc does
not have __ELF__ as a predefine. In looking around at where to add it,
it looks like there are multiple ways to do it. We see variations on
the following patterns:

+ dbxelf.h
+ OS specific header in config/
+ Arch/OS specific header

Integrating dbxelf.h into the microblaze seems risky for one simple
builtin_define(). Adding it to config/microblaze/rtems.h won't address
the microblaze-elf target.

A suggestion on where to add the builtin_predefine is appreciated.

Thanks

--joel

Re: Proper Place for builtin_define(__ELF__)

[Michael Eager]

On 7/21/21 2:28 PM, Joel Sherrill wrote:
> Hi
> 
> We are in the process of porting RTEMS to the Microblaze and gcc does
> not have __ELF__ as a predefine. In looking around at where to add it,
> it looks like there are multiple ways to do it. We see variations on
> the following patterns:
> 
> + dbxelf.h
> + OS specific header in config/
> + Arch/OS specific header
> 
> Integrating dbxelf.h into the microblaze seems risky for one simple
> builtin_define(). Adding it to config/microblaze/rtems.h won't address
> the microblaze-elf target.
> 
> A suggestion on where to add the builtin_predefine is appreciated.

There are very few defines for __ELF__ in the GCC target files.

Why don't you put this in rtems.h?

Alternately, you might put it in microblaze-s.c, wrapped with
#ifdef OBJECT_FORMAT_ELF/#endif.

-- 
Michael Eager

Re: Proper Place for builtin_define(__ELF__)

[Joel Sherrill]

On Wed, Jul 21, 2021, 7:12 PM Michael Eager <eager@eagercon.com> wrote:

> On 7/21/21 2:28 PM, Joel Sherrill wrote:
> > Hi
> >
> > We are in the process of porting RTEMS to the Microblaze and gcc does
> > not have __ELF__ as a predefine. In looking around at where to add it,
> > it looks like there are multiple ways to do it. We see variations on
> > the following patterns:
> >
> > + dbxelf.h
> > + OS specific header in config/
> > + Arch/OS specific header
> >
> > Integrating dbxelf.h into the microblaze seems risky for one simple
> > builtin_define(). Adding it to config/microblaze/rtems.h won't address
> > the microblaze-elf target.
> >
> > A suggestion on where to add the builtin_predefine is appreciated.
>
> There are very few defines for __ELF__ in the GCC target files.
>

Many  targets include dbxelf.h from the config.gcc script. There are 130
references to that file there. That seems to be where most architectures
get it.



> Why don't you put this in rtems.h?
>

That's ok for a hack but we haven't had to do that on the other ports so it
seems wrong.

I didn't mention but without this defined the cdefs.h file in newlib
produces incorrect macro definitions for at the weak_reference macro.


> Alternately, you might put it in microblaze-s.c, wrapped with
> #ifdef OBJECT_FORMAT_ELF/#endif.
>

Ok. This should fix it for microblaze-elf also.

Thanks.

--joel

>
> --
> Michael Eager
>

Re: Proper Place for builtin_define(__ELF__)

[Michael Eager]

On 7/21/21 5:22 PM, Joel Sherrill wrote:
> 
> 
> On Wed, Jul 21, 2021, 7:12 PM Michael Eager <eager@eagercon.com 
> <mailto:eager@eagercon.com>> wrote:
> 
>     On 7/21/21 2:28 PM, Joel Sherrill wrote:
>      > Hi
>      >
>      > We are in the process of porting RTEMS to the Microblaze and gcc does
>      > not have __ELF__ as a predefine. In looking around at where to
>     add it,
>      > it looks like there are multiple ways to do it. We see variations on
>      > the following patterns:
>      >
>      > + dbxelf.h
>      > + OS specific header in config/
>      > + Arch/OS specific header
>      >
>      > Integrating dbxelf.h into the microblaze seems risky for one simple
>      > builtin_define(). Adding it to config/microblaze/rtems.h won't
>     address
>      > the microblaze-elf target.
>      >
>      > A suggestion on where to add the builtin_predefine is appreciated.
> 
>     There are very few defines for __ELF__ in the GCC target files.
> 
> 
> Many  targets include dbxelf.h from the config.gcc script. There are 130 
> references to that file there. That seems to be where most architectures 
> get it.

AFAIK, no one has ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would.  Including dbxelf.h
seems wrong.  I don't have an answer why other arch's do that.

> 
> 
> 
>     Why don't you put this in rtems.h?
> 
> 
> That's ok for a hack but we haven't had to do that on the other ports so 
> it seems wrong.

Yep.

> 
> I didn't mention but without this defined the cdefs.h file in newlib 
> produces incorrect macro definitions for at the weak_reference macro.
> 
> 
>     Alternately, you might put it in microblaze-s.c, wrapped with
>     #ifdef OBJECT_FORMAT_ELF/#endif.
> 
> 
> Ok. This should fix it for microblaze-elf also.

ARM does something which looks screwy to me.  Instead of defining
__ELF__, they pass -D__ELF__ on the CPP command line.

> 
> Thanks.
> 
> --joel
> 
> 
>     -- 
>     Michael Eager
> 

-- 
Michael Eager

Re: Proper Place for builtin_define(__ELF__)

[Jeff Law]

On 7/21/2021 6:31 PM, Michael Eager wrote:
>
>
> On 7/21/21 5:22 PM, Joel Sherrill wrote:
>>
>>
>> On Wed, Jul 21, 2021, 7:12 PM Michael Eager <eager@eagercon.com 
>> <mailto:eager@eagercon.com>> wrote:
>>
>>     On 7/21/21 2:28 PM, Joel Sherrill wrote:
>>      > Hi
>>      >
>>      > We are in the process of porting RTEMS to the Microblaze and 
>> gcc does
>>      > not have __ELF__ as a predefine. In looking around at where to
>>     add it,
>>      > it looks like there are multiple ways to do it. We see 
>> variations on
>>      > the following patterns:
>>      >
>>      > + dbxelf.h
>>      > + OS specific header in config/
>>      > + Arch/OS specific header
>>      >
>>      > Integrating dbxelf.h into the microblaze seems risky for one 
>> simple
>>      > builtin_define(). Adding it to config/microblaze/rtems.h won't
>>     address
>>      > the microblaze-elf target.
>>      >
>>      > A suggestion on where to add the builtin_predefine is 
>> appreciated.
>>
>>     There are very few defines for __ELF__ in the GCC target files.
>>
>>
>> Many  targets include dbxelf.h from the config.gcc script. There are 
>> 130 references to that file there. That seems to be where most 
>> architectures get it.
>
> AFAIK, no one has ever tried to build microblaze to generate stabs,
> and I can't see a good reason why anyone would.  Including dbxelf.h
> seems wrong.  I don't have an answer why other arch's do that.
Avoiding dbxelf would be advisable.  We're really only supporting stabs 
for for aix anymore.  We need to start excising dbxelf from all the 
places it's being used.

jeff

Re: Proper Place for builtin_define(__ELF__)

[Joel Sherrill]

On Wed, Jul 21, 2021 at 10:08 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 7/21/2021 6:31 PM, Michael Eager wrote:
> >
> >
> > On 7/21/21 5:22 PM, Joel Sherrill wrote:
> >>
> >>
> >> On Wed, Jul 21, 2021, 7:12 PM Michael Eager <eager@eagercon.com
> >> <mailto:eager@eagercon.com>> wrote:
> >>
> >>     On 7/21/21 2:28 PM, Joel Sherrill wrote:
> >>      > Hi
> >>      >
> >>      > We are in the process of porting RTEMS to the Microblaze and
> >> gcc does
> >>      > not have __ELF__ as a predefine. In looking around at where to
> >>     add it,
> >>      > it looks like there are multiple ways to do it. We see
> >> variations on
> >>      > the following patterns:
> >>      >
> >>      > + dbxelf.h
> >>      > + OS specific header in config/
> >>      > + Arch/OS specific header
> >>      >
> >>      > Integrating dbxelf.h into the microblaze seems risky for one
> >> simple
> >>      > builtin_define(). Adding it to config/microblaze/rtems.h won't
> >>     address
> >>      > the microblaze-elf target.
> >>      >
> >>      > A suggestion on where to add the builtin_predefine is
> >> appreciated.
> >>
> >>     There are very few defines for __ELF__ in the GCC target files.
> >>
> >>
> >> Many  targets include dbxelf.h from the config.gcc script. There are
> >> 130 references to that file there. That seems to be where most
> >> architectures get it.
> >
> > AFAIK, no one has ever tried to build microblaze to generate stabs,
> > and I can't see a good reason why anyone would.  Including dbxelf.h
> > seems wrong.  I don't have an answer why other arch's do that.
> Avoiding dbxelf would be advisable.  We're really only supporting stabs
> for for aix anymore.  We need to start excising dbxelf from all the
> places it's being used.

That will take some work.

What about elfos.h which is referenced 168 times in config.gcc?

Unfortunately, dbxelf.h and elfos.h appear to be used together a lot.
Grep'ing for "dbxelf.h elfos.h" in config.gcc resulted in 128 hits.

--joel

>
> jeff
>

Re: Proper Place for builtin_define(__ELF__)

[David Edelsohn]

On Wed, Jul 21, 2021 at 11:09 PM Jeff Law via Gcc <gcc@gcc.gnu.org> wrote:
>
>
>
> On 7/21/2021 6:31 PM, Michael Eager wrote:
> >
> >
> > On 7/21/21 5:22 PM, Joel Sherrill wrote:
> >>
> >>
> >> On Wed, Jul 21, 2021, 7:12 PM Michael Eager <eager@eagercon.com
> >> <mailto:eager@eagercon.com>> wrote:
> >>
> >>     On 7/21/21 2:28 PM, Joel Sherrill wrote:
> >>      > Hi
> >>      >
> >>      > We are in the process of porting RTEMS to the Microblaze and
> >> gcc does
> >>      > not have __ELF__ as a predefine. In looking around at where to
> >>     add it,
> >>      > it looks like there are multiple ways to do it. We see
> >> variations on
> >>      > the following patterns:
> >>      >
> >>      > + dbxelf.h
> >>      > + OS specific header in config/
> >>      > + Arch/OS specific header
> >>      >
> >>      > Integrating dbxelf.h into the microblaze seems risky for one
> >> simple
> >>      > builtin_define(). Adding it to config/microblaze/rtems.h won't
> >>     address
> >>      > the microblaze-elf target.
> >>      >
> >>      > A suggestion on where to add the builtin_predefine is
> >> appreciated.
> >>
> >>     There are very few defines for __ELF__ in the GCC target files.
> >>
> >>
> >> Many  targets include dbxelf.h from the config.gcc script. There are
> >> 130 references to that file there. That seems to be where most
> >> architectures get it.
> >
> > AFAIK, no one has ever tried to build microblaze to generate stabs,
> > and I can't see a good reason why anyone would.  Including dbxelf.h
> > seems wrong.  I don't have an answer why other arch's do that.
> Avoiding dbxelf would be advisable.  We're really only supporting stabs
> for for aix anymore.  We need to start excising dbxelf from all the
> places it's being used.

As requested by Richi, the GCC configuration for AIX on trunk no
longer enables stabs.  There still are some variables defined in
xcoffout.c that would need to move to rs6000.c.  GCC should be ready
for stabs support to be removed.

Thanks, David

Re: Proper Place for builtin_define(__ELF__)

[Jeff Law]

On 7/22/2021 8:12 AM, Joel Sherrill wrote:
> On Wed, Jul 21, 2021 at 10:08 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>>
>>
>> On 7/21/2021 6:31 PM, Michael Eager wrote:
>>>
>>> On 7/21/21 5:22 PM, Joel Sherrill wrote:
>>>>
>>>> On Wed, Jul 21, 2021, 7:12 PM Michael Eager <eager@eagercon.com
>>>> <mailto:eager@eagercon.com>> wrote:
>>>>
>>>>      On 7/21/21 2:28 PM, Joel Sherrill wrote:
>>>>       > Hi
>>>>       >
>>>>       > We are in the process of porting RTEMS to the Microblaze and
>>>> gcc does
>>>>       > not have __ELF__ as a predefine. In looking around at where to
>>>>      add it,
>>>>       > it looks like there are multiple ways to do it. We see
>>>> variations on
>>>>       > the following patterns:
>>>>       >
>>>>       > + dbxelf.h
>>>>       > + OS specific header in config/
>>>>       > + Arch/OS specific header
>>>>       >
>>>>       > Integrating dbxelf.h into the microblaze seems risky for one
>>>> simple
>>>>       > builtin_define(). Adding it to config/microblaze/rtems.h won't
>>>>      address
>>>>       > the microblaze-elf target.
>>>>       >
>>>>       > A suggestion on where to add the builtin_predefine is
>>>> appreciated.
>>>>
>>>>      There are very few defines for __ELF__ in the GCC target files.
>>>>
>>>>
>>>> Many  targets include dbxelf.h from the config.gcc script. There are
>>>> 130 references to that file there. That seems to be where most
>>>> architectures get it.
>>> AFAIK, no one has ever tried to build microblaze to generate stabs,
>>> and I can't see a good reason why anyone would.  Including dbxelf.h
>>> seems wrong.  I don't have an answer why other arch's do that.
>> Avoiding dbxelf would be advisable.  We're really only supporting stabs
>> for for aix anymore.  We need to start excising dbxelf from all the
>> places it's being used.
> That will take some work.
Yup.  But it's clearly the right thing to do.

>
> What about elfos.h which is referenced 168 times in config.gcc?
>
> Unfortunately, dbxelf.h and elfos.h appear to be used together a lot.
> Grep'ing for "dbxelf.h elfos.h" in config.gcc resulted in 128 hits.
I think most of elfos.h is OK, we just need to rip out the bits for 
embedded stabs contained therein.


jeff