0

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 !!

Rajiv Kumar Srivastav
  • 111
  • 1
  • 6
  • 2
    You are trying to revive the horrors of 16-bit x86 coding. You'll have to change the operating system and compiler first. Odds that your patches will be accepted are zero so it is a build-a-submarine-in-the-basement kind of project. – Hans Passant Feb 26 '13 at 12:36
  • Is is possible by any other method? – Rajiv Kumar Srivastav Feb 28 '13 at 05:11

2 Answers2

0

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.)

Assad Ebrahim
  • 6,234
  • 8
  • 42
  • 68
  • The question is asking for an option to make gcc's code-gen use an `es` prefixes for accessing a custom section, not how to do it in hand-written code. (Weird, because that would 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) Anyway, if you're writing asm by hand, AT&T syntax already allows `%es:(%eax)` so there's no need to mention the numeric prefix values. – Peter Cordes Aug 02 '18 at 02:41
  • @PeterCordes. True on both points. Making answer community wiki and replacing with yours. – Assad Ebrahim Aug 05 '18 at 12:36
0

Quoting the example from the clang language-extension docs

#define GS_RELATIVE __attribute__((address_space(256)))
int foo(int GS_RELATIVE *P) {
  return *P;
}

Which compiles to (on X86-32):

_foo:
        movl    4(%esp), %eax         # load the arg
        movl    %gs:(%eax), %eax      # use it with its prefix
        ret

address-space 256 is gs, 257 is fs, and 258 is ss.

The docs don't mention es; compilers normally assume that es=ds so they can freely inline rep movs or rep stos for memcpy / memset if they choose to do so based on tuning options. Library implementations of memcpy or memset 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 uses gs for thread-local storage in user-space, while x86-64 Linux uses fs.

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?.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847