Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=5&d=10

Friday, 10 May 2019

12:02:16 <doug_16k> to prevent everything being exported, you add -fvisibility=hidden to your compile option, then it will only export things you tag with __attribute__((__visibility__("default")))
12:02:39 <gog> i need to find some symbols from my loader
12:02:42 <doug_16k> I defined an EXPORT macro for that
12:03:16 <gog> and then after the loader is done i don't really need the symbol table
12:03:17 <gog> not yet
12:03:40 <doug_16k> and you can't just pass pointers them to the kernel programmatically?
12:03:52 <doug_16k> pojnters to them*
12:03:58 <doug_16k> ...
12:04:34 <gog> well this particular case is for the kernel stack. i was allocating a stack in the loader and setting rsp before jumping into the kernel entry point
12:05:13 <gog> i could just keep using the laoder stack and set rsp when i get to the kernel entry
12:08:04 <zid> I do mov rsp, ..; jmp main
12:08:16 <zid> I have absolutely no idea where my bootloader's stack lives
12:09:30 <doug_16k> gog, I keep using the loader stack for a few nanoseconds after kernel entry
12:10:00 <zid> I wouldn't know where it is in order to map it, so I don't touch it after the 64bit page table swithc
12:10:17 <zid> which is for like, four instructions anyway
12:19:58 <doug_16k> although I keep "using" the bootloader stack, I don't read or write it, rsp points to it briefly. https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/entry.S#L91
12:21:50 <doug_16k> other cpus use the bottom half of the bootstrap cpu's stack until they get themselves into the threading system
12:22:54 <doug_16k> ...perhaps hundreds of microseconds later
12:30:16 <geist> yah doesn't matter if it's bogus as long as you dont use it
12:38:39 <doug_16k> my bootloader makes life luxurious for the kernel, paging is set up according to program headers + address randomization, physical memory map there, and all memory used by kernel is already used. it can just expect everything to work in the kernel even at the first instruction
12:39:07 <doug_16k> memory used by the kernel is already taken out of free memory regions I mean
12:39:25 <doug_16k> bootloader used the memory map to find pages to put the kernel into
12:39:48 <doug_16k> screw propositions :P
12:42:16 <doug_16k> only sse isn't on by there
12:42:50 <doug_16k> it would have been a lie for it to be on that early, no proper context saving is happening yet
12:44:01 <eryjus> well, that thoroughly sucked!
12:44:33 <eryjus> it only took me 3 days to remember that xadd returns the previous value, not the new value
12:44:43 <doug_16k> x! exchange
12:45:57 <eryjus> well....
12:46:02 <eryjus> i got nothin'
12:46:05 <doug_16k> the instruction name says it all "exchange, add". first it does exchange, but instead of writing the source to the destination it adds the source to the destination
12:46:38 <eryjus> but in my defense, i thought the problem was also somewhere else.
12:46:42 <bcos> It's not an "eXtended ADD?"
12:46:55 <eryjus> lol
12:47:31 <gog> extended adhd
12:47:46 <gog> @doug_16k ye my bootloader does that too
12:47:49 <bcos> (more seriously, Intel did add a new addition instruction recently - something about multi-precision maths and not borking with as many flags)
12:47:55 <gog> i want the kernel to be as blissfully unaware of firmware concerns as possible
12:48:03 <doug_16k> nice
12:48:17 <gog> thus my concern regarding segment headers
12:48:50 <gog> the kernel's job is to schedule tasks and kick ass and it's all out of ass
12:48:56 <doug_16k> bcos, you mean the ones that use OF for the carry?
12:49:07 <doug_16k> so you can have two multiword chains overlapping
12:49:47 <bcos> Yes
12:50:00 <gog> i don't have ASLR yet but i do plan on that being a feature
12:51:07 <bcos> My boot loaders start with PASLR (e.g. randomly allocating physical pages to load kernel, etc into)
12:51:36 <gog> i basically have PASLR but tianocore and qemu has deterministic behavior
12:51:45 <gog> so unless the size of my kernel crosses a page boundary it's usually the same each boot
12:52:02 <doug_16k> you can take specific pages
12:52:13 <gog> one thing at a time lol
12:52:20 <gog> gotta be able to boot again
12:52:34 <bcos> You can initialise your own physical memory manager; and start with things like "RDRAND"
12:52:55 <graphitemaster> bcos, do a Cheney kernel heaps
12:52:57 <gog> it'd be trivial to add that
12:53:04 <gog> with the way i wrote it
12:53:06 <bcos> Cheney kernel?
12:53:08 <gog> (the right way)
12:53:16 <doug_16k> gog, if you get your kernel to compile with -fpie, you've 95% completed KASLR
12:53:32 <doug_16k> the actual relocation step is a breeze
12:53:45 <gog> i don't think i do anything rn that would cause -fpie not to work
12:53:49 <gog> but i don't use fpie atm
12:53:55 <doug_16k> x86-64?
12:54:19 <graphitemaster> bcos, basically, your entire kernel heap is separated into two, you have GC headers on all kernel data structures, on a context switch from userspace to kernel you follow all the references in the one heap that are reachable and copy them into the second heap, then adjust VMMs, ping pong between the two heaps
12:54:31 <gog> -mcmodel doesn't want fpie lol
12:54:33 <doug_16k> if you refer to any global variables in -fpie, and you didn't mention (%rip) then it won't link
12:54:34 <graphitemaster> bcos, the benefit is you don't have to manage memory and it's constantly moving around, really secure ;-)
12:54:37 <gog> -mcmodel=kernel
12:54:42 <doug_16k> in assembly I mean
12:55:31 <bcos> graphitemaster: Heh - already planning something better (but without heap and no GC)
12:55:32 <gog> it linked when i removed -mcmodel=kernel
12:55:32 <bcos> :-)
12:55:34 <doug_16k> position dependent: movq something,%rax independent: movq something(%rip),%rax
12:56:07 <doug_16k> where "something" is a 64 bit variable
12:56:16 <doug_16k> global variable*
12:56:37 <gog> i did have a few of those problems but they were exposed by ld truncating them
12:56:48 <gog> even without fpie
12:57:03 <doug_16k> using proper cross compiler?
12:57:20 <gog> using the one from osdev wiki
12:57:26 <doug_16k> system compiler/linker will force randomization down your throat
12:57:34 <gog> x86_64-elf is the target
12:57:38 <doug_16k> typically
12:58:06 <gog> it's always generated the code it was supposed to whether or not i wrote it correctly lol
12:58:26 <gog> frankly i'm a terrible programmer
12:59:10 <doug_16k> if you load at or above 0xffff'ffff'8000'0000 but below 0x0000'0000'7F00'0000 then it will link no matter what
12:59:25 <doug_16k> I mean, as far as your linker script says about where to load it
12:59:28 <gog> yeah it's in the -2GB territory
12:59:34 <gog> so it's always at that virtual address
01:00:00 <gog> so yeah i guess aslr would require some thinking because if they're more than 2GB apart
01:00:16 <doug_16k> the instructions it used are not all suitable for when it actually randomizes outside that cozy -2GB region, that's why -fpie is needed
01:00:21 <gog> yeah
01:00:30 <gog> i'm grasping that now lol
01:00:35 <doug_16k> it
01:00:50 <doug_16k> 's easy to update the assembly. might need to add a lea here and there
01:01:05 <doug_16k> otherwise just throwing (%rip) on it. I doubt you access that many globals in asm anyway
01:02:34 <gog> none actually except through some inline assembly
01:02:41 <gog> and those use lea's
01:02:57 <gog> mostly they don't touch globals at all
01:03:01 <gog> i have two spots i think?
01:04:41 <gog> yeah anyhow so i'm probably writing a hybridized microkernel i know that sounds like a bold and original decision (jk)
01:04:56 <gog> it just makes sense tho
01:05:46 <gog> things that do a specific thing should be their own thing
01:06:08 <gog> a thing-in-itself; a wonderfully hegelian approach to structuring a program
02:24:38 <gog> ok so my bloviating notwithstanding, what if i need to pass arguments to the kernel? i guess in x86_64 you can use edi and just pass everything in a pointer there which is fine
02:25:12 <gog> which is what i do already i guess but i was using the space allocated for the kernel stack by the loader to store the EFI memory map and some other structures
04:02:29 <doug_16k> gog, I physical identity map the bootloader heap before entering the kernel, and require kernel parameter data to be on the heap. bootloader heap is 4KB aligned after end of bootloader executable until end of contiguous free memory below 1MB. (bootloader is 32 bit)
04:03:07 <doug_16k> then pass pointer as you said, which works now because it is mapped
04:05:03 <doug_16k> same thing is done in uefi case, nothing is below 1MB then most likely
04:05:29 <doug_16k> all the kernel parameter things will work though because I just got a block from uefi and used my own malloc on it, and have that mapped in initial page tables
04:07:09 <doug_16k> everything is guaranteed to be reasonably close to address zero in uefi because it is identity mapped
04:08:51 <doug_16k> it's userspace for 128TB
04:09:16 <doug_16k> then bazillion byte non-canonical region, then kernel space
04:11:01 <doug_16k> point is, there's no way the uefi heap could ever overlap something the kernel needs
04:12:03 <doug_16k> pointers to things at boot can be very non-trivial
04:18:41 <doug_16k> (the one bazillion byte non-canonical region is exactly 16 776 960 TB long)
04:19:16 <doug_16k> as long as people keep it under 16 million terabytes of ram, we should be good
04:19:50 <doug_16k> 0xFFFF800000000000 region immune
04:22:04 <doug_16k> geordi, << pow(2,64)-pow(2,48)/pow(2,40)
04:22:04 <geordi> 1.84467e+19
04:22:17 <doug_16k> geordi, << (pow(2,64)-pow(2,48))/pow(2,40)
04:22:18 <geordi> 1.6777e+07
04:22:32 <doug_16k> geordi, << setprecision(8) << (pow(2,64)-pow(2,48))/pow(2,40)
04:22:33 <geordi> 16776960
04:22:54 <doug_16k> geordi, << setprecision(8) << (pow(2,64)-pow(2,48)) / pow(2,40) << "TB"
04:22:54 <geordi> 16776960TB
04:24:00 <doug_16k> geordi, << (cout.imbue(locale("")) << setprecision(8) << (pow(2,64)-pow(2,48)) / pow(2,40) << "TB"
04:24:00 <geordi> error: Unexpected end of request. Expected ')' or balanced code.
04:24:08 <doug_16k> geordi, << (cout.imbue(locale("")),"") << setprecision(8) << (pow(2,64)-pow(2,48)) / pow(2,40) << "TB"
04:24:09 <geordi> 16776960TB
04:24:17 <doug_16k> geordi, << (cout.imbue(locale("")),"") << setprecision(8) << fixed << (pow(2,64)-pow(2,48)) / pow(2,40) << "TB"
04:24:17 <geordi> 16776960.00000000TB
04:24:33 <doug_16k> geordi, << (cout.imbue(locale("")),"") << setprecision(8) << fixed << int((pow(2,64)-pow(2,48)) / pow(2,40)) << "TB"
04:24:34 <geordi> 16776960TB
04:24:44 <doug_16k> geordi, << fixed << int((pow(2,64)-pow(2,48)) / pow(2,40)) << "TB"
04:24:45 <geordi> 16776960TB
04:25:50 <doug_16k> geordi, << (pow(2,64)-pow(2,48)) / pow(2,40)) << "TB"
04:25:50 <geordi> error: Unexpected `)` after `pow(2,40)`. Expected balanced code or end of request.
04:25:58 <doug_16k> geordi, << (pow(2,64)-pow(2,48)) / pow(2,40) << "TB"
04:25:58 <geordi> 1.6777e+07TB
04:26:06 <doug_16k> geordi, << setprecision(8) << (pow(2,64)-pow(2,48)) / pow(2,40) << "TB"
04:26:06 <geordi> 16776960TB
04:26:46 <doug_16k> oops, dammit I was supposed to be doing /msg. sorry
05:41:58 * bcos sighs
05:42:24 <adu> hi bcos
05:43:00 <bcos> ..just spent 2 hours single-stepping through the UEFI firmware in virtualbox to find out that "stack aligned on 16-byte boundary" really means "stack deliberately misaligned on 16-byte boundary + 8 bytes for the return RIP"
05:43:04 <bcos> Hi :-)
05:44:06 <adu> I just spent 3 days trying to understand DUET
05:45:39 <zid> bcos: Yea I had a hard time finding out which way around that was supposed to be for amd64 when I first tried to mess with it
05:45:46 <zid> whether the 'call' was supposed to align the stack or misalign it
05:47:38 * bcos made sure stack was aligned *after* the CALL, and that worked fine for ages so I thought it was right. Then today I learnt the exception handlers in OVFM are shit and just go into an infinite loop when you GPF.. :-)
05:50:27 <zid> You can't even logic it out, someone has to subtract 8. You can't say "well the caller will want his stack aligned so he can mess with sse, so the call has to align" but then your call will misalign
05:50:53 <zid> (when you call your children)
05:53:27 <bcos> Logic works wrong - when caller has to supply 32 bytes of shadow space and has to "sub rsp,32" anyway, it makes more sense to "sub rsp,32+8"
05:53:50 <bcos> ..so callee gets an already aligned stack
05:54:19 <zid> oh it's windows calling convention under uefi I guess, so yea shadow space too
05:54:41 * bcos nods
05:55:08 <zid> windows convention is fucking dumb as arseholes if you ask me
05:56:06 <bcos> It's horrible for assembly (especially when you do your own thing with no calling convention). I'm slowly burying UEFI's functions under wrappers
05:56:43 <zid> Like, the design seems to assume we're all using compilers, but not ones clever enough to spill registers properly
05:56:44 <zid> it's very strange
05:58:34 <zid> I wonder if there's a satisfying reason somewhere in some deep internal microsoft document
05:58:48 <zid> because I'm not seeing it from the outside
05:58:54 <bcos> I guess I should be glad it's a bug in my code this time (easy for me to fix)
05:59:42 <zid> yea that's what I hate about using complicated blobs of other people's code
05:59:53 <zid> I couldn't imagine being the person responsible for shipping a working project in PHP or something :P
06:00:56 <zid> Like, what do you do if a maint release that fixes a security bug, also makes some other function super slow
06:01:04 <zid> (which you rely on)
06:01:39 <bcos> That's easy - you blame someone else :-)
06:26:17 <bauen1> bcos: there are some other places (not UEFI) that also say "stack aligned on 16-byte boundary", but don't really mean it (iirc posix has this too); really annoying :D
06:28:52 <bcos> Things like this don't help: https://stackoverflow.com/questions/52615235/is-the-microsoft-stack-always-aligned-to-16-bytes
06:29:11 <bcos> ("The CALL instruction pushes an 8-byte return address on the stack, so the calling program must subtract 8 from the stack pointer, in addition to the 32 it already subtracts for the shadow space.")
06:31:12 <zid> It should be written with the word 'before' somewhere, to be clear
06:31:19 <zid> wtf does 'when calling' mean
06:32:54 <bcos> When I read that the first time, I thought "caller must subtract an extra 8 (in addition to the 32) before calling" because after the call the caller isn't doing anything
06:33:37 <bcos> ^ should really be "callee subtracts another 8 in prologue"
06:35:19 <zid> oh that's what it's trying to say, wow
06:35:20 * bcos wonders how many GiB of RAM is consumed for this alignment and shadow space crap (on average) on his Windows machine
06:39:36 <bcos> Of course to make everything "nicer" all of UEFI's functions return a status, and the calling convention can't handle returning multiple things so every actual output parameter is an input pointer
06:40:46 <bcos> ..so I'm doing stuff like "sub rsp,4; mov rcx,rsp" and then "pop rbx" in wrappers so I can return output parameters in registers like any sane person would hope for ;-)
06:41:08 <bcos> *sup rsp,8"
06:41:14 <bcos> Sigh - typos
12:49:55 <stisl> hi
12:51:58 <stisl> I think I have to instrument my scheduler, because something is blocking my scheduler. For this I need another timer /counterwhich can count the instructions per second or sth. like this so that I can figure out which task is blocked. Which timer/counter could be simple enough for doing this?
12:53:40 <stisl> A watchdog could be also ok
12:57:32 <stisl> Currently I have a Jitter from 10.000 khz up to 2 Seconds which is too much
02:16:30 <eryjus> stisl, i have something similar going on. in my case i have narrowed it down to delayed reschedules but i have not yet been able to put my finger on the real problem. but I am very much interested in your findings as you go
02:44:28 <stisl> eryjus, I will inform you
02:44:47 <stisl> especially when I found a solution
02:47:56 <stisl> eryjus, do you also have the problem only on the real machine and not in the emulator?
02:56:02 <stisl> so I will try first to slowdown my scheduler to 1000 Hz, on an embedded machine 10.000 Hz is possible, but I don't know if a PC can handle this
03:22:41 <eryjus> stisl, i have not been able to debug on real hardware yet. I know it triple faults before the scheduler, but I have not yet taken on that debugging effort as I do not have a serial cable that will work -- gotta get to Fry's and make one...
03:39:26 <doug_16k> eryjus, I use a null modem cable
03:39:41 <doug_16k> you can get those premade
03:41:55 <doug_16k> they have rx/tx, rts/cts, dsr/dtr crossed over so it works in two computers
03:43:38 <doug_16k> a bunch of crap comes out at boot on my setup. must be the bios sending something I guess. I gotta try a few different baud rates and see if I can make sense of it
03:44:29 <doug_16k> after the initial burst of garbage it is fine though
03:44:45 <doug_16k> has anyone seen text coming out of the bios on their serial?
04:16:04 <eryjus> doug16k, i have to look for a serial db9 to usb... the only one i have connects to the GPIO pins of the rpi
08:33:18 <Vercas> So I've got some code that doesn't really seem to want to work.
08:33:26 <Vercas> And GCC is completely fucking it up.
08:33:39 <Vercas> I've disassembled it and the shit I'm seeing makes no sense.
08:33:53 <Vercas> https://gist.github.com/vercas/327d4c94ed1131bed7545856805ff13d
08:34:18 <Vercas> Last line in the disassembly page faults. It hits a guard page which is right before the SchedulerData that belongs to this core.
08:34:28 <Vercas> (I use TLS for per-core data, FWIW)
08:35:42 <Vercas> It seems to defenestrate all the logic in GetNext and SchedulerData::Pop and go straight for SchedulerQueue::Pop...
08:37:11 <Vercas> Scheisse, noticed a bug.
08:41:42 <Vercas> That didn't fix it. :(
08:42:42 <zid> keep finding taht ub
08:42:46 <doug_16k> Vercas, loading from this->first page faults?
08:42:59 <Vercas> doug_16k: Yes.
08:45:03 <doug_16k> what is 'this' at that line? thread object?
08:45:44 <Vercas> A SchedulerQueue, part of SchedulerData.
08:45:55 <Vercas> You've got line numbers there.
08:46:01 <Vercas> The code is under the disassembly.
08:46:30 <doug_16k> meant disassembly line 184
08:47:08 <Vercas> Yes.
08:47:17 <Vercas> It refers to line 75 of the file below it.
08:49:49 <doug_16k> how sure are you about all those linked list operations? :)
08:50:01 <Vercas> In GetNext?
08:50:22 <geist> yah this is a bit hard to sort out
08:50:23 <doug_16k> line 84 thru 166
08:50:38 <Vercas> Oh.
08:50:59 <doug_16k> it would explain it going off rail right?
08:51:04 <Vercas> But those don't even appear in the disassembly, the instructions aren't reached.
08:51:05 <doug_16k> at that deref
08:51:14 <Vercas> But the dereference is before all that.
08:51:41 <geist> my brain is not parsing stuff like line 216 in the source
08:51:47 <geist> assert(foo)((something else))
08:51:59 <Vercas> That something else just prints extra parameters.
08:52:12 <geist> ah
08:52:19 <doug_16k> ya I saw other function like tricky things in asserts too
08:52:41 <Vercas> It's just shorter to type this way. The implementation uses recursive macro trickery...
08:52:44 <doug_16k> I assume it is doing something cool
08:52:51 <geist> ah
08:53:19 <Vercas> I plan on ditching the recursive macro shenanigans at some point later.
08:53:25 <Vercas> But it lets me type quick assertions this way.
08:54:28 <doug_16k> Vercas, what is the value of the this pointer register at the ->First crash?
08:54:47 <doug_16k> at first I assumed null but realized maybe not
08:54:50 <Vercas> CR2: FFFFFDFFFFCF8D50
08:55:00 <doug_16k> does that sound about right to you?
08:55:04 <geist> maybe a few asserts in that queue class to see if it gets off in the weeds
08:55:07 <Vercas> As I said, it hits a guard page which is right before the SchedulerData structure for this core.
08:55:35 <geist> hmm, perhaps some sort of negative index off an array?
08:55:41 <Vercas> FFFFFDFFFFCF9010 is where the SchedulerData starts.
08:55:47 <Vercas> Definitely.
08:55:59 <Vercas> + an offset
08:56:05 <geist> might want to double check that bitmap logic, make sure it computes all the right offset
08:56:31 <Vercas> Well here's the thing.
08:56:35 <geist> maybe roll up somoe of the bitmap stuff into some helper routines
08:56:36 <Vercas> I can't see it in the disassembly.
08:56:44 <Vercas> It literally skips all of it.
08:57:00 <doug_16k> in gdb you mean?
08:57:20 <Vercas> No? objdump is what I used to disassemble.
08:57:22 <doug_16k> I've seen gdb strangly omit inlined stuff
08:57:25 <doug_16k> oh
08:58:14 <Vercas> God I hate GCC's optimizations.
08:58:19 <Vercas> I most likely have UB somewhere.
08:58:24 <doug_16k> I doubt it is the compiler's fault
08:58:32 <zid> >keep finding that ub
08:58:33 <zid> :P
08:58:36 <Vercas> It could at least fucking tell me where it finds UB.
08:58:43 <geist> same. usual rule is if you think it's the compiler fault you're almost overwhelmingly wrong
08:58:55 <Vercas> I was right before when I blamed the compiler.
08:59:08 <geist> sure, but every one is a new thing
08:59:12 <Vercas> Now I only blame it for not reporting UB.
08:59:24 <Vercas> Popping 0|18446744073709551584
08:59:25 <geist> well, sounds like you've convinced yourself what the problem is
08:59:29 <Vercas> .............
08:59:52 <Vercas> That stupid number is `highestPriority`
09:00:17 <doug_16k> max unsigned long?
09:00:35 <Vercas> That should be an odd number.
09:00:42 <Vercas> Wait.
09:00:44 <Vercas> I am a moron.
09:00:52 <Vercas> size_t highestPriority = 31UL - __builtin_clzl(this->Bitmap[bitmapIndex]);
09:01:03 <doug_16k> 63
09:01:03 <geist> i was just looking at that line
09:01:05 <Vercas> That 31 should be (sizeof(size_t) * 8 - 1)...
09:01:11 <doug_16k> yes
09:01:26 <geist> again, you should wrap all of those computations into some helper functions
09:01:26 <doug_16k> I have helpers for that
09:01:52 <doug_16k> get it right once and for all. you need ceil(log2(n)) all the time
09:02:00 <Vercas> Okay, making progress. Now dereferencing a null pointer.
09:02:20 <geist> i'm having a hard time following this because it'e extremely out of my code style
09:02:23 <doug_16k> clz is different but you need the other way a lot
09:02:37 <geist> also remember clz is i think undedefined for zero
09:02:51 <Vercas> geist: Yes, that's why two lines above it I check if it's != 0.
09:02:55 <geist> ah yes
09:03:15 <Vercas> GCC can't use the flags from BSR.
09:03:18 <Vercas> :l
09:03:26 <Vercas> It sets the zero flag when it's zero.
09:03:28 <geist> there's a ffs that does what you think
09:03:28 <doug_16k> use inline asm
09:03:35 <Vercas> Nah, this is good enough.
09:03:43 <geist> only difference is ffs has a defined 0, and everything is scooted over once
09:04:10 <geist> i tend to use builtin clz because ARM has precisely that instruction
09:04:29 <geist> though you can also use builtin ctz which tends to do the 31-foo stuff for you
09:04:34 <Vercas> Fuck GCC.
09:04:40 <doug_16k> there is "=@ccz" (is_zero) to get condition code output from inline asm. it may optimize it poorly though
09:04:41 <Vercas> ffffffff800284c0: 48 c7 04 25 10 00 00 00 00 00 00 00 mov QWORD PTR ds:0x10,0x0
09:05:00 <Vercas> doug_16k: I use that in some places, it understands it just fine.
09:05:08 <Vercas> It just doesn't understand it for the builtin. :(
09:05:28 <geist> are you sure that's not just pre-linked unrelocated stuff?
09:05:45 <zid> yea that's what relocations tend to look like
09:05:46 <doug_16k> absolute references are horrible on x86_64
09:05:47 <geist> that looks fine to me, if you're doing an access to something 0x10 off a global
09:06:03 <Vercas> No it's not a relocation, that's how GCC breaks code on purpose.
09:06:11 <geist> seriously, cut it out
09:06:22 <geist> if you're convined the compiler is out to fuck you then go find another job
09:06:23 <Vercas> Been seeing code like that since I upgraded to GCC 6...
09:06:30 <doug_16k> absolute refs will bloat up to SIB encoding and put a 32 bit immediate
09:06:42 <geist> that almost assuredly is fine you're just not interpreting it right
09:06:54 <doug_16k> the linker believes something is at 0x10
09:06:57 <Vercas> geist: But I found code like that where I had UB before!
09:07:10 <geist> fine.but that doesn't mean *every* weird thin gyou see forever more is the same thing
09:07:16 <zid> I mean, it's not a useful comment, but, don't have UB?
09:07:17 <geist> that sort of thinking will absolutely blind you
09:07:27 <Vercas> zid: I am trying to get rid of UB...
09:08:03 <geist> i seriously doubt thats what it is, but sounds like you've convinced yourself otherwise and i have no interest in arguing with you
09:08:13 <doug_16k> imagine how big and complex gcc itself is, or some browser. how could they compile and a few linked list manipulations are beyond it
09:08:33 <zid> parse error
09:08:34 <doug_16k> a significant portion of that code is linked list stuff. very easy to get wrong
09:09:04 <Vercas> Last time I fought the compiler, this thing kept emitting an SSE instruction in my kernel to zero out a register, for no damn reason.
09:09:25 <doug_16k> reason is operator error. operator failed to specify -mgeneral-regs-only
09:09:26 <geist> again. if you had a bad day once and now you're convinced its out to get you that is not helpful
09:09:45 <zid> I bet it was some clever anti-stall code that you'd never in a million years figure out by hand
09:09:51 <geist> furthermore it's highly frustrating to folks trying to help you
09:09:51 <Vercas> doug_16k: Really, mate? I've been working on this thing since 2015, you'd think I'm not THAT lucky...
09:10:19 <Vercas> geist: You seem to think I'm blaming the compiler for my code not working.
09:10:21 <doug_16k> the compiler will auto-vectorize things here and there if you don't ban the fpu
09:10:27 <geist> right, using SSE instructions to zero out stuff is extremely common
09:10:34 <geist> you have to make sure you tell the compiler to absolutely not use it
09:10:44 <geist> clang is even worse, it'll drop sse at a drop of a hat
09:10:47 <Vercas> doug_16k: geist: I used every single compiler option I could find to forbid FPU/SSE stuff.
09:10:54 <geist> then you didn't find the right one
09:11:10 <geist> it is absolutely 100% possible to ban fpu/sse stuff
09:11:27 <zid> gcc helpfully actually errors if you disable sse 'slightly' and it has to use it
09:11:28 <doug_16k> -mgeneral-regs-only shuts it off altogether on x86
09:11:32 <zid> rather than just emitting it and exploding
09:11:37 <geist> same on arm64
09:11:42 <doug_16k> if you try to use it it will error
09:11:54 <zid> so if you use -mno-sse and attribute((interrupt)) it'll error and tell you to use -mgeneral-regs-only etc, it's great
09:11:54 <geist> arm64 its just stops and says 'i can't do what you want'
09:12:19 <Vercas> I understand.
09:12:50 <Vercas> Found my UB.
09:12:54 <zid> hoorah
09:12:57 <geist> woot
09:13:18 <geist> once yo do find it, then the question is is there a warning that would have covered it
09:13:18 <Vercas> Well, some UB. Not sure if this is all of it. :P
09:13:38 <doug_16k> https://godbolt.org/z/hlH3gX
09:14:00 <geist> my experience is general is that UBs on both gcc and clang almost always result in a UB2 or a BKPT, which though is shitty and i hate it, at least can be easily spotted
09:14:03 <Vercas> Great, now I advanced from page faults to indefinite looping. :D
09:14:06 <geist> or at least the really hard UBs
09:14:25 <doug_16k> being difficult to debug is what makes it so much fun right?
09:14:32 <Vercas> geist: From my experience, GCC 6.2+ emits mov instructions to bogus addresses.
09:14:43 <geist> i have never ever seen that in my life
09:14:45 <doug_16k> why so old?
09:14:48 <Vercas> Like ds:0x10 there
09:15:08 <geist> that makes zero sense whatsoever. if it were to intentionally emit a bgosu load why isn't it 0?
09:15:13 <Vercas> doug_16k: I patched a few versions of GCC since 5.3 and later.
09:15:17 <geist> that really really looks like a pre-linked relocation entry
09:15:29 <Vercas> I've compiled my code, debugged, and disassembled with all of them. :l
09:15:38 <geist> are you absolutely 100% positive that's not the case? how about objdumping with the rel entries interspersed? it's a neat flat
09:15:38 <Kazinsal> I was gonna say, that looks bogus but intentionally bogus in a specific manner like a reloc placeholder
09:15:59 <Vercas> geist: That instruction is gone now, man.
09:16:07 <geist> -r
09:16:20 <geist> yes, but you didn't really get to the bottom of it
09:17:45 <Vercas> No relocations.
09:17:49 <geist> so it's frustrating for us, because you've dangled a problem and then taken it away
09:17:57 <Vercas> Lemme try something.
09:18:01 <Vercas> I'll break the code again.
09:18:15 <geist> right, if you fix the code you *must* understand why
09:18:22 <geist> or you'll just make the same mistake again
09:19:02 <Vercas> ffffffff800284c0 <(anonymous namespace)::SchedulerTick(SchedulerData*) [clone .cold.0]>:
09:19:02 <Vercas> _ZN12_GLOBAL__N_113SchedulerTickEP13SchedulerData():
09:19:02 <Vercas> /home/vercas/repos/Beelzebub/beelzebub/src/scheduler.cpp:205
09:19:02 <Vercas> ret->Scheduler = nullptr;
09:19:02 <Vercas> ffffffff800284c0: 48 c7 04 25 10 00 00 00 00 00 00 00 mov QWORD PTR ds:0x10,0x0
09:19:16 <zid> it thinks ret is 0 then
09:19:20 <Vercas> No relocation, and it's exactly the line where UB is. `ret` can be null.
09:19:33 <zid> or rather, it has via analysis, proved it's either 0 or UB
09:19:35 <zid> so it's just 0
09:19:50 <Vercas> It knows it *can* be 0.
09:19:57 <zid> It knows it has to be 0, by the look of it
09:20:05 <zid> because it would have invoked UB if it were not.
09:20:14 <geist> yah
09:20:17 <Vercas> Mate, it branches there.
09:20:29 <geist> dunno you only pasted a piece of it
09:20:30 <zid> Consider like, if(ret) ret = UB(); ret->blah = 12;
09:20:37 <Vercas> It branches to that when another function finds a null pointer.
09:20:38 <zid> it *knows* ret is 0 there
09:21:10 <Vercas> Line 77 in my gist.
09:21:27 <Vercas> If the condition passes, it jumps to that instruction.
09:21:59 <Vercas> So in that case, yes, it is UB. But it knows it's not UB 100% of the time.
09:22:39 <Vercas> God I wish it gave me an error or a warning or something.
09:22:52 <zid> what version of gcc is this out of interst
09:23:12 <geist> yes but isn't this near 195 where you computed a bitmap index wrong potentially?
09:23:23 <geist> maybe it decides that the this->Queue[] you're popping from is garbage
09:23:40 <Vercas> The queue seems to be fine now. o.o
09:23:43 <geist> all in all this is somewhat dodgy code
09:23:47 <geist> really need to tighten it up
09:23:58 <Vercas> zid: 8.3.0
09:24:06 <Vercas> I should patch 9.1.0... :(
09:24:39 <Vercas> geist: Yeah, I've basically been writing it bit by bit every morning when waiting for my breakfast to cook or heat up. :P
09:26:02 <aalm> oh, morning code
09:26:04 <aalm> .theo
09:26:04 <glenda> You can decide what you do with your time, but you cannot decide what other people do with theirs.