[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: 1729298186246727.jpg (511 KB, 1748x2480)
511 KB
511 KB JPG
previous: >>108589999

#define __NR_modify_ldt                154

https://man7.org/linux/man-pages/man2/modify_ldt.2.html

tl;dr:
modify the local descriptor table for you process's memory map

what exactly does that mean? hah, good question. it sure seems like it's really, really, really old legacy code for managing memory mappings and thread local storage. the only interesting thing you can do with this these days is maybe run legacy 16-bit code, which is actually kind of cool i guess? any anon interested in trying to make that happen? would love to hear if you can get it to work

relevant resources:
man man

man syscalls

https://man7.org/linux/man-pages/
https://linux.die.net/man/
https://elixir.bootlin.com/linux/
https://elixir.bootlin.com/musl/
https://elixir.bootlin.com/glibc/
>>
me on the right
>>
>>108597697
This used to be used by Wine for running win32 programs within a 64-bit wine instance, before the switch over to using a WoW64-style interface. It was one of the sticking points for ages that prevented 64-bit wine from working correctly on Macs (MacOS does nonsense that clobbers the GDT and LDTs).
>>
>>108597697
Me on the left.
>>
>>108598566
>It was one of the sticking points for ages that prevented 64-bit wine from working correctly on Macs
Based, fuck MacOS and fuck all the retards who felled for it.
>>
>>108597697
>what exactly does that mean?
Once upon a time Intel was very retarded and slapped a 16-bit CPU onto a 20-bit address bus. The reason they were very retarded was because they didn't give a hoot about forward compatibility, so instead of doing the sane thing (((segment_register << 16) + offset_register) & 0xFFFFF) - i.e. allowing people to use the first four bits of the segment register to be used linearly - they decided to do (((segment_register << 4) + offset_register) & 0xFFFFF) instead. The difference? Throwing away 12 perfectly good bits for future generations so that programmers could do wraparounds (which then immediately broke when the A20 gate was introduced).

Then Intel became even more retarded and introduced protected mode, in which the values of the segment registers all of a sudden became byte indices into a descriptor table. The reason they did that was because the 286 was hooked to a 24-bit address bus, which their previous addressing scheme couldn't fully utilize - but with descriptors you can provide a base address that's bigger than 16 bits, thus circumventing this limitations. Only problem: you were still limited to 64 KB blocks.

Then Intel hired some actual engineers, and those built the 386, which finally had 32-bit registers and a 32-bit address bus, finally allowing for linear address space. Problem: they had already introduced descriptors, and now they have to carry them around until the heat death of the universe. These days most segment registers just point to some descriptor with the base address zero, so that SS:RSP doesn't fuck everything up.
>>
>>108600539
There are some exceptions however, like GS/FS (depending on OS and architecture). On x64 Windows for example GS:0x58 takes whatever nonsense the descriptor at [internal_descriptor_table_address + GS] is pointing at, loads that value (or, rather, uses it from an internal register, because memory is slow), adds 0x58 bytes to it, and all of a sudden you have a pointer to TLS slots - or in other words: GS points at some thread-local structures.
>>
File: 1725801378986.png (293 KB, 1080x720)
293 KB
293 KB PNG
>>108597697
KITA-CHAN
>>
kita marriage
>>
kita is gay (just like OP)
>>
>>108601663
/thread
>>
>>108601670
no, i still like these threads
>>
>>108601677
The topic is great, I'm just sick of the coomer bait pictures and the inevitable awful replies.
>>
File: kita chan.png (1.05 MB, 1200x900)
1.05 MB
1.05 MB PNG
>>
>>108601663
nah-uh i'm a bishit
>>108601685
u are welcome to contribute to them. there's really only so much i can do on my own. i still have a job to go to and a life to live. it's a surprising amount of effort to make these threads consistently every day. you'll forgive me if i take steps to ensure they stay bumped until i get home
>>
>>108601685
>I'm just sick of the coomer bait pictures and the inevitable awful replies.
they are part of why i like them tho
>>
>>108601685
i don't see the coomer bait though? i mean, they're just anime
>>
>>108601725
Really, you don't see it?
>>108548206
>>108548235
>>108548875
>>108549847
>>
>>108601685
What's coomerbait about the OP?
>>
>>108601755
It successfully got a number of lewd replies.
>>108601696
I'd contribute more if you weren't trying to drive the sane people out.
>i still have a job to go to and a life to live. it's a surprising amount of effort to make these threads consistently every day. you'll forgive me if i take steps to ensure they stay bumped until i get home
I do like the topic, so thank you for posting these. I just wish you would do it better, that's all.
>>
>>108601773
>lewd replies
where itt?
>>
>>108601754
anons get horny over things like >>108577706, too
>>
>>108601775
>>108601754
>>
>>108601773
>It successfully got a number of lewd replies.
A picture of Ebussy will get a number of lewd replies.
>>
>>108601773
If pictures of anime girls are driving you away, then maybe 4chan isn't the place for you. Just sayan.
>>
>people are discussion tranime nonsense rather than the topic on hand
Very cute.

>>108600539
There's a continuation to that story with the 386 - because that processor was actually able to use 32-bit registers in both protected AND real mode. In real mode this allowed for nonsense like DS:EAX to specify an address - why was it nonsense? Because real mode didn't make use of descriptors. Kind of. Not really though. It was basically an emulation layer on top of real mode.

Why is that important? Because it allowed for a thing called "unreal mode", in which one could circumvent the 64-KB limitation that was present with 16-bit registers with 32-bit registers and specifically crafted descriptors.

And why is *that* important? Because there were plenty of programs (games) that used to switch between real and protected mode all the time - real mode for BIOS functions, protected mode for memory management due to increased address space. With unreal mode you could have the best of both worlds ... in theory. In reality almost no one made use of it, for whatever reason.
>>
>>108597697
this is the first syscall thread I can recall where we have something that's generally useless for mass linux noobies. Neat history tho
>>
>>108602863
thank you for sharing, anon! the history is really interesting



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.