I have memory layout (In Increasing memory addr) like :
Code Section (0-4k), Data Section(4k-8k), Stack Section(8k-12k), CustomData Section(12k-16k).
I have put some special arrays, structs in Custom Data Section.
As i know, Data Segment (#DS)Selector will be used for any Data related compiler code.
So Data Section(4k-8k) will have #DS by default for all operation. Except some str op where ES may be used. Like:
mov $0xc00,%eax
addl $0xd, (%eax)
But, I want to use Extra Segment(#ES) selector for CustomData access. I would define a new GDT entry for ES with different Base and Limit. like:
mov $0x3400,%eax
addl $0xd, %es:(%eax)
So my question is:
Does GCC has any x86 compiler flag, which can be used to tell compiler that use #ES for CustomData Section code access.?
Means, compiler flag which will generate code using #ES for CustomData Section.?
Thanks in advance !!
Quoting the example from the clang language-extension docs
address-space 256 is
gs
, 257 isfs
, and 258 isss
.The docs don't mention
es
; compilers normally assume thates
=ds
so they can freely inlinerep movs
orrep stos
for memcpy / memset if they choose to do so based on tuning options. Library implementations ofmemcpy
ormemset
may also use rep stos/movs on some CPUs. Related: Why is std::fill(0) slower than std::fill(1)?Obviously this is really low-level stuff, and only makes sense if you've already set the GS or FS base address. (
wrfsbase
). Beware that i386 Linux usesgs
for thread-local storage in user-space, while x86-64 Linux usesfs
.I'm not aware of extensions like this for gcc, ICC, or MSVC.
Well, there is
__thread
in GNU C, which will use%gs:
or%fs:
prefixes as appropriate for the target platform. How does the gcc `__thread` work?.While the question is asking for an option to make gcc's code-gen use an es prefix for accessing a custom section, IF you wanted to do it in hand-written code, the AT&T syntax already allows e.g. %es:(%eax).
Note, this may break rep-string instructions which gcc sometimes inlines; fs or gs would be the only sane choices, and are still usable even in x86-64.
(Making this comment community wiki based on useful critique by Peter Cordes.)