Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: "'Joel Brobecker'" <brobecker@adacore.com>, gdb@sourceware.org
Subject: Re: [RFC] ARI related: Use of GCC poison pragma
Date: Thu, 15 Nov 2012 18:14:00 -0000	[thread overview]
Message-ID: <50A530FA.1020604@redhat.com> (raw)
In-Reply-To: <50a51777.47f0440a.09dd.2b79SMTPIN_ADDED@mx.google.com>

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


  parent reply	other threads:[~2012-11-15 18:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-15  9:01 Pierre Muller
2012-11-15 15:14 ` Joel Brobecker
2012-11-15 16:25   ` Pierre Muller
2012-11-15 17:57     ` Joel Brobecker
     [not found]   ` <50a51777.47f0440a.09dd.2b79SMTPIN_ADDED@mx.google.com>
2012-11-15 18:14     ` Pedro Alves [this message]
2012-11-15 20:13       ` Pierre Muller
2012-11-15 20:33         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A530FA.1020604@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=pierre.muller@ics-cnrs.unistra.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox