gcc_assert() and inhibit_libc

gcc_assert() and inhibit_libc

[Sebastian Huber]

Hello,

while testing this patch

https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking

I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from 
tsystem.h):

#ifdef ENABLE_RUNTIME_CHECKING
#define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
#else
/* Include EXPR, so that unused variable warnings do not occur.  */
#define gcc_assert(EXPR) ((void)(0 && (EXPR)))
#endif

In tsystem.h there is this if inhibit_libc is defined:

#ifndef abort
extern void abort (void) __attribute__ ((__noreturn__));
#endif

Who is supposed to define abort here optionally? Can this be defined for 
example by a target configuration header like gcc/config/rtems.h?

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gcc_assert() and inhibit_libc

[Richard Biener]

On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> Hello,
>
> while testing this patch
>
> https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking
>
> I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from
> tsystem.h):
>
> #ifdef ENABLE_RUNTIME_CHECKING
> #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
> #else
> /* Include EXPR, so that unused variable warnings do not occur.  */
> #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
> #endif
>
> In tsystem.h there is this if inhibit_libc is defined:
>
> #ifndef abort
> extern void abort (void) __attribute__ ((__noreturn__));
> #endif
>
> Who is supposed to define abort here optionally? Can this be defined for
> example by a target configuration header like gcc/config/rtems.h?

I suppose for inhibit_libc we could use __builtin_trap () (but that might
expand to abort() on some targets)

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

Re: gcc_assert() and inhibit_libc

[Sebastian Huber]

On 22/07/2021 14:15, Richard Biener wrote:
> On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber
> <sebastian.huber@embedded-brains.de>  wrote:
>> Hello,
>>
>> while testing this patch
>>
>> https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking
>>
>> I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from
>> tsystem.h):
>>
>> #ifdef ENABLE_RUNTIME_CHECKING
>> #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
>> #else
>> /* Include EXPR, so that unused variable warnings do not occur.  */
>> #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
>> #endif
>>
>> In tsystem.h there is this if inhibit_libc is defined:
>>
>> #ifndef abort
>> extern void abort (void) __attribute__ ((__noreturn__));
>> #endif
>>
>> Who is supposed to define abort here optionally? Can this be defined for
>> example by a target configuration header like gcc/config/rtems.h?
> I suppose for inhibit_libc we could use __builtin_trap () (but that might
> expand to abort() on some targets)

In case of RTEMS, the application and the operating system is statically 
linked into one executable. The more features an application uses the 
bigger will be the executable. The abort() function pulls in a lot of 
stuff since it uses signals and may attempt to close all open streams. 
It would be nice if the gcc_assert() could be customized by the target 
configuration. For RTEMS we could use the Newlib defined __assert_func() 
from <assert.h>:

# define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, \
						       __ASSERT_FUNC, #__e))


void __assert_func (const char *, int, const char *, const char *)
	    _ATTRIBUTE ((__noreturn__));


-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gcc_assert() and inhibit_libc

[Jason Merrill]

On Thu, Jul 22, 2021 at 8:18 AM Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber
> <sebastian.huber@embedded-brains.de> wrote:
> >
> > Hello,
> >
> > while testing this patch
> >
> > https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking
> >
> > I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from
> > tsystem.h):
> >
> > #ifdef ENABLE_RUNTIME_CHECKING
> > #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
> > #else
> > /* Include EXPR, so that unused variable warnings do not occur.  */
> > #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
> > #endif
> >
> > In tsystem.h there is this if inhibit_libc is defined:
> >
> > #ifndef abort
> > extern void abort (void) __attribute__ ((__noreturn__));
> > #endif
> >
> > Who is supposed to define abort here optionally? Can this be defined for
> > example by a target configuration header like gcc/config/rtems.h?
>
> I suppose for inhibit_libc we could use __builtin_trap () (but that might
> expand to abort() on some targets)

That seems straightforward.  Does it address the RTEMS concern?

Or, should we suppress ENABLE_RUNTIME_CHECKING when inhibit_libc?

Jason

Re: gcc_assert() and inhibit_libc

[Martin Liška]

On 7/21/21 2:44 PM, Sebastian Huber wrote:
> Hello,
> 
> while testing this patch
> 
> https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking
> 
> I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from tsystem.h):
> 
> #ifdef ENABLE_RUNTIME_CHECKING
> #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
> #else
> /* Include EXPR, so that unused variable warnings do not occur.  */
> #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
> #endif
> 
> In tsystem.h there is this if inhibit_libc is defined:
> 
> #ifndef abort
> extern void abort (void) __attribute__ ((__noreturn__));
> #endif
> 
> Who is supposed to define abort here optionally? Can this be defined for example by a target configuration header like gcc/config/rtems.h?
> 

