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

Pedro Alves
2012-11-15T18:14:34Z

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