[RFC] ARI related: Use of GCC poison pragma

[RFC] ARI related: Use of GCC poison pragma

[Pierre Muller]

  To avoid resurgence of expunged ARI problems,
Pedro suggested the use of GCC poison pragma.

  The problem is that I have no experience with that 
kind of code.
  I looked into the gcc source,
and there seems to be a huge list of forbidden
macros and functions inside gcc/system.h
header.

Small extract of gcc-4.3.1 source:
#if (GCC_VERSION >= 3000)

/* Note autoconf checks for prototype declarations and includes
   system.h while doing so.  Only poison these tokens if actually
   compiling gcc, so that the autoconf declaration tests for malloc
   etc don't spuriously fail.  */
#ifdef IN_GCC
#undef calloc
#undef strdup
 #pragma GCC poison calloc strdup

#if !defined(FLEX_SCANNER) && !defined(YYBISON)
#undef malloc
#undef realloc
 #pragma GCC poison malloc realloc
#endif

/* Old target macros that have moved to the target hooks structure.  */
 #pragma GCC poison ASM_OPEN_PAREN ASM_CLOSE_PAREN                      \
        FUNCTION_PROLOGUE FUNCTION_EPILOGUE                             \
        FUNCTION_END_PROLOGUE FUNCTION_BEGIN_EPILOGUE                   \

  What would be the corresponding gdb file?
I suppose it would be defs.h

 So would a patch adding 
#if (GCC_VERSION >= 3000)
#pragma GCC poison xvasprintf
#endif
(and probably lots of other functions aand macros)
be an acceptable way to introduce these poisons?


Pierre Muller
as ARI maintainer

Re: [RFC] ARI related: Use of GCC poison pragma

[Joel Brobecker]

>   To avoid resurgence of expunged ARI problems,
> Pedro suggested the use of GCC poison pragma.

I believe it was Tom, actually.

> What would be the corresponding gdb file?  I suppose it would be
> defs.h

I agree that defs.h should be a good place for it.

> So would a patch adding 
> #if (GCC_VERSION >= 3000)
> #pragma GCC poison xvasprintf
> #endif

I don't think we really need the GCC_VERSION check, do we?

-- 
Joel

RE: [RFC] ARI related: Use of GCC poison pragma

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la part
> de Joel Brobecker
> Envoyé : jeudi 15 novembre 2012 16:14
> À : Pierre Muller
> Cc : gdb@sourceware.org
> Objet : Re: [RFC] ARI related: Use of GCC poison pragma
> 
> >   To avoid resurgence of expunged ARI problems,
> > Pedro suggested the use of GCC poison pragma.
Yes, Pedro talked about simply removing the 
function completely. 
> I believe it was Tom, actually.
 and  Tom suggested use of poison pragma.

> > What would be the corresponding gdb file?  I suppose it would be
> > defs.h
> 
> I agree that defs.h should be a good place for it.
> 
> > So would a patch adding
> > #if (GCC_VERSION >= 3000)
> > #pragma GCC poison xvasprintf
> > #endif
> 
> I don't think we really need the GCC_VERSION check, do we?

  I still think that this should only be 
parsed by GCC.
  So a conditional to restrict to GCC compiler is needed,
but I suppose you meant that the use of a GCC prior to 3000
is not needed...

Pierre

Re: [RFC] ARI related: Use of GCC poison pragma

[Joel Brobecker]

> > > So would a patch adding
> > > #if (GCC_VERSION >= 3000)
> > > #pragma GCC poison xvasprintf
> > > #endif
> >
> > I don't think we really need the GCC_VERSION check, do we?
>
> I still think that this should only be parsed by GCC.  So a
> conditional to restrict to GCC compiler is needed, but I suppose you
> meant that the use of a GCC prior to 3000 is not needed...

I don't see why. Looking at the C 89 reference manual, it clearly states
that unknown pragmas are simply ignored:

| 3.8.6 Pragma directive
|
| Semantics
|
|    A preprocessing directive of the form
|
|          # pragma  pp-tokens<opt> new-line
|
| causes the implementation to behave in an implementation-defined
| manner.  Any pragma that is not recognized by the implementation is
| ignored.

So, protecting the pragma with a GCC-specific check seems to be
useless. Or is there something else we're trying to do?

-- 
Joel