Apparently, it's a hairy revision:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=7e7de68b8938

What happens now on RTERM where you have inhibit_libc set to true? Do you end up with an undefined symbol?

Cheers,
Martin

Re: gcc_assert() and inhibit_libc

[Sebastian Huber]

On 12/08/2021 16:08, Martin Liška wrote:
> On 7/21/21 2:44 PM, Sebastian Huber wrote:
>> Hello,
>>
>> while testing this patch
>>
>> https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking 
>>
>>
>> I noticed that __gcov_info_to_gcda() uses abort(). This is due to 
>> (from tsystem.h):
>>
>> #ifdef ENABLE_RUNTIME_CHECKING
>> #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
>> #else
>> /* Include EXPR, so that unused variable warnings do not occur.  */
>> #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
>> #endif
>>
>> In tsystem.h there is this if inhibit_libc is defined:
>>
>> #ifndef abort
>> extern void abort (void) __attribute__ ((__noreturn__));
>> #endif
>>
>> Who is supposed to define abort here optionally? Can this be defined 
>> for example by a target configuration header like gcc/config/rtems.h?
>>
> 
> Apparently, it's a hairy revision:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=7e7de68b8938
> 
> What happens now on RTERM where you have inhibit_libc set to true? Do 
> you end up with an undefined symbol?

No, we have abort() in RTEMS (from Newlib).  The problem is that abort() 
is a very heavy weight function which pulls in the signal and file 
streams support.

In case of RTEMS, the application and the operating system is statically 
linked into one executable. The more features an application uses the 
bigger will be the executable. The abort() function pulls in a lot of 
stuff since it uses signals and may attempt to close all open streams. 
It would be nice if the gcc_assert() could be customized by the target 
configuration. For RTEMS we could use the Newlib defined __assert_func() 
from <assert.h>:

# define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, \
                                __ASSERT_FUNC, #__e))


void __assert_func (const char *, int, const char *, const char *)
         _ATTRIBUTE ((__noreturn__));

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gcc_assert() and inhibit_libc

[Martin Liška]

On 8/12/21 4:12 PM, Sebastian Huber wrote:
> On 12/08/2021 16:08, Martin Liška wrote:
>> On 7/21/21 2:44 PM, Sebastian Huber wrote:
>>> Hello,
>>>
>>> while testing this patch
>>>
>>> https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking
>>>
>>> I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from tsystem.h):
>>>
>>> #ifdef ENABLE_RUNTIME_CHECKING
>>> #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
>>> #else
>>> /* Include EXPR, so that unused variable warnings do not occur.  */
>>> #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
>>> #endif
>>>
>>> In tsystem.h there is this if inhibit_libc is defined:
>>>
>>> #ifndef abort
>>> extern void abort (void) __attribute__ ((__noreturn__));
>>> #endif
>>>
>>> Who is supposed to define abort here optionally? Can this be defined for example by a target configuration header like gcc/config/rtems.h?
>>>
>>
>> Apparently, it's a hairy revision:
>> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=7e7de68b8938
>>
>> What happens now on RTERM where you have inhibit_libc set to true? Do you end up with an undefined symbol?
> 
> No, we have abort() in RTEMS (from Newlib).  The problem is that abort() is a very heavy weight function which pulls in the signal and file streams support.

Oh, I see.

> 
> In case of RTEMS, the application and the operating system is statically linked into one executable. The more features an application uses the bigger will be the executable. The abort() function pulls in a lot of stuff since it uses signals and may attempt to close all open streams. It would be nice if the gcc_assert() could be customized by the target configuration. For RTEMS we could use the Newlib defined __assert_func() from <assert.h>:
> 
> # define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, \
>                                 __ASSERT_FUNC, #__e))
> 
> 
> void __assert_func (const char *, int, const char *, const char *)
>          _ATTRIBUTE ((__noreturn__));
> 

Then what about adding a condition to gcc/tsystem.h where where you would define
a different gcc_assert based on rtems target?

Martin

Re: gcc_assert() and inhibit_libc

[Sebastian Huber]

