Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8369

Re: 64-bit detection

Show all headers | View raw

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:aea7adff-b96a-492c-a592-14ffbf5bb026@googlegroups.com...
> On Tuesday, July 14, 2015 at 12:37:15 AM UTC-7, James Harris wrote:
> ...
>> DJGPP and OpenWatcom may call lots of things in the background. I 
>> don't
>> know. But bcc and gcc seem, so far, to do just what they are told.
>
> Like I said elsewhere in the (other?) thread, gcc has a habit of
> generating calls and references to the guts of the standard library.
> Pre-main() initialization, stack overflow checks and so on.

Main does not need to be used for an OS (thus avoiding linking the C 
runtime) and if main *is* used (as it would be for an app) a custom C 
runtime can be provided.

Even with main being present the C runtime calls main, not the other way 
around, AIUI, so the pre-main initialisation you mention does not need 
to affect the compiler's output. IME gcc will compile a function, even 
main, I believe, to do just what the programmer has coded (with the 
possible exception of stack checking, mentioned below).

I mentioned stack overflow checks in the paragraph preceding the one you 
quoted above as something I'll have to come back to.

...

Thanks for the explanation of DPMI (snipped).

>> The point being that each library would provide the same functions. 
>> It's
>> just that their implementations would differ. The single compiler 
>> should
>> be able to interact with different operating systems by being linked
>> with the appropriate library.
>
> Not necessarily. Again, as it has been mentioned before, there are 
> some
> OS-specific things that the compiler may choose to use or is actually
> forced to use:
> 1. 128-byte "red-zone" below ESP/RSP on Linux is guaranteed to not be
> overwritten by the OS (ISRs, signal handlers) and gcc may not
> explicitly subtract the size of the local variables from ESP/RSP and
> thus save an instruction in many places.
> 2. More then 4KB worth of local variables on the stack on Windows
> require special handling due to the way Windows automatically grows
> the stack as it's being used. Windows checks that it doesn't grow by
> more than 4KB at a time (more is considered a programming error). So,
> if you allocate an 8KB buffer and write to its first byte, you get a
> crash induced by the OS. To avoid it, you need to touch a byte of
> the stack in every 4KB page, from ESP/RSP downwards.

I am aware of that, and that Windows provides a function (called _stkchk 
or _chkstk or something similar) to do such stack extension.

Paging OSes can handle stack extension and checking differently from 
non-paging ones. x86 and ARM have different mechanisms to do such 
checks. Leaf functions can work differently to ones which call others, 
etc, and I have some (incomplete) ideas on how to approach such checks 
portably but I'll have to come back to the topic.

In this context, though, are you saying that gcc, say, has to know what 
OS it is compiling for, or at least what stack checking mechanism its 
host OS uses? Can the compiler not be told what stack checking mechanism 
to use by some command-line switch?

If a compiler inserted, say, Windows-style stack checks in every 
function then the generated code could not be expected to work elsewhere 
and the compiler would not be suitable for writing OS code so I would be 
surprised if the checking mechanism was fixed.

James

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-09 16:47 -0700
  Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-09 23:41 -0400
    Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-10 08:30 +0100
      Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-10 05:17 -0400
        Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-10 13:41 +0100
          Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-12 19:04 +0100
            Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 02:30 -0400
              Re: 64-bit detection "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-13 02:07 -0700
                Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 23:10 -0400
                Re: 64-bit detection "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-14 01:23 -0700
              Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-13 12:34 +0100
                Re: 64-bit detection "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 22:50 -0400
                Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-14 08:37 +0100
                Re: 64-bit detection "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-14 01:41 -0700
                Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-14 10:04 +0100
      Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 08:44 -0700
      Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 10:52 -0700
    Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 08:38 -0700
      Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 10:58 -0700
  Re: 64-bit detection CN <qmbmnp3799@pacbell.net> - 2015-07-09 23:00 -0700
    Re: 64-bit detection "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-10 08:40 -0700
      Re: 64-bit detection "James Harris" <james.harris.1@gmail.com> - 2015-07-10 21:29 +0100

csiph-web