From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
To: kettenis@wins.uva.nl
Cc: gcc@gcc.gnu.org
Subject: Re: Segment register support for the i386
Date: Fri, 31 Dec 1999 23:54:00 -0000 [thread overview]
Message-ID: <199912302102.WAA22342@loewis.home.cs.tu-berlin.de> (raw)
Message-ID: <19991231235400._GgMZ0Vtf0WuTpeR4MEw1VzfIgpqBq_m4arMyUNvbws@z> (raw)
In-Reply-To: <199912301755.SAA01528@delius.kettenis.local>
> Well, not exactly. While the "address space attribute" approach would
> be nice to have, it isn't that easy to implement, since there seems to
> be no support for pointer attributes in GCC.
They would not be pointer attributes. Instead, they would be type
attributes:
struct TLS{
fill_in something;
and something_else;
}__attribute__((segment("gs")));
struct TLS *tls;
then you do
tls->something++;
and it knows to use a segment prefix on each reference.
Alternatively, they could be qualifiers, like const, volatile,
restrict - although this sounds like a major new extension.
> It would be nice if I could write:
>
> register struct thread_descr *__thread_self __asm__("%gs");
>
> such that I could use the same C code as in the Sparc case to access
> and manipulate the thread descriptor.
No, that would not be nice. What if I do:
int i;
__thread_self = &i;
That does not *at all* do what it looks like it would do (if it does
anything at all).
> That's why I'm not sure if this approach is acceptable, and I'd like
> to hear what other people think of this proposal before spending too
> much time on finishing my current implementation. I can imagine that
> people say that this extension is really an ugly hack that should
> never be allowed in GCC.
I would be such a person :(
Regards,
Martin
next prev parent reply other threads:[~1999-12-31 23:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-30 9:55 Mark Kettenis
1999-12-30 11:24 ` Linus Torvalds
1999-12-31 23:54 ` Linus Torvalds
1999-12-30 13:07 ` Martin v. Loewis [this message]
1999-12-31 23:54 ` Martin v. Loewis
1999-12-31 23:54 ` Mark Kettenis
-- strict thread matches above, loose matches on Subject: below --
1999-12-24 8:42 Mark Kettenis
1999-12-24 11:41 ` Linus Torvalds
1999-12-28 14:10 ` Jeffrey A Law
1999-12-28 14:47 ` Linus Torvalds
1999-12-31 23:54 ` Linus Torvalds
1999-12-30 12:41 ` Richard Henderson
1999-12-31 4:06 ` Denis Chertykov
1999-12-31 10:49 ` Joern Rennecke
1999-12-31 23:54 ` Joern Rennecke
[not found] ` <v04220801b492c4a4768c@[192.168.1.254]>
2000-01-01 1:26 ` Denis Chertykov
2000-01-01 5:52 ` Alan Lehotsky
2000-01-04 2:05 ` Nick Ing-Simmons
2000-01-04 4:47 ` Denis Chertykov
2000-01-05 9:29 ` Sergey Larin
2000-01-06 11:15 ` Denis Chertykov
2000-01-06 11:25 ` Joern Rennecke
2000-01-06 11:51 ` Denis Chertykov
2000-01-06 11:52 ` Jeffrey A Law
2000-01-07 2:35 ` Denis Chertykov
1999-12-31 23:54 ` Denis Chertykov
1999-12-31 23:54 ` Richard Henderson
1999-12-31 23:54 ` Jeffrey A Law
1999-12-31 23:54 ` Linus Torvalds
1999-12-31 23:54 ` Mark Kettenis
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=199912302102.WAA22342@loewis.home.cs.tu-berlin.de \
--to=martin@loewis.home.cs.tu-berlin.de \
--cc=gcc@gcc.gnu.org \
--cc=kettenis@wins.uva.nl \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).