On 12/08/2021 16:29, Martin Liška wrote:
> On 8/12/21 4:12 PM, Sebastian Huber wrote:
>> On 12/08/2021 16:08, Martin Liška wrote:
>>> On 7/21/21 2:44 PM, Sebastian Huber wrote:
>>>> Hello,
>>>>
>>>> while testing this patch
>>>>
>>>> https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking 
>>>>
>>>>
>>>> I noticed that __gcov_info_to_gcda() uses abort(). This is due to 
>>>> (from tsystem.h):
>>>>
>>>> #ifdef ENABLE_RUNTIME_CHECKING
>>>> #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
>>>> #else
>>>> /* Include EXPR, so that unused variable warnings do not occur.  */
>>>> #define gcc_assert(EXPR) ((void)(0 && (EXPR)))
>>>> #endif
>>>>
>>>> In tsystem.h there is this if inhibit_libc is defined:
>>>>
>>>> #ifndef abort
>>>> extern void abort (void) __attribute__ ((__noreturn__));
>>>> #endif
>>>>
>>>> Who is supposed to define abort here optionally? Can this be defined 
>>>> for example by a target configuration header like gcc/config/rtems.h?
>>>>
>>>
>>> Apparently, it's a hairy revision:
>>> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=7e7de68b8938
>>>
>>> What happens now on RTERM where you have inhibit_libc set to true? Do 
>>> you end up with an undefined symbol?
>>
>> No, we have abort() in RTEMS (from Newlib).  The problem is that 
>> abort() is a very heavy weight function which pulls in the signal and 
>> file streams support.
> 
> Oh, I see.
> 
>>
>> In case of RTEMS, the application and the operating system is 
>> statically linked into one executable. The more features an 
>> application uses the bigger will be the executable. The abort() 
>> function pulls in a lot of stuff since it uses signals and may attempt 
>> to close all open streams. It would be nice if the gcc_assert() could 
>> be customized by the target configuration. For RTEMS we could use the 
>> Newlib defined __assert_func() from <assert.h>:
>>
>> # define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, 
>> __LINE__, \
>>                                 __ASSERT_FUNC, #__e))
>>
>>
>> void __assert_func (const char *, int, const char *, const char *)
>>          _ATTRIBUTE ((__noreturn__));
>>
> 
> Then what about adding a condition to gcc/tsystem.h where where you 
> would define
> a different gcc_assert based on rtems target?

This would be suitable for me, however, I am not sure if you want such a 
customization feature just for a niche operating system.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gcc_assert() and inhibit_libc

[Martin Liška]

On 8/12/21 4:31 PM, Sebastian Huber wrote:
> This would be suitable for me, however, I am not sure if you want such a customization feature just for a niche operating system.

I don't see a reason why not.
Please send a patch.

Martin

Re: gcc_assert() and inhibit_libc

[Sebastian Huber]

On 16/08/2021 14:33, Martin Liška wrote:
> On 8/12/21 4:31 PM, Sebastian Huber wrote:
>> This would be suitable for me, however, I am not sure if you want such 
>> a customization feature just for a niche operating system.
> 
> I don't see a reason why not.
> Please send a patch.

Ok, good. I will try to figure out what can be done. One problem is that 
tsystem.h is included before tm.h.  Independent of this Joseph S. Myers 
said in the recent patch review with respect to the gcov_type size that 
removing tm.h from the target libraries is a development goal.

I guess we have a couple of options.

1. Detect the presence of __assert_func and add the result to tconfig.h. 
This can't be a link time check, since libgcc is build before Newlib.

2. Use __builtin_trap() instead of abort() if inhibit_libc is defined. 
The trap builtin is target-specific. Making this system-specific (in 
this case RTEMS) could be an issue.

3. Add a new target hook for the gcc_assert() failure. This has the same 
problem as 2. with respect to customization by system and not architecture.

4. Disable gcc_assert() if inhibit_libc is defined.

5. Use builtin __rtems__ define in tsystem.h as a hack.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gcc_assert() and inhibit_libc

[Jason Merrill]

On Mon, Aug 16, 2021 at 9:51 AM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> On 16/08/2021 14:33, Martin Liška wrote:
> > On 8/12/21 4:31 PM, Sebastian Huber wrote:
> >> This would be suitable for me, however, I am not sure if you want such
> >> a customization feature just for a niche operating system.
> >
> > I don't see a reason why not.
> > Please send a patch.
>
> Ok, good. I will try to figure out what can be done. One problem is that
> tsystem.h is included before tm.h.  Independent of this Joseph S. Myers
> said in the recent patch review with respect to the gcov_type size that
> removing tm.h from the target libraries is a development goal.
>
> I guess we have a couple of options.
>
> 1. Detect the presence of __assert_func and add the result to tconfig.h.
> This can't be a link time check, since libgcc is build before Newlib.
>
> 2. Use __builtin_trap() instead of abort() if inhibit_libc is defined.

I still think this seems the most straightforward approach.

