linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kamil Dudka <kdudka@redhat.com>
To: Christopher Li <sparse@chrisli.org>
Cc: linux-sparse@vger.kernel.org
Subject: Re: [PATCH] do not ignore attribute 'noreturn'...
Date: Mon, 14 Sep 2009 21:44:37 +0200	[thread overview]
Message-ID: <200909142144.37273.kdudka@redhat.com> (raw)
In-Reply-To: <70318cbf0909141055m218d2819m592f9fa72cc26774@mail.gmail.com>

On Monday 14 of September 2009 19:55:49 Christopher Li wrote:
> On Mon, Sep 14, 2009 at 10:32 AM, Kamil Dudka <kdudka@redhat.com> wrote:
> > As for the long term solution, I don't think it's possible without
> > breaking the current API/ABI. What about using a bitfield instead? I can
> > see it solved this way in <gcc/tree.h>.
>
> I am actually not afraid of breaking current API/ABI because there is not
> enough sparse user application to worry about. Just recompile the apps
> should be fine. Please warn me if any one disagree.
>
> As for long term, here is my plan, it will go will with Al's replace same
> type with same type pointer plan as well.
>
> We need to have a different structure to support the extended attributes
> for ctype. Current "contexts" and "as" should go into that extended
> attribute as well. Then ctype should have one pointer for extended
> attributes. For most common case, the extended attribute pointer is just
> NULL.
>
> Because the extended attribute pointer is possibles to be shared between
> different ctypes. It is not allow to modify the extended attribute struct
> from ctype directly. Instead it should replace with a new one.
> We can even hash the extended attribute struct so same attribute struct
> will have the same pointer, just like ident. That will make comparing
> attribute is the same much easier.
>
> I try it before, it is  hard to do because current code does implicit
> assign for the ctype.

It sounds like a tough challenge to me :-)

I am playing with the SPARSE API now. Any chance to pass in a unique ID
to each symbol? (as equivalent to DECL_UID from <gcc/tree.h>) I can of course 
manage an ptr/ID mapping at application level. I am only curious if this is 
possible to place directly into SPARSE, so that other apps could gain
from it. Please let me know if such functionality is already implemented
in SPARSE.

Kamil

  reply	other threads:[~2009-09-14 19:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-28 21:30 [PATCH] do not ignore attribute 'noreturn' Kamil Dudka
2009-08-28 21:44 ` Christopher Li
2009-09-14 17:27   ` Christopher Li
2009-09-14 17:32     ` Kamil Dudka
2009-09-14 17:55       ` Christopher Li
2009-09-14 19:44         ` Kamil Dudka [this message]
2009-09-14 20:47           ` Christopher Li
2009-09-14 21:13             ` Kamil Dudka

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=200909142144.37273.kdudka@redhat.com \
    --to=kdudka@redhat.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.org \
    /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;
as well as URLs for NNTP newsgroup(s).