[itchyjunk] has quit [Read error: Connection reset by peer]
noeontheend has quit [Ping timeout: 260 seconds]
ajr has joined #osdev
vai has joined #osdev
<vai>
I feel great! Good morning!
<Mutabah>
'morning :)
matt__ has joined #osdev
ajr_ has joined #osdev
ajr has quit [Ping timeout: 272 seconds]
Patater has quit [Ping timeout: 276 seconds]
vai has quit [Quit: leaving]
vai has joined #osdev
ajr_ is now known as ajr
<doug16k>
have you seen amd's mitigation paper for that new spectre variant. when an instruction spans a indirect predictor address, it erases that predictor entry. that's a big surprise
<doug16k>
you put a byte before it that makes the following bytes be a superfluous cmp that spans the indirect branch, then branch back into the middle of the cmp to the indirect branch
vai has quit [Quit: Lost terminal]
<doug16k>
and it will have erased any attacker attempt to redirect the indirect branch
GeDaMo has joined #osdev
<doug16k>
you can just do a big giant IBPB at privilege changes, but if you want max speed, better to not IBPB and just pessimize the indirect branches
<doug16k>
ibpb can be 10000 cycles
mzxtuelkl has joined #osdev
<doug16k>
they botched the cpuid a little too. zen3 is not affected, and the cpuid leaf doesn't say it is unaffected. future ones will say if they are unaffected there
<doug16k>
they need to stop it with the aliasing nonsense and use full tags
<doug16k>
or even more than full tags. have address space id too
<doug16k>
so you can't even attack yourself from inside the same process
<moon-child>
'put a byte before it that makes the following bytes be a superfluous cmp that spans the indirect branch, then branch back into the middle of the cmp to the indirect branch'
<moon-child>
cuute
<moon-child>
also maybe this'll give disassemblers the kick in the teeth they need to not suck. Probably not, though
<doug16k>
yeah I wonder if it will get some special handling for that
<doug16k>
yeah, probably not
<moon-child>
I don't want 'special handling'
<moon-child>
I want them to handle the general case
<moon-child>
afaik dedicated re tools do an ok job
<moon-child>
but not fully general
<doug16k>
you need global knowledge to pull that off completely. you could see calling into the middle of an instruction in far away code
<moon-child>
yep
<doug16k>
generate comments that show the weird entry point and what instructions they are?
<moon-child>
I mean, at some point rice's theorem gets in your way
<doug16k>
heuristically figure out which one is primary and yeah, rabbit hole
<moon-child>
for one, there are indirect jumps (circling back...) which could go anywhere
<doug16k>
true
<moon-child>
but you could also try to explicitly thwart such a scheme by inserting a bunch of dummy jumps to insignificant locations, which dummies aren't accessed by any interesting paths
<doug16k>
maybe a tool that finds all possible entry points that don't lead to crashing and show them with the victim code
xhe has quit [Read error: Connection reset by peer]
<moon-child>
all I want, really, is for them to _acknowledge_ that the totality of the cfg includes an instruction decoded at every offset
xhe has joined #osdev
<moon-child>
some heuristics for 'interesting' code paths that aren't reached from normal entry points
<moon-child>
and a way for me to look at the 'dead' instructions myself and potentially annotate them as live
<doug16k>
can't you just trap the SIGILL and bump eip ahead a byte and return? lol
<moon-child>
yep
<doug16k>
in my project you can too
<moon-child>
so you have to have an edge going from any potentially faulting instruction to the fault handler
<moon-child>
but it's Hard statically to figure out where you get out of the fault handler
<doug16k>
if you have every edge like that, then you need all irq handlers spraying out between every instruction
<doug16k>
except after they moved to ss if it was x86 :P
<moon-child>
oh yeah, you could just randomly have an interrupt following every instruction
<doug16k>
if it is context switching, then you get a universe shattering explosion of paths
<doug16k>
where all the energy in the universe isn't enough to store it
<GeDaMo>
Pfft! Just get a bigger universe :P
<doug16k>
yeah, I told them to order a universe with a higher speed of light next time, the propagation is way too sluggish in this one
<moon-child>
:D
ajr has quit [Quit: WeeChat 3.6]
* kof
waits for universe to show up on ebay after bubble pops
foudfou has quit [Remote host closed the connection]
xhe has joined #osdev
foudfou has joined #osdev
opal has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou_ has joined #osdev
wootehfoot has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
hello-smile6 has joined #osdev
hello-smile6 has quit [Ping timeout: 252 seconds]
wootehfoot has quit [Ping timeout: 268 seconds]
wootehfoot has joined #osdev
the_lanetly_052 has quit [Ping timeout: 255 seconds]
xhe has quit [Read error: Connection reset by peer]
xhe has joined #osdev
wootehfoot has quit [Ping timeout: 240 seconds]
wootehfoot has joined #osdev
j0hn has left #osdev [WeeChat 3.5]
MarchHare has quit [Ping timeout: 244 seconds]
sikkiladho_ has joined #osdev
<sikkiladho_>
I was reading a book about Linux, which explains that pointer to task_struct is stored in thread_info for x86 and thread_info is stored at the end of stack so that it's easier to get access it just using stack pointer.
<sikkiladho_>
But when I looked at the x86 code for thread_info, task_struct is not there and I found the commit which removed it:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/include/asm/thread_info.h?id=15f4eae70d365bba26854c90b6002aaabb18c8aa
<bslsk05>
git.kernel.org: kernel/git/torvalds/linux.git - Linux kernel source tree
<bslsk05>
lwn.net: thread_info cleanups and stack caching [LWN.net]
<zid`>
so.. try read that, maybe it's relevent
<zid`>
it was overly magic and made the stack have to stay around even after the task was 'dead' and had to be refcounted away etc by the sounds of it
[itchyjunk] has joined #osdev
<sikkiladho_>
thank you, it helps.
xhe has quit [Ping timeout: 268 seconds]
chartreuse has quit [Ping timeout: 240 seconds]
xhe has joined #osdev
matt__ has quit [Ping timeout: 240 seconds]
MarchHare has joined #osdev
<zid`>
There, meal prep done
tsraoien has joined #osdev
pretty_dumm_guy has joined #osdev
jafarlihi has joined #osdev
<jafarlihi>
Is it possible with GCC to assemble inline assembly and write the machine code into a normal C variable buffer?
<jafarlihi>
I want to use inline assembly but write the resulting machine code to specific address
<bauen1>
jafarlihi: I'm sure you can use the function address and iirc __attribute__((naked)) to avoid the function pro/epilog do something like that
<jafarlihi>
Yeah, that sounds interesting, thanks
<bauen1>
like `void __attribute__((naked)) f(void) { asm volatile ("...."); }` and then copy the data from there, or maybe put it in a specially named section so you have a start + size/end
jafarlihi has quit [Quit: WeeChat 3.5]
<mrvn>
naked is an ARM only think iirc. And how would you get the function size?
<doug16k>
put it into a special input section, then in the linker script, put something = .; and something_end = .; around it
<doug16k>
you can use __attribute__((section, ".something")) on the function to place it in there
<doug16k>
then you can memcpy it using the symbols to compute the size
<doug16k>
it might matter where the code is, though
<doug16k>
you can't necessarily just scoop up code bytes and put them somewhere else, and expect that code to work
<doug16k>
depends on whether you moved the program image as a whole, then the relative values are correct
<doug16k>
global variable accesses will probably be using a position independent encoding
<doug16k>
which means they screw up if you copy the code somewhere else and run it
<doug16k>
unless you moved all the variables the same distance
<doug16k>
or fix the instructions by examining relocations
bradd has quit [Quit: No Ping reply in 180 seconds.]
<doug16k>
then you run into needing to keep it within a certain distance of things
<doug16k>
it can only withstand being so far away from the globals
bradd has joined #osdev
<doug16k>
oh way worse, calls will be position independent, so they all need fixup
<doug16k>
indirect calls would probably just work
<doug16k>
they're absolute
gxt has quit [Quit: WeeChat 3.5]
<doug16k>
assuming it isn't a global function pointer!
<doug16k>
then you need position independent to find it
<doug16k>
fixup
<doug16k>
get ready to be the linker itself
gxt has joined #osdev
<GeDaMo>
Why not just use an assembler to generate the bytes then copy them to where ever you want?
<GeDaMo>
Oh, they left :P
<zid`>
That's what I do with my GeDaMo
<zid`>
I write him once, then send him all over to buy the shortbread
<doug16k>
oh crap they did leave. I thought I checked
<doug16k>
sometimes I wonder how much they are paying per minute for IRC, when I see how quickly people leave after they ask
<doug16k>
totally brainwashed to run one program at a time maybe?
<doug16k>
a superstition
<GeDaMo>
Maybe they're in a public place and don't want someone watching over their shoulder :|
<GeDaMo>
"Are you on that IRC again?" "No, mum, I'm watching porn!" :P
<doug16k>
sometimes it drives me nuts when I am helping someone and I ask them to open a program or switch to the browser, and they can't help it, they MUST click the X.
<doug16k>
hehe
mimmy has joined #osdev
<zid`>
My mother closes her web browser and reopens it to do google searches
<doug16k>
reminds me of a friend. he had 3 C64 power supplies to use when his mom took it away for punishment
<doug16k>
she thought she was so clever, it won't work with no power supply
troseman has joined #osdev
<zid`>
Cute, just read a thing about a boat almost sinking because of some potatoes
<GeDaMo>
Were the potatoes the owners or had they just rented it? :P
<zid`>
electrical fire in a refrigerated trailer set the sprinklers off, compartment starts to fill with water. Water inside a ship is BAD because it flows to the lowest point, making any tilt worse, until it capsizes.
<zid`>
So they have drains to let the sprinkler water flow outside, but it ended up full of potatoes instead.
<zid`>
2010 regs had mandated screens over the drains, but they had pulled out the prototypes to use as patterns to have proper ones fabricated just prior :P
<mrvn>
doug16k: It's inline asm. The code will do what you write. You have to make it PIC.
<doug16k>
mrvn, what's inline asm? a naked compiled function?
<mrvn>
doug16k: "Is it possible with GCC to assemble inline assembly ..."
<zid`>
<doug16k> mrvn, what's inline asm? --2022
<mrvn>
I really have to wonder why you would not just dump it into a .S file and be done.
<doug16k>
exactly
<mrvn>
and make the linker put into the right address from the start.
<zid`>
When a mommy text editor and a daddy compiler love each other very much
<doug16k>
sounded like they wanted to memcpy a function to a buffer
<mrvn>
he wants to hack linux kernels.
<doug16k>
I guess it's not obvious to define externs for labels you wrote in the __asm__
<mrvn>
extern void* myasm[];
<zid`>
I'd quite like to be able to have like.. asm literals
<zid`>
char *buf = asm("mov eax, 12");
<mrvn>
that wouldn't be executable
<doug16k>
you can
<doug16k>
with register variable declaration, then = 12
<zid`>
not what I meant at all
<zid`>
I mean I want the asm keyword to be an expression with an rvalue that is the address of the assembled code
<doug16k>
you can make buf use eax and set it
<doug16k>
that's exactly what you said
<mrvn>
zid`: a naked function is pretty much that, less the size.
<zid`>
You ignored the semantics to focus on the contents of the text
<zid`>
I want the semantics, I'm well aware I can move 12 into eax without being able to use asm blocks as an rvlaue already
<doug16k>
oh it has to be your exact syntax too. my bad
<zid`>
go on then, show me
<zid`>
= 12 is *highly* irrelevent to what I meant, so I'm not expecting this to match
<zid`>
yea effectively it would be the same as char *buf = &(char[1]){0xC3};
<zid`>
not knowing the size is weird but returning a tuple is lame also
<zid`>
but you could do char buf[] =
<mrvn>
hence "buf[]" so it has a size.
<zid`>
and sizeof it
<mrvn>
using [] is a great way to define extern symbols since it decays to pointer. I only wish one could have a `extern "C" void something[];`
<doug16k>
char lets pointer arithmetic give you bytes
<mrvn>
But that would be UB unless the symbol points at an array.
<doug16k>
that's UB but you want to do = asm(...code...) into a buffer
<mrvn>
I don't. I just want to know where some objects defined in boot.S or entry.S are located.
<mrvn>
or thje init_array
<GeDaMo>
I wonder if you could do something with a macro which would call out to an assembler at runtime to generate the bytes and then load them to a buffer :|
<doug16k>
It's UB because of some imaginary scenario where it's segmented, and pointers aren't convertible to integers
<zid`>
at that point you may as well just cat them to an .S file GeDaMo
<GeDaMo>
That's what I said in the first place! :P
<mrvn>
doug16k: I actually have no idea why pointers to `int x;` and `int x[1];` would ever use different representation.
<mrvn>
ALl in favour of a conseval open() raise your hands.
<mrvn>
consteval even
<doug16k>
I wish someone would make a kick ass 80286 compiler where pointers aren't convertible to integers and you can't just subtract stuff. it'll be hilarious to see if a single thing compiles
<doug16k>
flat model or death
<GeDaMo>
Would that even be C? :P
<mrvn>
sure.
<mrvn>
And you can still just subtract pointers.
<mrvn>
intptr_t would have to be 32bit, segment + offset.
<doug16k>
no you can't. every segment has a base and limit
<mrvn>
ptrdiff_t can be 17 bit.
<mrvn>
doug16k: so? YOu can only do pointer arithmatic of pointers in the same allocated block, which means the same segment.
<mrvn>
The segment always cancel out in any standard correct subtraction.
<doug16k>
in real mode? I mean protected mode with hidden bases and limits
<doug16k>
that nutcase scenario is why you can't just compare pointers
<mrvn>
only 99% of it
<mrvn>
The last 1% is arrays of size 0 and objects without unique address.
<mrvn>
and generally the one-past-the-end of an array overlapping the next variable.
xenos1984 has quit [Read error: Connection reset by peer]
<mrvn>
How about: char buf[10]; int i; char c; } buf[10] == &c?
X-Scale` has joined #osdev
<doug16k>
it would probably look like it worked when someone tested it
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
<doug16k>
you must have meant [14]?
<doug16k>
you are likely to get away with murder with char one - compiler is scared to death about aliasing on char*
<doug16k>
if you tried to use buf to change the int, good luck
<mrvn>
doug16k: changing the int is definetly bad. This is just about comparison though.
<mrvn>
buf[10] == &i would be UB because of different types but probably give true.
<doug16k>
in gcc, I expect just by taking its address you made it be there
<doug16k>
linux kernel people want it to be pessimized
<mrvn>
doug16k: you have to have a struct to be able to do the compare so it has to be there.
mimmy has quit [Ping timeout: 260 seconds]
<mrvn>
s.buf[10] == &s.c
<mrvn>
Linux kernel people probably want (*(S*)nullptr).buf[10] == &(*(S*)nullptr).c;
<mrvn>
&(*(S*)nullptr).buf[10] == &(*(S*)nullptr).c; I man.
X-Scale` has joined #osdev
<mrvn>
hehe, here is some more "nice" C++ syntax to use at work: class Foo { Foo() : x([]() { try { return something(); } catch (std::exception e) { throw XError(e.what()); }}()) { } ... };
xenos1984 has joined #osdev
X-Scale has quit [Ping timeout: 276 seconds]
X-Scale` is now known as X-Scale
mimmy has joined #osdev
<doug16k>
it destroys the stack trace, right?
<doug16k>
dumb how C++ has no inner exceptions
<mrvn>
doug16k: it has
<mrvn>
at least there is an exeptions count so you know how deep you are.
<doug16k>
yeah, you can get an exception_ptr and put it into another exception, but it's not a thing you can expect people to do
<mrvn>
If you want the inner exception why not use XError(e)?
<mrvn>
That count thing works without the user doing anything.
<doug16k>
count doesn't tell you where the exception actually happened
<doug16k>
if you can just pass e, then do that. why destroy it down to a char *?
<mrvn>
but I guess that's just how deep the rabbit hole you are now, not something to get the original exception if you rethrow.
<mrvn>
Maybe "throw" inside an catch block should implicitly set an exception_ptr in the exception. But then you could only throw something derived from exception.
<doug16k>
I meant to save it when debugging
<doug16k>
I hate it when people wreck the exceptions
<doug16k>
you should just let it go
<mrvn>
me too. python shows a whole exception backtrace
<mrvn>
Now that we have std::source_location I would even say every exception should include that.
<mrvn>
Is there some trick to have my cake and eat it too? I wan't Foo foo = { .x = 2 ]; to keep working.
<doug16k>
get a time machine and use reflection
<doug16k>
take a T and reflect over the members of the initializer and generate the assignments
tsraoien has quit [Ping timeout: 272 seconds]
<doug16k>
maybe someday
<mrvn>
what type would T be? initializer_list on steroids?
<mrvn>
Could you do template<typename Ts..., name ns...> struct AggregateList { Ts ns...; };?
<mrvn>
someday
<doug16k>
yeah, just a totally made up anonymous type
<doug16k>
and in a constexpr like manner, reflection would allow you to loop over the members and statically generate stuff like serializers
<doug16k>
and know the names
jafarlihi has joined #osdev
<jafarlihi>
I already asked ##c, how do I cast start address of a function to char pointer? I get this error: "error: initialization of ‘char *’ from incompatible pointer type ‘void (*)(void)’"
<jafarlihi>
Just needed a cast, nvm
mzxtuelkl has quit [Quit: Leaving]
jafarlihi has quit [Read error: Connection reset by peer]
<mrvn>
someday. I really would like to have to_string() for every enum, even for every object.
<mrvn>
like pythons __repr__
matt__ has joined #osdev
matt__ is now known as freakazoid333
dude12312414 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
xhe has quit [Read error: Connection reset by peer]
xhe has joined #osdev
mimmy has joined #osdev
mimmy has quit [Client Quit]
sebonirc has quit [Remote host closed the connection]
ajr has joined #osdev
sebonirc has joined #osdev
ripmalware has joined #osdev
ZipCPU has quit [Ping timeout: 244 seconds]
ZipCPU has joined #osdev
xhe has quit [Ping timeout: 255 seconds]
* geist
yawns
<geist>
good morning everyone
<ajr>
mornin'
wand has quit [Remote host closed the connection]
wand has joined #osdev
immibis_ has joined #osdev
immibis_ is now known as immibis
hello-smile6 has joined #osdev
cheapie has quit [Remote host closed the connection]
Bonstra has quit [Ping timeout: 240 seconds]
tsraoien has joined #osdev
sikkiladho_ has quit [Quit: Connection closed for inactivity]
<zid`>
Are you all a chip wizard and a food court specialist and an expert model painter yet?
<geist>
omg did i not get the memo?
<geist>
i'm behind! more performance anxiety to add to the pile!
cheapie has joined #osdev
<zid`>
only food court is optimizable tbh
<zid`>
I think that was the 'game' then he added the others as part of the themeing, if I had to guess
<geist>
oooh you mean that, yeah i've been meaning to pick it up
<geist>
currently on a slog to play through all of the final fantasy main series one at a time
xenos1984 has quit [Read error: Connection reset by peer]
<zid`>
ah neat
<zid`>
what are you up to?
<geist>
bought all of the pixel remasters on steam 1-6
<geist>
about halfway through 2. totally enjoying it though
<zid`>
the pixel remasters are.. interesting
<zid`>
random things are fixed, random things are still broken, etc
<zid`>
so it's just another "non-authoritative" version to throw onto the pile, sorta?
<mjg_>
is there a stamp of approval from the fanbase?
<mjg_>
so to speak
<geist>
i'm happy with, all in all. there's some youtube series where a guy goes through every single FF and talks about the differences between all the versions
<geist>
very meticulous. but so far the pixel remasters get a +1
<zid`>
ff1 nes nothing works, psx some stuff works but has a 10 second pause screen, gba version is cool but fixes random things etc
<geist>
the pixel remasters are totally authoritative. they're properly done by square and they actually got a bunch of the original authors and music people to revamp the stuff
<zid`>
I like some of the bugs in the NES version a lot though, like the misplaced fire wolves pack
<zid`>
no I mean in terms of being the "ultimate version"
<zid`>
There is still room to make one
<zid`>
They're *all* imperfect
<mjg_>
wow, had no idea there was ff on nes
<geist>
oh yeah. i think probably the biggest overall gist of the remasters is they're closer to the GBA version in terms of difficulty
<geist>
wich is frankly fine. i dont want to grind stuff like i used to have to
<zid`>
nes, psx, gba, pr, wanderswan, etc
<zid`>
yea they're very similar to GBA that's true
<geist>
anyway, so far totally enjoying it
<zid`>
mjg_: there's.. 3 of them lol
<zid`>
1 to 3
<geist>
the fact that i'm enjoying FF2 and it's considered kinda bad is a good sign
<zid`>
ff2 isn't bad it's just weird compared to where they ultimately went with the series
<mjg_>
zid`: i have to coness my nes days were mostly super mario and contra :-P
<geist>
i'm enjoying the levelling aspect of it, though lots of folks hate it
<zid`>
like zelda 2
<geist>
but i also think peoplelike to hate on stuff
<zid`>
only problem with ff1 is the awful encounter rate in mount gulug :p
<geist>
'you can beat yourself p to level that's crazy!'
<geist>
well done do it
<zid`>
It's approximately 50% per step
<geist>
FF2 seems to have a fairly high encounter rate too
<zid`>
does that version delete encounters if you're OP I forget
<zid`>
That appeared in one of the early games in one version briefly I think
<zid`>
where if you were very overlevelled the enemy action was to just flee
<zid`>
which sped up the encounters compared to single-target killing 6 weak wolves
freakazoid333 has quit [Ping timeout: 240 seconds]
<zid`>
I once spent several hours making a 'good' copy of FF6, US base rom, JP/PAL title screen, genji glove fix, sketch fix etc etc
<zid`>
then never bothered to actually play it :D
<mjg_>
journey is the destination
<zid`>
It was in that case yea
<mjg_>
i need to replay the fallout series at some point
<zid`>
fallout 1 I can knock out in a couple of hours
<mjg_>
also never played f3 and newer
<zid`>
fallout 2 gets my compulsions going and I have to religiously follow a guide and it takes forever
<mjg_>
i think speedrun to f1 is 20 minutes(?)
<zid`>
fallout 3 is meh, fallout new vegas is good, fallout 4 is pointless
<mjg_>
they abuse the combat turn bug
<zid`>
yea fallout 1 doesn't have much required stuff
<zid`>
You just need to water chip and blow up a supermutant
<zid`>
and the latter with good routing can be done with planting dynamite or whatever method
<zid`>
high speech, etc
<mjg_>
i remember having a copied save in fallout 2 after the temple
<mjg_>
so that i can start from there should i want to play the game
<zid`>
fallout 2 has just 5x the content density everywhere, every town is PACKED with little lines and you have to pick which to do and keep diving in and out of lines to get all the rewards etc
<mjg_>
killed all the scoprions, fixed the whell
<zid`>
so I just get totally overwhelmed if I don't follow a guide
<mjg_>
what's the first city near the village
<zid`>
fo2? or fo1?
<zid`>
fo1 is shady sands
<mjg_>
i remember i spent hours walking around, i think i did all the quests
<mjg_>
2
<zid`>
fo2 is erm..
<mjg_>
then when i got to the next one i could not be fucked to do almost anything
<geist>
honestly with most of the modern bethesda games i just get fatigue dealing with all the mods
<zid`>
klamath/arroyo
<geist>
i totally dig that they'r emoddable, but then feels like i end up spending all this time and energy dealing with maintaining mods and whatnot it becomes unfun
<zid`>
Only game I've really ever played modded is terraria
<zid`>
and factorio
<zid`>
because people put out entire new games in its engine
<zid`>
single click 'try this game in this engine'
<geist>
oxygen not included is another one of tose. really gest great with mods, but then you have to keep screwing with keeping them up todate
<zid`>
I can't deal with random 40kB mods by the hundreds like some people do
<clever>
zid`: ive been working my way thru a space exploration map in factorio lately
<zid`>
I'm currently playing dark souls inside terraria
<zid`>
and I just beat krastorio in factorio's engine
<clever>
it adds multiple planets to the game, space travel, and resources that you can only find off-world
<clever>
so now you need to setup inter-planetary transport of goods
<geist>
been replaying a bunch of Astroneer again, especially after they released the new rails thing
<geist>
but at this point ive 'beaten' the game before, so it's mostlyu just relaxed tinkering
<geist>
(instead of working on LK and getting stuff done)
<clever>
heh
ajr has quit [Quit: WeeChat 3.6]
<clever>
i cant really say why, but factorio gets a solid 60 fps on my pc, but astroneer gets like 5 fps
<mjg_>
geist: getting stuff done is overrated
<clever>
even when i push factorio pretty hard, it rarely lags
<clever>
ive also dabbled in factorio modding, and its surprisingly limited
<clever>
like, you cant even do something as simple as add the ability to put a circuit network wire on any building
<clever>
only buildings that already natively accept wires can be used
<zid`>
yea but you can just clone the assets and make one
<zid`>
so it isn't *that* big of an issue
<zid`>
it's honestly better for performance that you can't anyway
<clever>
what if i want something that is both a heatpipe, and outputs a circuit network signal?
xenos1984 has joined #osdev
<clever>
i think the only option is to place 2 entities in the same tile, and use some z-order to make sure the player clicks the right one with the wire
<zid`>
no you rip the .png for the pipe
<zid`>
and make a heatpipecircuit/
<clever>
but which entity does it clone, and can it actually conduct heat?
<geist>
hmm, you know theres really no point maintaining the no-mmu variant of the arm64 code on LK
<geist>
that's the least taken path, and actually doesn't compile
<zid`>
Good good
<clever>
damn you!, :D
<clever>
chainload without mmu would be far simpler
<clever>
but then i have to deal with fixing no-mmu :P
<geist>
what do yo umean?
<clever>
the chainload routines on arm64 are missing, and i was having trouble with the cache flush and mmu disable stuff
<geist>
problem is realistically you can't run without the mmu on arm64, since it runs like shit if you do
<clever>
if it was a no-mmu build, that problem wouldnt exist
<geist>
because the data cache stays off
<clever>
but fixing chainload on the mmu is obviously the better solution
<geist>
exactly
<geist>
problem with 'fixing chainload' is really there's not e good solution solution for it
<geist>
what works on one board doens't work on another. my experiene is that every actual use case of it ends up writing its own bespoke version anyway
<geist>
one of the reasons i dont really have one in the tree, because at best it'd act like a TODO list of things for the impl to do
<geist>
which i suppose is probably better than just not implementing anything and not leaving a note
<geist>
so having a 'insert code here' in the tree is basically the defacto solution
<zid`>
TODO: *gestures around vaguely*
<clever>
if i had a working disable-cache routine, i think i could copy/paste the arm32 one into my platform code
<clever>
assuming your own todo-chainload was tagged weak
<clever>
or i could just use my own symbol i guess
<geist>
lots of solutions there
<geist>
or just have it call a weak version of platform_chainload() and then implement it there
<geist>
that's a fairly standard strategy
hello-smile6 has quit [Remote host closed the connection]
vdamewood has joined #osdev
<clever>
having one in the platform code also solves the SMP issue
<clever>
where you didnt want to park multiple cores
<clever>
i can just do whatever i want
<geist>
right. my experience with these things is there are certain bits where its not really possible to build a generic solution for all stuff
<geist>
so in those cases you're sort of better off leaving it as a green field for an implementation to fill in
<geist>
otherwise you end up building some sort of complex overridable generic solution that just adds more boilerplate and complexity
<clever>
that makes the arm32 case a bit weird, that it exists and worked almost perfectly out of the box
Patater has joined #osdev
<geist>
for you
<geist>
and again you are free to try to roll some of these changse back into mainline
<geist>
but i never see output of your branch so i honestly have no idea what you're doing
<geist>
9/10 times it's simply because someone didn't bother to push the changes back
<clever>
i think the only change the arm32 chainload needed, was the fpu stuff
<geist>
and when i know someone is working in a particular area i tend to not futz with it because i assume they'll come up with a patch soon
<clever>
LK disables the fpu when context switching, to trap and lazy context switch it
<geist>
ie, why i stopped workign on ext4 because you said you had patches :)
<clever>
and linux assumes that if the FPU is disabled, it cant ever use it
<immibis>
clever: Last time I looked at factorio, you did make two entities on the same tile
<geist>
and then a year later i still haven't seen them
<immibis>
but that was a decade ago so
<clever>
yeah, i really need to get into that
<geist>
anyway, enough talk, now i do.
<immibis>
I think that's a modding API limitation. Internal code is perfectly capable of having an entity conduct heat and output circuit signals (I think) but because no building type in the basic game does that, it's not implemented
<geist>
gotta stare at some of these early arm64 pulls from a few people, see if i can resolve them
<immibis>
a frequent gamedev pitfall used to be (don't know if it still is; I certainly did this) getting hung up on the idea that each object in the game has to be an object in OOP, then writing your main loop as while(true) {for(thing in world) thing.update(timestep);}
<clever>
immibis: SE has a condenser turbine, that turns steam into water+power
<mrvn>
clever: outputing a circuit signal is done by adding a constant combinator. Reading a circuit signal is the real problem though. There is no way to wait for a change in signals so you have to read it every tick in LUA.
<clever>
immibis: behind the scenes, its a few assemblers and a turbine i think
<immibis>
with that kind of mentality something with lots of objects will never work. What you do want is optimal algorithms and data structures for what's actually in your game.
<clever>
mrvn: yeah, i currently implemented the mod as just a constant combinator, that you place near an existing normal heat pipe
<immibis>
factorio 0.1 did have every conveyor move the items overlapping itself every tick.
<clever>
mrvn: and it then changes its own config
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<immibis>
this mentality applies to OSes too by the way, you want your scheduler to be able to just pull the next ready process from the top of some structure, instead of traversing a bunch
<clever>
yeah, just have a lock protected list, of every runnable thread
<clever>
any time the state of a thread changes, you add/remove it from that list
<clever>
and when making something runnable, that is currently running, you must then context switch out of it, with the lock held
foudfou has joined #osdev
frkzoid has quit [Ping timeout: 240 seconds]
foudfou_ has quit [Quit: Bye]
<mrvn>
clever: if it's already running why wouldn't you just return?
wand has quit [Remote host closed the connection]
<zid`>
prio queue is a simple way to do something like factorio
<zid`>
Just set timers for when their next activity is
<zid`>
so you only ever process inputs in, outputs out
opal has quit [Ping timeout: 268 seconds]
[itchyjunk] has quit [Ping timeout: 244 seconds]
<geist>
hmm, yeah i think i like this 'trap to get to the high address' thing that someone did a pull request for in LK
<mrvn>
a lot of stuff isn't time based.
<geist>
initially i wa sa little iffy but the more i look at it its pretty rock solid
<clever>
mrvn: if you want to give up the cpu, to share it with other threads
<clever>
mrvn: either by force (timer irq) or by choice
<mrvn>
clever: in my code I call move_to_back on the thread.
[itchyjunk] has joined #osdev
<clever>
but now the thread is "runnable", and if you release the lock, its still actually running, if you called that on self
<mrvn>
geist: it avoids the need to have the 1:1 mapping for physical ram just to "jmp start_64"
<geist>
yeah i was worried that it'd break some other code that maybe implicitly relies on the trampoline still being set up when C started
<geist>
but i was confused, the LK code actually already almost instantly clean sup the trampoline page table
<geist>
so actually that's not an issue
<mrvn>
clever: not for me. no thread is running in the kernel. the top of the thread list gets loaded when I exit the kernel.
<geist>
the only real bummer is you have to burn 2k to set up a temporary exception vector thing, unless yo uanna get fancy
<clever>
geist: oh, what about allowing arm64 to run in EL2 or EL3?, as a compile-time selection
<geist>
but that's still better than burning a page for a trampoling page table
<geist>
clever: slow down slick.
<clever>
heh
<clever>
mrvn: ah, thats a very different model from what i'm used to
<geist>
also file a bug request
<mrvn>
clever: yeah. it's when you have no per-process kernel stack.
opal has joined #osdev
<clever>
mrvn: ive only heavily worked on the LK kernel, where you dont even have a process, so every thread is in-kernel
<mrvn>
Does LK have syscalls or does every thread just do function calls?
frkzoid has joined #osdev
<geist>
in the core kernel, the latter
<clever>
mrvn: every thread just does normal function calls
<geist>
user syscalls are a different layer
<clever>
there is an lk-user to create a kernel/user split and syscalls, but its optional
<mrvn>
That should fit the C++ thread model then.
<mrvn>
or coroutines
<mrvn>
coroutines make for a nice cooperative OS :)
wand has joined #osdev
<zid`>
I'm still upset that it's called little kernel which makes me think linux kernel every damn time, instead of small which would not
<geist>
go back and beat some sense into me 15 years ago
<geist>
naming things i am not good at
opal has quit [Remote host closed the connection]
<dh`>
makes me think of the aliens in starcon3, a game better forgotten
<clever>
i still have that problem :P
<clever>
i have a zfs-utils, and a zfs-utils2
<geist>
*frumple*
<clever>
why didnt i just add more utils to the first one?
opal has joined #osdev
foudfou has quit [Remote host closed the connection]
* dh`
goes back to the *playground*
foudfou has joined #osdev
<geist>
yah i think i played starcon3 for a grand total of like 2 hours before being bitterly dissapoint
<mrvn>
clever: Debian has coreutils, moreutils, binutils, ...
<zid`>
I am a *HAPPY CAMPER*
<zid`>
Because I only play UQM
<dh`>
did anyone ever reimplement the starcon1 full game in UQM?
<geist>
funny i was actually replaying Starflight 1 the other day a bit. starflight 1 and 2 are a pretty direct predecessor to starcon 2
<geist>
in the sense that it's basically the same exploration thing and designed by the same people
<geist>
SF1 was one of the first PC games i ever played, and it's still a classic
<zid`>
The tech talk the star control guys gave is great btw
<mrvn>
"They designed the game in consultation with fans, replacing features from Star Control II that received negative feedback. Star Control 3 was considered a critical and commercial success upon release, with praise for its story and varied gameplay. However, the game later suffered from comparisons to the award-winning Star Control II, with a mixed legacy among both fans and critics."
<kof>
it gets better "coreutils, moreutils, binutils" the gnu coreutils used to be textutils and whatever others
<mrvn>
Sounds like the bad things they removed actually made the previous game better :)
<dh`>
don't forget diffutils, findutils...
<kof>
^
<geist>
oh wow. yeah. there's a 2 hour interview with two of the guys
wand has quit [Remote host closed the connection]
<mrvn>
AmigaOS had more and muchmore instead of less.
wand has joined #osdev
<dh`>
erm, you know "more" is the original name, right?
<dh`>
less being a play on it
<dh`>
there was also a "most"
<clever>
less is also more in terms of features, lol
<clever>
more can only scoll down, it acts as a throttle on a pipe
<clever>
less can scroll up, so it has to buffer data and redraw more
<dh`>
bsd more scrolls up, but not on pipes
<dh`>
also I'm pretty sure less also acts as a throttle on a pipe, it's not a misfeature most of the time.
<clever>
dh`: ah yeah, the more on my linux can also scroll up on a file
<dh`>
yeah, that's the one
foudfou has quit [Remote host closed the connection]
<clever>
$ more --version
<clever>
more from util-linux 2.37.2
<dh`>
these days only linux ships that more, all the bsds dropped it in favor of less
foudfou has joined #osdev
<dh`>
not sure if that happened in 4.4 or after
<dh`>
it is terrible code, dropping it was almost certainly the right move, even though less has issues
<dh`>
(I guess it's possible someone has improved the util-linux copy in the past 25 years, but... I doubt it)
<mrvn>
I'm still missing the feature for less to keep scrolling when output happens when you are at the end (or a key for it)
<dh`>
there's some option, dunno about key
<mrvn>
"G" skips to the end. On a pipe it should go to the end and then scroll the output instead of waiting for the pipe to close.
<geist>
oh ugh. the fpu-in-the-kernel is technically rearing its head on arm64 now too
<geist>
thought that was a x86 only problem. ughhhhh
<dh`>
at this point I think we should assume that any lazy context switch is going to eventually be attackable
<geist>
i hadn't seen it before, but seems that gcc 12 is more aggressive about using vector registers on arm64 to do integer stuff, the way x86 compilers have been doing for ages with SSE/AVX
<geist>
problem is i can't just hard disable fpu code on arm64 because -mgeneral-regs-only means the compiler actually hard fails if it sees a float
<geist>
so you end up with this situation where the few places you want to use float cant even compile
<dh`>
joy
<geist>
this is the big downside of having a single kernel binary that mixes kernel code (interrupts/etc that you dont want to use float) and regular application code that just happens to be running in supervisor mode
<geist>
you can't easily separate the two pieces of code with different compilation flags, since they can intermix
<moon-child>
pragmas?
<geist>
what i really want is a flag on gcc that says 'dont use float regs for anything other than float code'
<geist>
but AFAIK there's no such thing
<geist>
yah it's even stricter on arm64 compilers. if you in any way specify nofp, or no simd, it's not that it'll just avoid using it and then revert to using software fallback
<geist>
it'll simply refuse to compile if any floating point code is hit in C
<geist>
in arm32 at least it'll just fallback to software routines
foudfou_ has joined #osdev
foudfou has quit [Ping timeout: 268 seconds]
wand has quit [Remote host closed the connection]
wand has joined #osdev
fastru has joined #osdev
<mrvn>
geist: Does compiling a separate file fail to link with a ABI mismatch error?
<geist>
about to find out
<geist>
implementing a module argument option so particular pieces of the code opt-in to floating point or not
<mrvn>
ON arm32 you can use soft/hard float.
<mrvn>
geist: I more and more want a non-optimizing compiler. But not that crap gcc -O0 produces.
<mrvn>
give me some register allocation but that's about it on optimization
<mrvn>
geist: did you see my godbolt url with the BinaryTree destructor? Just calls itself for left and right child recursively. gcc goes completely bonkers ininlining 3 or 4 levels with hundreds of jumps. clang fits on a screen.
<bslsk05>
vnmakarov/mir - A lightweight JIT compiler based on MIR (Medium Internal Representation) and C11 JIT compiler and interpreter based on MIR (103 forks/1589 stargazers/MIT)
<mrvn>
moon-child: that doesn't look like a C++ compiler
<mrvn>
2 opcodes in both cases and v0.4s has a register dependency
<zid`>
I don't know what a v0.4s is basically
<geist>
i bet the optimization manuals say that the store to the vector is a detected zeroing operation
<zid`>
in order to know why it doesn't count as a general reg
<geist>
ie, mov x0, xzr, etc
<zid`>
so better microps if it does it that way
<mrvn>
geist: so it gets renamed to use the zero reg?
<geist>
probably
<mrvn>
the "copy" case must get you a lot in C++
<mrvn>
every default copy constructor basically
<geist>
zid`: the vector regs in arm64 are fairly well named, though there's an odd overlap between the 'q' and 'v' registers
<geist>
but the gist is the 'q' regsters are named so because they have 4 single precision values in them
<geist>
and they nest nicely: s0 is a 32bit float, d0 is a 64bit float (s0 is the bottom half of d0), and q0 is a double d0, etc
<mrvn>
isn't that v0.4f?
<geist>
yah i think it's something like when you want to use an integer vs float option you have to specify the .N[if] if it's ambiguous
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
but if you're dealing with the bag of bits in the regster you can use the 'q' variant
<mrvn>
should have just allowed "v0" instead of "q0"
<geist>
hence why the load/stores of the q register are typeless. they just store bits
* geist
shrugs
<mrvn>
what bugs me is that the add/mul SIMD opcodes have some wired limits on which register format/size you can use. Some sizes need a different opcode.
<mrvn>
differe memonic I mean
chartreuse has joined #osdev
<mrvn>
damn, I'm debugging inter-thread-messages getting lost in zeromq. I've added some printf debuging and now the message arrives.
<mrvn>
I hate race conditions. Now I have to find where theres some barrier missing.
hello-smile6 has joined #osdev
<zid`>
I am a professional eater
<zid`>
I think I got more of that yoghurt on me than in me
<mrvn>
you're getting paid for it? Otherwise you're just an amateur
hello-smile6 is now known as hello-smile
hello-smile is now known as _9pfs
<dzwdz>
i'm trying to create a freestanding position independent executable, but the linker puts some hardcoded addresses in .data.rel.local
noeontheend has joined #osdev
<dzwdz>
shouldn't it instead generate relocations?
<mrvn>
neither gcc nor clang can create position independent code.
<dzwdz>
then what's the -fPIE flag for?
<mrvn>
relocatable code
<dzwdz>
but then it should create some relocations, right?
<geist>
it should. i dont know what mrvn is being obtuse about here
<dzwdz>
because the elf i'm getting has no relocations
<mrvn>
dzwdz: depending on the flags you get one or more relocation sections added under different names
<mrvn>
check all the sections you have
<dzwdz>
readelf -r says that there are no relocations
<dzwdz>
but lemme check
<geist>
there are a lot of variables in flight here: what compiler youre using, what arch you're targetting, what switches you're setting, what linker you're using, etc
<mrvn>
dzwdz: problem is when you write a global "Foo *foo = &bla;" there is no way for the compiler to make that PC relative. Any address ending up in .data is absolute and needs relocations.
<dzwdz>
yup
<mrvn>
readelf -r --use-dynamic?
<dzwdz>
still nothing
<geist>
another one i've used is the r flag on objdump where it puts the relocations inline
<geist>
so how are yo ucompiling it? what compiler are you using? are you using your own linker script?
<mrvn>
dzwdz: you have PIE there for compile and link?
<dzwdz>
yup
frkzoid has quit [Ping timeout: 244 seconds]
<mrvn>
-static-pie?
<dzwdz>
nope
<mrvn>
I haven't tried -static-pie myself but maybe that puts the relocations into the init_array instead.
<mrvn>
include code to do the relocation instead of some section listing the changes.
<geist>
vtables are another big offender
<geist>
and those can't really be fixed with an init_array
<dzwdz>
i'm using C, so i don't have vtables
<geist>
good
<dh`>
uh, on many targets there's a standard offset from .text to .data so if you have instructions that reach far enough you can have pc-relative accesses to .data
<dzwdz>
-static-pie doesn't seem to change anything either
<mrvn>
dh`: only with -mpic-data-is-text-relative
<dh`>
anyway if you want a bootable pie you'll have to apply the runtime relocations yourself in the startup code
<dh`>
mrvn: which is the default on such platforms IME
<geist>
yah you can reduce the number of times you have to apply it, or carefully avoid them
<geist>
but i think that's not the issue: dzwdz isn't seeing any relocations. of course maybe that's because you dont need them for your particular binary?
<dh`>
if you want an example of a bootable position-independent kernel, barrelfish does this
<mrvn>
dh`: or you have such a large range that you rach everywhere anyway.
<dh`>
though somewhat abusively IIRC
<dzwdz>
i do, that's why the .data.rel.local section is even there
<mrvn>
dh`: with gcc?
<geist>
is there anything in it?
<geist>
may be simply zeroed out
<dzwdz>
nope, there are some e.g. structs i have that have pointers to stuff in .data
<mrvn>
Is .data.rel.local thread local storage?
<dzwdz>
i have no clue what the .local stands for tbh
<geist>
i'd start by seeing what's special about those structures and reverse back why the compiler thinks those need to be there, etc
<geist>
then start there
<dh`>
mrvn: let me put it this way, I have yet to see gcc + binutils emit a GOT entry for a hidden-visibility symbol on riscv
<dzwdz>
but it only contains stuff that has pointers to .data
<dzwdz>
they need to be relocated
<mrvn>
dh`: but does it put absolte addresses in .data?
<mrvn>
dzwdz: that's the ".rel" part :)
<dzwdz>
also, if i go into my linker script and add `. = 255M;` on top
<dh`>
no, but that wasn't what we ere talking about
<dzwdz>
the addresses all get offset by 255
<dh`>
s/ere/were/
<dzwdz>
255M*
<mrvn>
dh`: actually we where. That's what dzwdz has as problem.
<dh`>
well, he said he was getting absolute addresses in relocations
<mrvn>
dh`: anything in the init_array?
<dh`>
also maybe he's not using riscv
<dh`>
though amd64 has a similar property, there's no reason to build a got entry unless the symbol is dynamically addressable
<mrvn>
dh`: the got and plt entries you can eliminate with the right options. That's the easy bits.
<dzwdz>
mrvn: did you mean to tag me with the init_array thing?
<mrvn>
dzwdz: yes, sorry
<dzwdz>
then i have no clue what init_array is lmao
<dzwdz>
but readelf -a doesn't mention it
<mrvn>
dzwdz: the array of initializers you have to run before main()
<mrvn>
dzwdz: .ctors?
<dzwdz>
nope
<mrvn>
section names differ per arch.
<mrvn>
what arch are you even on? :)
<dzwdz>
amd64
<dh`>
dzwdz probably isn't using off the shelf crtstuff, they're trying to build a bootable image
<dzwdz>
yes and no
<dzwdz>
it's freestanding
<dzwdz>
but it's not meant to be bootable, it's meant to be an userland binary for my kernel
<dzwdz>
which is a worthless detail
<dh`>
...then why is it freestanding?
<mrvn>
readelf -t | grep -i rela
<dh`>
that's not a minor detail
<dzwdz>
i meant the userland binary part
<dzwdz>
i don't have a proper libc yet
<dzwdz>
by freestanding i meant that i'm using -ffreestanding
<mrvn>
dzwdz: can't you just link it to a fixed address and worry about it later?
noeontheend has quit [Ping timeout: 240 seconds]
<dzwdz>
that's what i was doing
<mrvn>
ahh, so this is later then :)
<dzwdz>
but now i want to implement elf loading
<dzwdz>
yeah
<mrvn>
Still, ELF has the address it wants to be at in the header.
<dh`>
(a) you don't need or want -ffreestanding for userlevel code, but that doesn't matter
<dh`>
(b) walk before you try to run, first load static elf files
<dh`>
(c) then you'll need a dynamic linker
<mrvn>
dzwdz: I would forget about PIE and work on PIC for dynamic libs first.
<mrvn>
insert TLS somewhere if you want to support that
<dzwdz>
so the reason i want position independent code already
<dzwdz>
is that i want to implement the elf loading in userland
<dzwdz>
so i want to be able to move the loader if it would conflict with the binary that it's going to load
<dh`>
...walk before you try to run
<dh`>
just reject malformed bins to start with
<dzwdz>
there's nothing malformed about a binary that just happens to overlap the memory region that the loader is at
<dzwdz>
if there was, then the loader binary would be malformed
<dzwdz>
by definition
<mrvn>
dzwdz: but you don't have to start with that
<mrvn>
dzwdz: you also have virtual memory I assume. Just load the binary anywhere and then have a tiny function that remaps the bits and calls _start that you write position independent and relocate.
matt__ has joined #osdev
matt__ is now known as freakazoid333
<dzwdz>
how am i supposed to relocate if the linker doesn't create any relocations
<mrvn>
dzwdz: don't have any globals in that tiny function, not static. There should be nothing in there that needs relocation.
<mrvn>
s/not/nor/
<zid`>
if it doesn't, there's nothing to relocate, rejoice
<mrvn>
Should be just a loop calling mremap() a number of times and then calling a void (*_start)(void) [[noreturn]]
<zid`>
what are you dynamically linking against?
<mrvn>
zid`: he is trying to write an elf loader
<mrvn>
ld.so so to speak
<mrvn>
down to 3 fprintf() that change the race condition. Narrowing down where it happens at least.
<dzwdz>
i honestly have no idea what you are talking about
<zid`>
dzwdz: What relocations were you expecting to exist, that don't? You said you made a pic executable but it had no relocations.
<mrvn>
Comment out that fprintf and the code fails, leave it in and it works.
<dzwdz>
OH you're talking about something else, sorry
<dzwdz>
zid`: i have some global pointers to stuff in .data
<zid`>
those don't need relocating unless you do a weird link
<mrvn>
zid`: they do in PIE
<zid`>
you only *need* relocations if you're doing some linking at runtime, i.e .so/.dll
<dzwdz>
why wouldn't they?
<dzwdz>
i don't know their address until the executable is loaded
<zid`>
you know where the instruction pointer is
<zid`>
and you know where .data is loaded relative to .text in a lot of scenarios
<mrvn>
zid`: He has a global "Foo foo; Foo *pfoo = &foo;" in the .data section. "pfoo" needs relocation.
<zid`>
PIC doesn't mean "I randomly reodered the sections in my ELF" necessarily, just that you base your offsetting from the image base / instruction pointer
<zid`>
so you *might* need relocations, if your loader is doing that, but if it's just splatting it after .text then the linker can absolutely figure out what to add to IP
<zid`>
But I've not seen your linker or loader setup
<mrvn>
zid`: he *must* have relocation, he *might* not use them
<dzwdz>
i don't even have a loader yet, so far i just want to get something i can load
<zid`>
did you disassemble it to see what the reference to .data you're interested in looks like?
<zid`>
might be easier than trying to reverse engineer your linker's setup
<mrvn>
dzwdz: keep playing with the linker options. I've seen sections appear and disappear depending on options when I tried to make a PIE.
<dzwdz>
my code is accessing stuff in .data just fine
<zid`>
soo there's no problem?
<dzwdz>
no
<zid`>
I feel like we've gone in a loop
<dzwdz>
the globals which contain pointers to other stuff in .data
<mrvn>
zid`: the addresses in .data itself are the problem. the "pfoo" from above.
<dzwdz>
are in .data.rel.local
<geist>
there's not enough info here for us to help i think
<geist>
we're just getting pieces of the picture, but the details kinda matter
<zid`>
I've yet to find an actual.. problem
<dzwdz>
they need to be relocated - it doesn't matter that the offset between .text and .data is always the same, because the pointers aren't relative to the instruction pointer
<geist>
like i said what i'd do is figure out what is in that section, what the section is for
<geist>
then decide if you still have a problem
<zid`>
yea, initialized pointer values in data will need relocating
<geist>
as mrvn pointed out it might be something to do with TLS, in which case that is a different kettle of fish
<dzwdz>
zid`: and that's where the problem is
<zid`>
but you said the code works fine
<dzwdz>
no
<zid`>
so I'm confused
<dzwdz>
the code accesses .data fine
<dzwdz>
beacuse .data is always at the same offset from .text
<zid`>
but you're getting 0s for your function pointers or whatever?
<dzwdz>
but then the pointers it grabs from there don't make sense
<dzwdz>
not 0s, the linker seems to try relocating them
<dzwdz>
like, when i added `. = 255M;` to the beginning of my linker script, all those pointers shifted by 255M
<zid`>
do they look reasonable as offsets then?
<dzwdz>
yup
<zid`>
add the base address of .data to them then gg? :P
<dzwdz>
isn't that what the relocations are supposed to be for
<zid`>
I meant at load time
<geist>
in circles again
<geist>
again, figure out what is in those sections first, then the picture iwll make sense
<dzwdz>
again, i know what's in there
<geist>
should be able to look at the symbol table and see what structs/etc are going there
<geist>
what is in there?
<dzwdz>
for example, there's a struct in there which points to an array in .data
<dzwdz>
which has a pointer to it, i mean
<geist>
ah. right. okay
<geist>
is the struct something you made?
<dzwdz>
yup
<zid`>
probably that it's within your module
<zid`>
oh whoops wrong channel
<geist>
so there's no obvious reason it's in ....local?
<zid`>
oh it was relevent anyway :D
<dzwdz>
i have no clue why it's in .data.rel.LOCAL
<dzwdz>
but it's in .data.REL because it needs relocating
<geist>
are you sure?
<dzwdz>
because of the pointer in there
<dzwdz>
i'm pretty sure
<geist>
okay. so then as you say the problem is there are zero relocation entries emitted for this binary?
<dzwdz>
its value depends on the address of .data
<dzwdz>
yes
<geist>
okay, so back to a qusetion i had like an hour ago: how are you compiling this
<geist>
what compiler are you using
<geist>
what switches are you using, etc
<geist>
not enough info for us to help without that
<geist>
pastebin the whole damn thing
<geist>
otherwise we're just going to theorize and talk in circles
<geist>
my guess is you're missing some switch/etc that you're probably supposed to be setting that's causing it to generate a nerfed, incomplete binary
<geist>
or (also very likely) there's something you haven't told us that you may not thing is important but is extremely important
<dzwdz>
so about 20 minutes ago i've said that i should probably go to sleep
<geist>
okay, so lets do that then
<dzwdz>
yeah
<zid`>
not that the solution is anything other than
<zid`>
add .data to the entries
<zid`>
at the end of the day
<geist>
no. that's not a solution. the solution is to figure out the problem and then solve it
<geist>
that's a hack
<zid`>
That's what the dynamic linker *must* do
<dzwdz>
yes, but i need to have a list of where these entries are