> The trap builtin is target-specific. Making this system-specific (in
> this case RTEMS) could be an issue.

Is that necessary?  Are there interesting targets that don't have a trap insn?

> 3. Add a new target hook for the gcc_assert() failure. This has the same
> problem as 2. with respect to customization by system and not architecture.
>
> 4. Disable gcc_assert() if inhibit_libc is defined.
>
> 5. Use builtin __rtems__ define in tsystem.h as a hack.

6. Suppress ENABLE_RUNTIME_CHECKING when inhibit_libc.

Jason

Re: gcc_assert() and inhibit_libc

[Jakub Jelinek]

On Mon, Aug 16, 2021 at 12:50:49PM -0400, Jason Merrill via Gcc wrote:
> > The trap builtin is target-specific. Making this system-specific (in
> > this case RTEMS) could be an issue.
> 
> Is that necessary?  Are there interesting targets that don't have a trap insn?

Depends on the definition of interesting.
I think avr, bpf, c6x, cr16, epiphany, fr30, frv, ft32, h8300, lm32, m32c, m32r, mcore,
mmix, mn10300, moxie, msp430, or1k, pdp11, pru, rl78, rx, sh, stormy16, v850 and vax
don't have trap insn, while
aarch64, alpha, arc, arm, bfin, cris, csky, gcn, i386, ia64, iq2000, m68k, microblaze,
mips, nds32, nios2, nvptx, pa, riscv, rs6000, s390, sparc, tilegx, tilepro, visium and xtensa
have them.

	Jakub

Re: gcc_assert() and inhibit_libc

[Jeff Law]

On 8/16/2021 11:06 AM, Jakub Jelinek via Gcc wrote:
> On Mon, Aug 16, 2021 at 12:50:49PM -0400, Jason Merrill via Gcc wrote:
>>> The trap builtin is target-specific. Making this system-specific (in
>>> this case RTEMS) could be an issue.
>> Is that necessary?  Are there interesting targets that don't have a trap insn?
> Depends on the definition of interesting.
> I think avr, bpf, c6x, cr16, epiphany, fr30, frv, ft32, h8300, lm32, m32c, m32r, mcore,
> mmix, mn10300, moxie, msp430, or1k, pdp11, pru, rl78, rx, sh, stormy16, v850 and vax
> don't have trap insn, while
> aarch64, alpha, arc, arm, bfin, cris, csky, gcn, i386, ia64, iq2000, m68k, microblaze,
> mips, nds32, nios2, nvptx, pa, riscv, rs6000, s390, sparc, tilegx, tilepro, visium and xtensa
> have them.
Probably safer to say "no trap insn currently defined".  I'd bet 
multiple targets in the first set have trap insns defined in their ISA, 
but not in the MD file.

jeff

Re: gcc_assert() and inhibit_libc

[Sebastian Huber]

On 16/08/2021 18:50, Jason Merrill wrote:
> On Mon, Aug 16, 2021 at 9:51 AM Sebastian Huber
> <sebastian.huber@embedded-brains.de>  wrote:
>> On 16/08/2021 14:33, Martin Liška wrote:
>>> On 8/12/21 4:31 PM, Sebastian Huber wrote:
>>>> This would be suitable for me, however, I am not sure if you want such
>>>> a customization feature just for a niche operating system.
>>> I don't see a reason why not.
>>> Please send a patch.
>> Ok, good. I will try to figure out what can be done. One problem is that
>> tsystem.h is included before tm.h.  Independent of this Joseph S. Myers
>> said in the recent patch review with respect to the gcov_type size that
>> removing tm.h from the target libraries is a development goal.
>>
>> I guess we have a couple of options.
>>
>> 1. Detect the presence of __assert_func and add the result to tconfig.h.
>> This can't be a link time check, since libgcc is build before Newlib.
>>
>> 2. Use __builtin_trap() instead of abort() if inhibit_libc is defined.
> I still think this seems the most straightforward approach.

I sent a patch for this:

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577544.html

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gcc_assert() and inhibit_libc

[Joseph Myers]

On Mon, 16 Aug 2021, Sebastian Huber wrote:

> Ok, good. I will try to figure out what can be done. One problem is that
> tsystem.h is included before tm.h.  Independent of this Joseph S. Myers said
> in the recent patch review with respect to the gcov_type size that removing
> tm.h from the target libraries is a development goal.

That is, removing the *host* tm.h from the target libraries.  libgcc_tm.h 
(and the target macros defined therein that are only ever defined in 
libgcc, not in the host parts of the compiler) is not a problem.

-- 
Joseph S. Myers
joseph@codesourcery.com