Re: [RFC] ARI related: Use of GCC poison pragma

[Pedro Alves]

On 15-11-2012 16:25, Pierre Muller wrote:
> 
> 
>> -----Message d'origine-----
>> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la part
>> de Joel Brobecker
>> Envoyé : jeudi 15 novembre 2012 16:14
>> À : Pierre Muller
>> Cc : gdb@sourceware.org
>> Objet : Re: [RFC] ARI related: Use of GCC poison pragma
>>
>>>   To avoid resurgence of expunged ARI problems,
>>> Pedro suggested the use of GCC poison pragma.
> Yes, Pedro talked about simply removing the 
> function completely. 
>> I believe it was Tom, actually.
>  and  Tom suggested use of poison pragma.


Yes, and believe it or not, before suggesting that, I actually
wrote a patch that copied over the poison stuff from GCC into GDB.  :-) I did it
to easily see where the function was still used.  But the only usages that revealed
were in the function definition itself, and so I just pointed out that it can
just be removed.  I then deleted the patch I had, as thinking that it wasn't
_that_ useful.  For gcc it's more useful as it still does a lot of things with
target macros, instead of target methods.  Poisoning gdb functions IMO doesn't
have that much value, since once you remove them, you can't use them anymore
anyway without the compiler or linker complaining.  It could be more useful
for symbols from libiberty we might not want to use, for instance.

So I still say, just remove the unused function.  Poisoning that particular
symbol afterwards doesn't add anything.


> 
>>> What would be the corresponding gdb file?  I suppose it would be
>>> defs.h
>>
>> I agree that defs.h should be a good place for it.
>>
>>> So would a patch adding
>>> #if (GCC_VERSION >= 3000)
>>> #pragma GCC poison xvasprintf
>>> #endif
>>
>> I don't think we really need the GCC_VERSION check, do we?
> 
>   I still think that this should only be 
> parsed by GCC.
>   So a conditional to restrict to GCC compiler is needed,
> but I suppose you meant that the use of a GCC prior to 3000
> is not needed...
> 
> Pierre
> 
> 
> 


-- 
Pedro Alves

RE: [RFC] ARI related: Use of GCC poison pragma

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la part
> de Pedro Alves
> Envoyé : jeudi 15 novembre 2012 19:14
> À : Pierre Muller
> Cc : 'Joel Brobecker'; gdb@sourceware.org
> Objet : Re: [RFC] ARI related: Use of GCC poison pragma
> 
> On 15-11-2012 16:25, Pierre Muller wrote:
> >
> >
> >> -----Message d'origine-----
> >> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part
> >> de Joel Brobecker
> >> Envoyé : jeudi 15 novembre 2012 16:14
> >> À : Pierre Muller
> >> Cc : gdb@sourceware.org
> >> Objet : Re: [RFC] ARI related: Use of GCC poison pragma
> >>
> >>>   To avoid resurgence of expunged ARI problems,
> >>> Pedro suggested the use of GCC poison pragma.
> > Yes, Pedro talked about simply removing the
> > function completely.
> >> I believe it was Tom, actually.
> >  and  Tom suggested use of poison pragma.
> 
> 
> Yes, and believe it or not, before suggesting that, I actually
> wrote a patch that copied over the poison stuff from GCC into GDB.  :-) I
> did it
> to easily see where the function was still used.  But the only usages that
> revealed
> were in the function definition itself, and so I just pointed out that it
> can
> just be removed.  I then deleted the patch I had, as thinking that it
wasn't
> _that_ useful.  For gcc it's more useful as it still does a lot of things
> with
> target macros, instead of target methods.  Poisoning gdb functions IMO
> doesn't
> have that much value, since once you remove them, you can't use them
anymore
> anyway without the compiler or linker complaining.  It could be more
useful
> for symbols from libiberty we might not want to use, for instance.
> 
> So I still say, just remove the unused function.  Poisoning that
particular
> symbol afterwards doesn't add anything.
But we could poison function that do exist
in standard includes like
  sprint for example, no?

Pierre

Re: [RFC] ARI related: Use of GCC poison pragma

[Pedro Alves]

In 15-11-2012 20:12, Pierre Muller wrote:
> But we could poison function that do exist
> in standard includes like
>   sprint for example, no?

Yes, that might be a good one to poison.

-- 
Pedro Alves