Why is there a “V” in SIGSEGV Segmentation Fault?

Re:Why is there a “V” in SIGSEGV Segmentation Fault? by zaarn on Thursday June 18, 2020 @11:45AM (#23564155)

While technically the modern 64bit CPUs still support segmentation in 16 and 32bit modes (not very well but it works), in 64bit if you're not setting the segment registers to "everything" you're essentially operating outside supported margins. Some strange things happen if you do that.

I don't recall exactly but I don't think segmentation was heavily used after 2000 or so, it doesn't really do a lot for you if you have page tables.

[ Parent | on HN ]

Re:Why is there a “V” in SIGSEGV Segmentation Fault? by Erwin on Thursday June 18, 2020 @04:04PM (#23567330)

One thing the segment registers are still used for are thread local storage (on Linux). So you read data from FS (different per thread) segment but same address, if you've prefixed your variable with __thread.

(Having said that, I remember optimizing thread local storage away by explicit pointers some time ago in my code, because it was calling some function to get the address constantly, so maybe there are some subtleties there)

[ Parent | on HN ]

Re:Why is there a “V” in SIGSEGV Segmentation Fault? by rkeene2 on Thursday June 18, 2020 @10:53PM (#23570509)

FWIW, there was a good LWN article recently on the work to expose FS to userspace control safely

[ Parent | on HN ]

Re:Why is there a “V” in SIGSEGV Segmentation Fault? by waynecochran on Friday June 19, 2020 @03:17PM (#23577935)

I haven't tried this lately, but you get a compiler error if you include <windows.h> and use 'near' and 'far' as variables names (which are holdovers when 'near' and 'far' were keywords for ptrs that supported segmented memory flavors).

A lot of old OpenGL code and uses 'hither' and 'yon' for the near and far clipping plane for this reason. :)

[ Parent | on HN ]