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=8&d=13

Tuesday, 13 August 2019

00:00:07 <zid`> I have ints named pml4 pdpte etc
00:00:13 <zid`> for decoding address bits into
00:32:03 <griddle> `#define pti(va, i) ((((u64)va / 0x1000) >> (9 * i)) & 0777)` thats a scary macro
00:32:13 <griddle> the index into the ith page table
00:32:25 <heat> why are you using octal
00:33:03 <griddle> because its 9 bits, and octal is nice for sets of 3
00:33:29 <griddle> its what, `0x1ff` in hex?
00:33:44 <heat> octal is awful for everything
00:33:50 <heat> hex4lyfe
00:34:00 <griddle> base64 when
00:34:11 <griddle> `AA==`
00:34:29 <heat> sha512 when
00:34:43 <heat> 6EC26FA77CDDD42FDC32201B48B1654809DB753FB81E4BA8A2D758A2A8F6569422B7920DB7B3842AF12289F06CCEE171401CCC87820D739ABF68E80BADE2F077
00:35:13 <griddle> octal is great only for sets of 3, and the pdp11
00:35:30 <griddle> hex for sets of 4
00:36:10 <griddle> it still amazes me that they crammed the entire file permission system of linux into 16bits
00:36:27 <heat> because they didn't
00:36:41 <heat> lookup ACLs
00:37:03 <griddle> oh well yeah ext has gid and uid, nvm
00:37:41 <heat> ext4 does have proper ACLs too
00:37:49 <heat> or extended attribute or whatever they call it
00:37:55 <heat> attributes*
00:48:22 <griddle> does the page size bit mean anything on 4k pages?
00:48:59 <heat> I think it's marked as available in PTEs
00:49:01 <zid`> there isn't one
00:49:11 <zid`> it's PWT or something isn't it or PAT
00:50:02 <heat> it's PAT
01:02:42 <griddle> https://pastebin.com/raw/f3Zjw2Gd I think I over-engineered this, and its going to bite me in the ass - its great.
01:06:10 <mrvn> griddle: learn C99
01:06:34 <griddle> ?
01:06:53 <mrvn> uint64_t, intptr_t
01:07:19 <mrvn> PRIu64 or %p
01:08:25 <mrvn> I would also recommend putting physical addresses in a struct so they can't be confused with virtual addresses
01:10:03 <mrvn> looking up switch/case might also help
01:10:56 <mrvn> if you define proper types for va and pa you can make them have page size alignment naturally.
01:10:58 <griddle> why would I use switch case there?
01:11:13 <mrvn> because size can't be both large and huge.
01:13:06 <mrvn> u64 ind = ((u64)va / 0x1000) & 0777; is wrong for large/huge pages.
01:13:32 <mrvn> why don't you use the pti macro there?
01:15:00 <griddle> pti(va, depth) is better
01:15:06 <mrvn> // this is some spooky math, but look at the PN_INDEX macros at the
01:15:09 <griddle> yeah I added the pti macro after the fact
01:15:11 <mrvn> What PN_INDEX macro?
01:15:42 <griddle> i literally just refactored this, didn't delete the comment. gimmie a break
01:15:48 <mrvn> hehe
01:15:59 <mrvn> That also explains if (table[ind] & 1) {
01:16:25 <griddle> there used to be a panic about remapping in there
01:16:33 <griddle> not sure if I should allow that or not
01:16:41 <heat> mapping over?
01:16:55 <mrvn> You could allow it if the pa is the same. Or you have to free the old pa.
01:17:26 <griddle> the way I want to get this map function working is you can set flags to not contain the present flag, and it acts like an unmap
01:18:05 <mrvn> I would make a sub function that returns the table and index. Then make functions for mapping, unmapping and remapping.
01:18:48 <griddle> what if I just call this function `modify_mapping`
01:19:45 <mrvn> When swapping people also put "dev:block:0" in the entry. Because if not present all oter bits are available and make for a fast lookup of where the page is swapped to.
01:20:16 <mrvn> griddle: don't forget to also have a read_mapping.
01:20:24 <griddle> ah, thats true
01:20:40 <griddle> okay, then Ill make a function for find_mapping, and have it return a pointer to the entry
01:20:43 <mrvn> Hence the sub function to do the page walk common to all the functions.
01:20:49 <mrvn> nod
01:21:43 <mrvn> So far the code looks rather compact. You should have seen the monster I made in C++ with a template PageTable class with the level as one argument.
01:22:08 <griddle> yeah I was thinking of doing that, but then thought against it
01:22:16 <griddle> cause I already had this, but exclusively for 4k pages
01:23:47 <mrvn> PageTable<level> is an array of PageTableEntry<level> structs that have a method returning a PageTable<level-1> unless level is already the bottom and so on
01:25:05 <mrvn> Lots of proxy classes too
01:25:39 <mrvn> So in conclusion: No, I don't think your code if over designed.
01:25:46 <mrvn> s/if/is/
01:27:05 <mrvn> Do you have all physicall memory always mapped in the kernel? Or how does your p2v macro work?
01:28:00 <griddle> basically offsets the addresss by 23TB
01:28:14 <griddle> where physical memory is mapped with 1gb pages
01:28:44 <mrvn> Odd number. Would have used 16 or 32.
01:28:50 <mrvn> or 24
01:28:58 <griddle> actually, i think I pulled the number out of my ass, its not 23tb
01:29:24 <griddle> `#define KERNEL_VIRTUAL_BASE 0xffffe90000000000`
01:29:52 <mrvn> So, -23TB or so then
01:30:12 <griddle> yeah
01:31:00 <mrvn> One of the PML4 slots with the level 3 table then mapping 1GB pages. Did you check the cpu features that is has 1GB pages?
01:31:17 <griddle> I will
01:31:35 <griddle> and if I dont have it, use 2mb
01:31:50 <mrvn> yeah. Those you always have.
01:32:29 <griddle> so Im thinking of mapping all the physical memory with 1gb pages or whatever, then having the kernel heap live after that mapped with 4k or 2mb pages
01:32:37 <griddle> probably 4k
01:32:55 <mrvn> do you need a kernel heap?
01:33:13 <griddle> I use alot of lambdas for callback
01:33:26 <mrvn> that will fragment horribly.
01:33:58 <griddle> yeah, probably
01:34:16 <heat> don't lambdas use the stack?
01:34:25 <mrvn> You should use pools for objects of small sizes like 16, 24, 32, 48, 64 bytes.
01:34:38 <griddle> I ported dlmalloc
01:34:43 <heat> 1) don't do that
01:34:46 <heat> 2) don't do that
01:34:46 <griddle> oof
01:34:46 <mrvn> heat: no, then you couldn't return them
01:35:00 <heat> mrvn: you can return them by value
01:35:24 <griddle> ported cause im lazy, and also was checking if my own allocator was the problem and not my paging system
01:35:30 <mrvn> heat: if they don't allocate then yes
01:35:35 <heat> using a slab allocator for malloc is a bad idea and using dlmalloc is even worse because it's really crappy to debug
01:35:49 <mrvn> heat: why not have slabs?
01:36:06 <heat> your slab allocator will not be as fast as a proper malloc implementation
01:36:17 <heat> and a proper malloc supports more sizes than those
01:36:18 <mrvn> heat: no, it will be much faster
01:36:47 <heat> err, not sure where you're getting your slabs that it's much faster
01:37:07 <mrvn> heat: you are right. it will be just the speed of malloc because that's what my malloc uses.
01:38:52 <geist> oh dlmalloc is fine, just dont expect to debug it
01:39:12 <mrvn> heat: What is slow in a slab? The slab has a pointer to the next free object. It returns that and sets the next_free to obj->next;
01:39:37 <heat> hmm, you're right
01:39:48 <heat> but I still prefer the scalability of a malloc
01:40:01 <heat> where it lets you allocate loads of shit
01:40:05 <mrvn> heat: some book keeping to count the number of free and allocated objects if you like but that hardly slows it down.
01:40:40 <mrvn> heat: In kernel you only need a fixed number of small sizes. Then for anything lager you allocate whole pages.
01:42:33 <mrvn> I actually don't have a heap in kernel at all. Every subsystem that needs to malloc has to make a slab or work in pages.
01:43:11 <griddle> hey do you guys run into stack smashing errors ever?
01:43:37 <heat> mrvn: hmm
01:43:50 <griddle> because I commonly have errors where the return address is the base pointer, and it causes an invalid opcode fault
01:43:51 <heat> I've always used malloc because well, that's what you use in user programs
01:44:45 <mrvn> heat: even there a good malloc will use buckets for objects of similar size to limit fragmentation
01:46:29 <griddle> are structures like vectors not commonly used in kernels?
01:46:44 <mrvn> heat: Also: A trivial malloc will have a prev/next pointer for every allocation. That adds 16 bytes overhead for each object. So for lambdas with one argument (16 bytes) that's 100% overhead. A slab will just use a fixed amount for the metadata of the slab and waste nothing per object.
01:46:46 <heat> I use them commonly
01:48:47 <mrvn> Anything that needs random access will be a vector
01:49:10 <mrvn> or tree if you need to be able to insert in the middle
01:49:10 <griddle> well, dynamically resizing structures
01:49:47 <heat> I'm searching but I really can't find a source for the heap allocations with lambdas
01:50:00 <griddle> std::function maintains a heap copy
01:50:07 <heat> std::function is crap
01:50:18 <griddle> because of type erasure or whatever
01:50:21 <heat> std::function is not something you should use, especially in a kernel
01:50:29 <heat> it's really heavyweight
01:50:43 <griddle> yeah... I know
01:50:50 <heat> I'm talking about actual lambdas
01:51:02 <griddle> oh, those get stack allocated
01:51:07 <griddle> and copied or moved
01:51:14 <heat> exactly, those are cheap
01:51:24 <griddle> the problem is, they are hard to give a concrete type to
01:51:29 <heat> auto
01:52:04 <heat> if you need to store them, well you're kinda fucked but maybe you shouldn't be using them
01:52:18 <griddle> I mean, how do I give a callback type?
01:52:56 <mrvn> void (*)(void *priv, uint64_t arg);
01:53:18 <heat> I use function pointers and then if I want a lambda I pass it like a callback and it implicitly converts
01:53:27 <griddle> does that work the lambda syntax?
01:53:57 <mrvn> never tried but see heat
01:54:31 <heat> https://github.com/heatd/Carbon/blob/master/kernel/mm/kasan.cpp#L164
01:55:11 <mrvn> griddle: but back to your vector question. My vector takes an allocator argument, which is the slab that stores objects for the subsystem.
01:55:12 <griddle> well ill be damned
01:55:17 <heat> in this case, [] (struct vm_region *region) -> bool casts to a bool (*ptr)(struct vm_region *)
01:55:37 <griddle> wow yeah. I dont need to store the lambda, I just want to use the closure system
01:55:58 <mrvn> griddle: then go for that. That's much better than std::function
01:56:01 <griddle> wait no, you cant cast a lambda with a closure
01:56:18 <heat> yes
01:56:29 <heat> it needs to be a lambda without captures
01:56:38 <heat> if you want to capture something you'll have to pass a priv or something
01:57:35 <heat> you could create a cheap callable object that doesn't require any allocations and doesn't do type erasure
01:58:02 <mrvn> griddle: I have a struct callback { R (*fn)(P, A); P priv; };
01:58:46 <griddle> heat: how?
01:58:51 <mrvn> return type R, private data P and argument A.
01:59:12 <griddle> mrvn: you could also probably template that further, with any number of arguments
01:59:30 <mrvn> griddle: yeah, A can be a vardiac template arg
01:59:45 <mrvn> P could too but then it gets complicated.
02:02:07 <mrvn> If you fiddle with it I bet you can specialize std::function to store the capture in the lambda object directly
02:06:57 <griddle> https://pastebin.com/raw/ENtRrkpY
02:07:02 <griddle> okay, I need help. I'm losing my mind
02:07:37 <griddle> the write to the high virtual address works, but touching the low address causes an invalid opcode exception
02:07:48 <griddle> and eip is somewhere on the stack
02:09:06 <griddle> even if I flush the TLB after the new mappings
02:10:17 <griddle> it works fine when addr = 1gb
02:10:47 <griddle> Im probably missing some crucial information regarding the first virtual page
02:15:33 <heat> griddle, sorry I was thinking about std::function
02:15:38 <heat> You're not
02:15:41 <heat> here's the thing
02:15:56 <heat> GCC sees you're accessing 0x0 and since that's UB, it inserts a ud2
02:15:59 <heat> aka invalid opcode
02:16:22 <griddle> oh
02:16:26 <mrvn> does it? check the disassembly
02:16:46 <heat> I mean, only if it changed its behavior recently
02:17:00 <heat> because it did that for a long time and it's the logical explanation
02:17:41 <griddle> yep, `ud2`
02:17:52 <griddle> that is very annoying
02:18:01 <mrvn> try addr+1
02:18:19 <Mutabah> It's better than just running off the end and doing god-knows what
02:18:24 <mrvn> You really shouldn't have a page mapped at zero so null pointer access always faults
02:18:57 <mrvn> Mutabah: unless you have something mapped at 0 and 0 is a valid pointer. But you should tell gcc about that.
02:19:00 <griddle> yeah, just testing my new paging system
02:19:32 <adu> mrvn: is it possible to implement MBR loading without mapping 0?
02:19:55 <mrvn> nullptr should be 0xDEAD0000DEAD0000
02:20:11 <mrvn> adu: MBR is loaded in 16bit mode. no mapping at all
02:20:31 <adu> so I guess it doesn't matter at that point
02:20:39 <mrvn> and kernels are usually loaded to 1MB
02:20:50 <mrvn> (x86)
02:22:56 <mrvn> griddle: your code might not work on other archs by the way.
02:23:48 <griddle> like on 32bit x86? Yeah
02:24:17 <mrvn> griddle: you assume the CPU knows the dst and addrs are the same physical address and the read is blocked till the write finishes.
02:24:47 <griddle> ohhh
02:25:05 <mrvn> Does that even work on x86?
02:25:14 <griddle> I get the right value in qemu
02:25:27 <heat> yes it does
02:25:33 <mrvn> In this case the printk code will be so complex to always finish the write.
02:25:35 <heat> thats even how linux does it
02:25:57 <griddle> works in qemu-kvm too
02:26:08 <mrvn> griddle: trydst[0] = 0xFE;
02:26:12 <mrvn> printk("%02x\n", *(u8*)addr);
02:26:29 <mrvn> That should do the write followed directly by the read
02:26:56 <griddle> works fine
02:27:03 <mrvn> unless the compiler reorders that and does the read before the write
02:27:30 <griddle> man kvm is slow on the ol' port io
02:28:11 <mrvn> griddle: also try read + write + re-read. Don't forget to use (volatile u8*) there.
02:29:25 <mrvn> I know x86 caches use the physical address to tag cache lines but I wouldn't be surprised if the read/write ordering in the cpu doesn't.
02:30:45 <mrvn> On the other hand x86 is backwards compatible to when it didn't cache so it does a ton of magic to resolve all those ordering and cache issues for you.
02:31:00 <griddle> all seems to work fine
02:31:26 <griddle> though I dont know if it works on real hardware
02:31:33 <mrvn> griddle: just beware that it's not always that simple on every arch.
02:33:01 <mrvn> griddle: how about: printk("%02x\n", *(u8*)addr); dst[0] = 0xFE; printk("%02x\n", *(u8*)addr);?
02:33:33 <griddle> ff fe
02:33:58 <zid`> aliasing, how does it work
02:34:03 <mrvn> lazy compiler. doesn't want to eliminate the common *(u8*)addr.
02:34:29 <griddle> I wonder if there could be any work in compiler optimization regarding shared memory
02:34:37 <griddle> probably not
02:34:50 <mrvn> zid`: how do you tell the compiler 2 virtual addresses are aliases to the same physical page?
02:35:01 <griddle> >probably not :)
02:42:38 <mrvn> To answer my own question: use GCC’s may_alias attribute
02:43:27 <mrvn> n8
03:44:22 <macroprep> when linux boots up if it does not successfully chroot into the OS (via chroot /rootfs) where exactly is it at, at this point, kernel? systemd? something else?
03:45:24 <Mutabah> systemd
03:45:46 <macroprep> oh ok
03:46:05 <Mutabah> well, it's already started running `init` - which is systemd on modern machines
03:46:34 <macroprep> and where would init be located?
03:49:27 <Mutabah> Init is just the first process, usually it's stored in the initrd on linux
03:49:42 <macroprep_> and where would init be located?
03:51:03 <Mutabah> < Mutabah> Init is just the first process, usually it's stored in the initrd on linux
03:51:32 <macroprep_> and initrd is located on the boot partition with the kernel vmlinuz right?
03:52:21 <Mutabah> Yes. There should be good documentation of the linux boot process on the 'net
04:02:38 <macroprep_> ok, ill try to find some
04:03:07 <macroprep_> can an android bootloader be debugged?
04:08:26 <macroprep_> nvm
04:23:45 <geist> okey dokey
04:33:25 <adu> is there a difference between gspi and espi?
04:33:42 <geist> dunno, no idea what either of those are
04:40:16 <klange> GSPI is a manufacturer of lubricants and ESPI is the European Space Policy Institute.
04:50:54 <ybyourmom> QSPI is a serial bus standard
04:51:20 <zid`> anyone know what the hell .sdata is on MIPS
04:51:29 <geist> 'small data'
04:51:31 <geist> riscv has it too
04:51:33 <zid`> gcc manual gives some options for messing with it but I don't know what it's for
04:51:45 <zid`> I added a function pointer assignment to my code and now suddenly gcc wants to use it
04:52:01 <geist> basically the idea is data in the .s* sections is within some short offset of a dedicated register (gp i believe)
04:52:17 <geist> and thus can access with just the load/store instruction offset off of gp
04:52:21 <zid`> I tried -mno-gpopts but it didn't stop it
04:52:44 <geist> ARCH_COMPILEFLAGS += -mno-gpopt
04:52:52 <geist> ttps://github.com/littlekernel/lk/blob/master/arch/mips/rules.mk#L39 specifically
04:52:58 <zid`> small-data section exceeds 64KB; lower small-data seize limit (see option -G)
04:53:09 <zid`> relocation truncated to fit
04:53:27 <zid`> if I actually add an .sdata, not that I have gp loaded with anything specific
04:54:13 <geist> riscv has something very similar: https://github.com/littlekernel/lk/blob/master/arch/riscv/start.S#L35
04:54:17 <zid`> geist: I added -mno-gpopt but it's still generating it
04:54:36 <geist> zid`: that was sufficient for my code, did you recompile everything? also use it on linker too
04:54:47 <zid`> lemme try linker too
04:55:13 <zid`> -m is an emulation mode for linker
04:55:15 <geist> it's a silly optimization, but it's based on the idea that you put some of the 'hot' data in it. .sbss works too
04:56:22 <geist> https://github.com/littlekernel/lk/blob/master/arch/riscv/linker.ld#L70 is the trick i found for riscv. basically you set a phony symbol to 2K into the .sdata section
04:56:38 <geist> then load that into gp at boot, so that it has +/- 2K reach into it
04:56:41 <zid`> do you have to move to gp in your crt0.s
04:56:51 <geist> mips works similarly but i never screwed with it
04:56:53 <zid`> I don't actually have a crt0.s atm I'm lazy
04:56:57 <geist> yes, see one of the earlier links
04:57:06 <zid`> and why it wants to put 64kB of crap in there I have no idea
04:57:09 <geist> but that's riscv. for the mips port i just use the no-gpopt and moved on with things
04:57:29 <geist> there's a whole trick about it. i think it tries to pile smallish things in it
04:57:48 <zid`> ah yea you were right I stale .o filed when I added mno-gpopt
04:57:50 <geist> and there's some option about which symbols to include
04:57:59 <geist> based on size i think
04:58:08 <zid`> seems like it's sort of like [fs:] on x86
04:58:18 <geist> it's a silly optimization for large programs, but it probably came from an earlier era when programs were small
04:58:28 <zid`> If you can tag things into it it seems okay
04:58:35 <zid`> 'this is hot global state'
04:58:37 <geist> it's all so it can avoid a multi instruction sequence to calculate offset into data
04:58:47 <zid`> keep it within a disp16 of some reg which always has that base address
04:58:53 <geist> yah, precisely
04:58:56 <geist> the ABI says which one gp is
04:59:03 * zid` has no idea what his ABI is
04:59:20 <zid`> I wrote all the syscall crap in assembly and I don't link against anything :P
04:59:25 <zid`> I let god sort out the abi
04:59:30 <geist> yah mips is an ABI mess. there are lots of them
05:00:46 <zid`> hmm no breakpoint on my function, odd
05:01:40 * zid` set his irq handler function pointer to something and tried to trigger an IRQ but apparently did not get one
05:01:58 <geist> yah microblaze even has *two* sdata segments: https://github.com/littlekernel/lk/blob/master/arch/microblaze/start.S#L34
05:04:24 <zid`> gcc is really crap at optimizing for mips
05:06:02 <geist> ah i see, in microblaze sdata2 is small RO data
05:07:03 <zid`> oooh nice bug, I was checking interrupt cause against the mask reg not the status reg
05:07:20 <zid`> so basically every single interrupt was going to fire, because the enabled ones were always enabled :P
05:08:30 <geist> that'll do it
05:14:10 <zid`> god damnit now I triggered sbss :P
05:15:30 <zid`> -G0 got rid of it apparently
05:15:59 <geist> yah, the microblaze one at least was described as being for 'small data', so there's some sort of threshold for the size of the symbol
05:16:08 <geist> i guess the idea is to cram the one off ints and chars and whatot there
05:16:17 <geist> but larger structs go into the regular one
05:16:27 <geist> which maybe makes sense since you probably want to compute their base address in general anyway
05:16:42 <geist> but the -G<N> option sets the size threshold
05:16:50 <geist> so -G0 should say nothing goes in it
05:18:24 <zid`> grr I broke my debugger now
05:18:28 <zid`> it's showing nops for all of memory
05:19:39 <macroprep> If you've hard bricked your device, it means that your device doesn't respond when connected to a charger , or when power button is pressed. It's literally like a piece of brick and it's commonly done when you fry your kernel
05:19:42 <macroprep> how does this get done?
05:20:09 <geist> how doe it get done?
05:20:34 <macroprep> yea
05:20:44 <geist> the question does not parse
05:20:50 <geist> try again, what are you asking?
05:20:53 <zid`> still putting up with the troll vampire?
05:21:01 <Mutabah> zid`: It can be fun
05:21:04 <macroprep> how does a device get hard bricked
05:21:12 <Mutabah> Hardware failure
05:21:17 <geist> any number of ways
05:21:22 <geist> corrupted boot chain
05:21:27 <zid`> wat, debugger is working, my thing no longer boots
05:21:40 <geist> hardware failure, that too
05:21:53 <geist> basically all sorts of failure mode equals 'brick'
05:22:08 <geist> it's like saying why does a car not go? well, there are a ton of ways that cause the car to not go
05:22:11 <macroprep> as i want to try to boot up a custom built kernle but i do not know if it will brick my device
05:22:20 <geist> a ton of failures end up with it looking like a brick
05:22:35 <macroprep> kernel*
05:22:36 <geist> well, it might. i wouldn't try it if you actually care about your device
05:22:54 <geist> device makers generally do not care what happens to your device if you start to fiddle with it
05:23:33 <geist> usually there's a way to recover it, but it may require proprietary tools and/or encrypted recovery images that you may or may not have access to
05:24:50 <macroprep> ok ;-;
05:25:27 <macroprep> imma just avoid it ;-;
05:25:55 <geist> good idea!
05:25:57 <zid`> geist pls, why does my CD image suddenly no longer boot now I have something in bss :(
05:26:16 <geist> zid`: did you zero out the bss?
05:26:17 <zid`> it's not even a real executable it's a firmware image, my bss is just allocated 0 bytes in the file >_<
05:26:27 <zid`> only real change is now that it's bigger
05:26:27 <geist> yes, that's the definition of bss
05:26:42 <zid`> geist: hardly anyone allocates bss like that
05:26:44 <geist> it is data that occupies zero space in the file, but real space in memory
05:26:50 <zid`> kind of defeats the point of it
05:26:58 <geist> eh? no
05:27:01 <zid`> mine are actually allocated
05:27:03 <Mutabah> wha?
05:27:13 <geist> you just said it is allocated 0 bytes in the file
05:27:21 <zid`> you have the brackets in the wrong place
05:27:21 <Mutabah> The idea of BSS is that it's known to be zero-initialised, so it doesn't need to take up storage space
05:27:29 <zid`> it isn't allocated [0 bytes]
05:27:33 <zid`> it's bytes which are allocated and zero
05:27:38 <zid`> because I don't really have a bss
05:27:49 <geist> i am not lost what you're trying to say
05:27:57 <zid`> I don't have a bss.
05:27:58 <geist> dump the program header plz
05:28:04 <zid`> I don't have a program.
05:28:07 <geist> section header too
05:28:27 <zid`> It's a firmware image which runs out of ram, I don't have a crt0.s so I just allocated the bss as bytes
05:28:28 <geist> then i have no idea how to help you
05:28:37 <zid`> all that happened is that it got bigger
05:28:43 <zid`> but it stopped booting :(
05:28:45 <geist> so you did everything from scratch and something doesn't work, but you wont show me what you did
05:28:48 <geist> so i have no idea how to help
05:28:55 <Mutabah> maybe it's too big to be loaded by whatever is load it?
05:29:02 <Mutabah> (you mentioned that it's a CD loader?)
05:29:04 <geist> that could be it too
05:29:15 <geist> maybe it can only read one sector or something
05:29:15 <zid`> yea but it's like.. 4k bigger and I have 2MB of ram :(
05:29:23 <geist> maybe it can only load 2K sector?
05:29:25 <zid`> geist: it'd still boot that one sector, I hope
05:29:34 <zid`> I'll check my header
05:29:43 <zid`> I get nothing in ram
05:30:37 <zid`> oh maybe my filesize calc is wrong that'd do it
05:30:51 <zid`> oh the bios supports doing bss for you, never noticed that
05:30:59 <zid`> 028h Memfill Start Address (usually 0) (when below Size=None)
05:30:59 <zid`> 02Ch Memfill Size in bytes (usually 0) (0=None)
05:31:43 <Mutabah> Just a memset wrapper I guess... might be more compact?
05:31:58 <geist> sure, like a multiboot header or something
05:32:18 <geist> if you have a loader that is doing the putting of you in memory, easy enought o also have it zero your bss
05:32:24 <zid`> I'd still have to have my linker script fill it out, but it's doable
05:32:33 <geist> or do it in a .S file
05:32:37 <zid`> anyway, need to figure out why it won't boot
05:32:47 <geist> .word _bss_start; .word _bss_end - _bss_start
05:32:49 <geist> or something like that
05:33:50 <zid`> yea basically, but I need to add those to my linker script if I do
05:33:56 <geist> of course
05:34:03 <zid`> I think my image sizecalc has exploded
05:35:34 <zid`> yep
05:36:01 <zid`> 0x0000000000001001 image_size = (SIZEOF (.text) - 0x800)
05:36:04 <zid`> That needs rounding up
05:39:41 <zid`> 014h Initial GP/R28
05:39:55 <zid`> oh hey I guess I could use the .sdata if I put the address of .sdata here?
05:40:09 <zid`> and made sure gcc knew r28 was gp
08:32:17 <ddevault> would anyone happen to know offhand how long a fresh zircon build takes on $hardware
08:32:40 <zid`> 17 seconds
08:32:56 <ddevault> can you define $hardware
08:33:09 <ddevault> supercomputers would not be a useful benchmark for me in this situation
08:33:18 <zid`> might want to pick something more specific then
08:33:22 <zid`> like your own desktop, then just do the build
08:33:27 <ddevault> x86 build on consumer x86 hardware
08:34:10 <j`ey> why not just try it?
08:34:19 <zid`> >like your own desktop, then just do the build
08:34:27 <ddevault> I can, and will
08:34:36 <ddevault> I asked if anyone here knew, figuring someone likely would
08:34:58 <j`ey> lets guess... <5mins?
08:35:07 <zid`> do you have an ssd, is your cache warm, how much ram do you have, how many cores do you have, how fast are the cores
08:35:18 <zid`> but regardless of what you answer, somewhere between 10 seconds and 10 minutes, most likely
08:35:56 <ddevault> I can reason about those things for someone who gives their hardware configuration alongside their number
08:36:00 <ddevault> and I did specify a fresh build
08:36:14 <ddevault> but instead I get a lecture from people with nothing better to do, apparently
08:36:20 <ddevault> not sure why I bother here
08:36:30 <zid`> why are you even here
08:36:33 <zid`> .theo
08:36:33 <glenda> AND WHERE IS THE PONY.
08:36:35 <bcos_> For a micro-kernel; I wouldn't expect it to take very long
08:36:37 <j`ey> ddevault: Im interested in hearng the answer
08:36:41 <ddevault> well, it's C++
08:36:51 <j`ey> it's still quite small though, right?
08:37:05 <ddevault> so as such it could take anywhere from a few hours to the heat death of the universe
08:37:35 <bcos_> (actually, should be able to compile a micro-kernel 1000 times faster than a millikernel, and 1000000 faster than a unikernel; that's just how SI units work... ;-)
08:38:25 <ddevault> not to mention that the system I'm working from now would require me to first build a toolchain, and invent the universe, and bake a cake, before I can attempt a zircon build
08:40:46 <j`ey> seems like it can work with an out of box clang
08:41:36 <ddevault> I can try that
08:41:56 <j`ey> https://fuchsia.dev/fuchsia-src/development/build/toolchain
08:43:42 <ddevault> "out of the box" clang from fuschia.googlesource.com/third_party/llvm-project, huh?
08:43:56 <j`ey> I said that before reading that page :D
08:44:19 <j`ey> I think you can use upstream though, I think that's just their mirror
08:44:43 <ddevault> after a few minutes of messing with things to get it working with my distro's clang package I got bored
08:50:07 <mrvn> ddevault: 4h to get your system ready, 10m to build
08:50:15 <ddevault> hah
08:50:17 <mrvn> or forever since you already gave up
08:54:50 <klange> ddevault: I'm sure the friendly Googlers in #fuchsia would be able to help you.
08:56:23 <ddevault> thanks klange
08:56:27 <ddevault> swung by
08:56:48 <aalm> .theo
08:56:48 <glenda> Punting stupid problems along forever just gets worse and worse.
08:57:50 <zid`> hah
08:57:54 <zid`> theo is always great
08:58:39 <immibis> .theo
08:58:39 <glenda> Well, I don't think the world will fall over as a result.
09:23:56 <nellie> hello
09:24:29 <nellie> is anyone here?
09:24:36 <zid`> that's not how irc works
09:24:51 <zid`> There's 277 people here your job is to say something interesting enough to get a response
09:25:00 <nellie> sorry, i'm new ;-;
09:28:23 <nellie_> I can't manage to plot a single pixel in VESA and I feel pretty stupid right now
09:28:48 <nellie_> when I try it fills a whole group of pixels
09:28:55 <zid`> so writing lots of bytes at once? :P
09:29:12 <nellie_> nope, I even tried using the example code on the wiki
09:29:19 <zid`> are you using vbe and a lfb?
09:30:36 <nellie_> yes I am
09:30:46 <zid`> what mode did you set?
09:31:17 <nellie_> 0x115
09:31:21 <zid`> which is..?
09:31:31 <zid`> and not 0x4115?
09:32:02 <nellie_> 800x600x24
09:32:20 <zid`> and did you do a 3 byte write, correctly aligned?
09:32:29 <zid`> and what is a 'group' of pixels?
09:34:44 <nellie_> yes, a three-byte write, and when I try to set a pixel, it sets a group of 8x16 pixels instead of just one
09:34:50 <zid`> post code
09:35:35 <nellie_> one second, you mentioned using 0x4115 rather than 0x115?
09:35:40 <zid`> yes
09:35:44 <zid`> that's how you ask for a LFB
09:35:47 <nellie_> i'll try that, then
09:36:03 <zid`> INT 0x10, AX=0x4F02, BX=mode, ES:DI=CRTCInfoBlock
09:36:03 <zid`> Set Video Mode. Call this with the mode number you decide to use. If you choose a mode that makes use of a linear framebuffer, you should OR the mode number with 0x4000. This sets the "Use LFB" bit in the mode number. Set the bit 11 of BX to instruct the BIOS to use the passed CRTCInfoBlock structure, see the specification for more information.
10:06:14 <zid`> you dead?
10:10:00 <bcos_> No response. Must be dead.
10:11:10 <nellie_> i'm dead
10:11:44 <nellie_> i think i might know what's wrong
10:12:02 <j`ey> i just realised why removing my low half mapping didnt work
10:12:09 <zid`> you were still using it?
10:12:24 <j`ey> i didnt reset my SP to the high half!
10:12:30 <zid`> yes then ;)
10:12:38 <zid`> not as fun as my bug though
10:12:57 <zid`> I set my stack pointer to kernel + 4096 a long time ago when I was just starting and completely forgot about it
10:13:21 <zid`> then random code would crash in really bizzare ways as I commented or uncommented lines
10:13:30 <zid`> because my kernel code and stack pushes were overlapping
10:14:15 <nellie_> same thing happened to me a while back
10:16:00 <nellie_> anyway, i think the VESA mode isn't even being set
10:16:16 <zid`> sounds like you're doing well
10:16:30 <nellie_> yep
10:17:11 <zid`> pode costs
10:17:13 <zid`> I mean, post codes
10:17:17 <zid`> and nudes
10:19:14 <nellie_> I was writing to the wrong register all along
10:19:23 <nellie_> somehow i missed this
10:19:28 <zid`> You have a clever.
10:19:33 <zid`> That'll be $50
10:19:35 <nellie_> i have bad thunks
10:20:05 <j`ey> zid`: I hit infinite recursion and had the same issue
10:20:12 <nellie_> thank you for helping me realize the problem!
10:20:16 <zid`> I've yet to recurse in a serious project
10:20:23 <zid`> nellie_: No thanks needed, just the 50
10:20:50 <j`ey> zid`: accidental recursion :P
10:21:49 <nellie_> that orgasmic feeling when the computer does what you want it to do
10:21:59 <zid`> orgasms cost extra
10:22:50 <bcos_> Erm, nope. When software does what you want it to you just get paranoid about hidden bugs and start wishing you had easily found bugs instead
10:23:11 <zid`> That's why I write my software with obvious bugs that I don't fix
10:23:17 <zid`> then all UB lives inside that one bug I neer fixed
10:23:20 <zid`> even if it's completely unrelated
10:23:25 <zid`> I can just blame the obvious bug I didn't fixed
10:23:40 <nellie_> irc chats are amazing, why didn't I use this much earlier
10:28:58 <Lowl3v3l> bcos_: "There are no healthy patients, just underdiagnosed ones!" ? :D
10:30:03 <zid`> That's why you should never get a full body CT scan
10:30:08 <zid`> they'll find all sorts of things wrong with you
10:34:58 <Lowl3v3l> That shitty feeling when you want to use new cool C++-Features and no IDE undestands them :/
10:38:19 <nellie_> vim gang
10:39:04 <zid`> not-using-c++-anything-masterrace
10:39:10 <Lowl3v3l> Unfortunately I am not free to choose the IDE's I use at work
10:39:44 <Lowl3v3l> unless someone finds a way to use vim on windows to build Visual Studio Projects xS
10:39:54 <nellie_> what do you have to use?
10:40:05 <nellie_> oh, Visual Studio
10:41:10 <Lowl3v3l> And if someone does I'd probably not use it, i tend to be afraid of magic on the dark side of evil.
10:41:54 <nellie_> is Visual Studio any good? I always try to use FOSS because big brother Stallman is always watching
10:42:34 <zid`> nope
10:43:00 <Lowl3v3l> I do not like it, it's way to bloated for my taste and using any build process or build system M$ doesn't like is a pain in the ass. And I dislike MSVC++ with a passion
10:43:08 <nellie_> d*ng
10:43:11 <zid`> It only does the things it does
10:43:29 <zid`> unlike *unix style things that can do anything they can do and in any combination :P
10:43:39 <zid`> want to use msvc for anything but windows C++ programs? fuck you
10:43:50 <nellie_> stinky proprietary software :p
10:44:17 <Lowl3v3l> For private use I prefer eVil-mode emacs or the QT-Creator. But I suppose CLion is good as well, most other IntelliJ-Projects are
10:44:49 <nellie_> not to start an editor war, but
10:45:02 <nellie_> does eVil mode have any advantages over Vim?
10:46:33 <zid`> never heard of it
10:46:36 <zid`> vi fork?
10:46:44 <Lowl3v3l> On plain vim? Three that are big for me. First : emacs has amazing modes for other languages I use(Racket, Haskell), secondly scripting emacs with non trivial things is way less of a pain in the ass for me and third : spacemacs provides pretty cool defaults.
10:46:48 <zid`> It's not like anybody can actually use vi
10:46:58 <zid`> at least enough to need things mroe than it can actually do
10:47:04 <Lowl3v3l> eVil-mode is essentially emacs with vim-keybindings.
10:47:10 <nellie_> it's a plugin for emacs, so you can emulate Vim rather than just using Vim
10:55:55 <klange> imo if you're gonna bother to write an OS you might as well write an editor to go with it ;)
10:56:40 <lkurusa> :)
10:58:09 <Lowl3v3l> xkcd 927 ;)
10:58:44 <klange> Not sure 927 applies for this; editors aren't standards (classic vi aside)
11:00:18 <klange> (Plus, this is osdev, if we through around 927 for things like that it would be hella hypocritical)
11:01:27 <Lowl3v3l> got me there^^
11:02:50 <klange> (threw*)
11:05:39 <lkurusa> #editordev
11:05:41 <lkurusa> :D
11:06:20 <Lowl3v3l> mother of god...
11:20:18 <nellie_> exit
11:20:27 <nellie_> how do i exit irssi?
11:21:05 <zid`> pkill -9 irssi
11:21:09 <zid`> or you know, use the commands
13:22:02 <w1d3m0d3> editor development terrifies me
13:22:09 <w1d3m0d3> I wanted to make a hex editor but then I didn't
18:59:35 <Prf_Jakob> Heya, has anybody here written any AArch64 asm? Trying to figure out how to do a function that saves all of the regs to the stack, calls a function and then returns the returns the return from the function.
19:00:13 <Prf_Jakob> Looking at the dissasembly from a C compiler just confuses me.
19:13:40 <j`ey> Prf_Jakob: what issue do you actually have
19:13:43 <j`ey> ?
19:15:29 <Bitweasil> Well, what calling convention is the c compiler using?
19:15:36 <Bitweasil> Most stuff these days is passed in registers since there are plenty of them.
19:18:44 <Prf_Jakob> j`ey: The issue I have is that I don't understand AArch64 ASM, what I'm trying to do is make my GC work on AArch64, currently my push all registers to stack function is a stub and surprise I get use after free errors :)
19:22:35 <j`ey> Prf_Jakob: so what do you have so far/
19:26:15 <Prf_Jakob> j`ey: https://github.com/VoltLang/Volta/blob/master/rt/src/vrt/aarch64.s
19:27:30 <Prf_Jakob> https://hastebin.com/kolaboxohu.cpp
19:29:17 <j`ey> Prf_Jakob: you want to use the 'stp' instruction
19:29:33 <Prf_Jakob> From what I can understand yeah
19:29:35 <j`ey> something like stp x0, x1, [sp, #-16]!
19:29:42 <Prf_Jakob> Yupp yupp
19:31:20 <j`ey> so what's the issue?
19:32:00 <Prf_Jakob> The compiler was doing very weird things to sp in the output I was looking at.
19:32:08 <Prf_Jakob> Like not changing it
19:33:08 <Prf_Jakob> I guess "sub sp, sp, #256" should be safe?
19:33:15 <Prf_Jakob> Not pushing x31 of course
19:33:17 <j`ey> should be
19:36:13 <Prf_Jakob> If I'm reading the docs right I would need to restore x30, since bl saves PC+4 to x30?
19:36:41 <j`ey> yeah
19:41:02 <Prf_Jakob> What does "addx29, sp, #16" do?
19:42:02 <Prf_Jakob> "add x29, sp, #16" do?
19:42:13 <j`ey> x29 = sp+16
19:42:33 <Prf_Jakob> Hehe that I figured out, but what does x29 do? :p
19:42:45 <j`ey> its just a gp reg
19:42:47 <Prf_Jakob> Oh is it the frame-pointer?
19:43:12 <Prf_Jakob> Ah sorry, context. Clang adds that instruction before a call.
19:43:15 <j`ey> yeah I think it is used as that
19:43:38 <Bitweasil> On most modern ARM implementations, there aren't the same sort of fixed purpose registers x86 has - they're just general purpose, and you can use them for "whatever." There are conventions, but they're typically compiler/OS specific.
20:18:08 <alberinfo_osdev> Hi, i have a question. I have a x64 os, and when im returning the rsdp addr, it throws a #GP. No matter how much i think it i cant seem to figure out what's happening. Could you help me? Thanks!
20:19:05 <Bitweasil> rsdp?
20:19:12 <alberinfo_osdev> Yes
20:20:36 <alberinfo_osdev> Ah yeah, i forgot github.com/alberinfo/Slidoor-OS/tree/master/ if you want to see my code
20:22:06 <adu> is that like the DSDT?
20:22:27 <alberinfo_osdev> Erm.. no.. its rsdp
20:22:32 <Bitweasil> Sorry, can you expand RSDP? I'm not actually familiar with that acronym.
20:22:54 <Bitweasil> Oh, ACPI. :( Yuck.
20:23:05 <alberinfo_osdev> ya.. dont worry :-)
20:24:52 <eryjus> are you in long mode yet?
20:25:07 <alberinfo_osdev> Yes
20:25:38 <eryjus> are you getting the #GP when searching or when accessing the found address?
20:26:10 <alberinfo_osdev> When accesing, because its when i retuen the acpi addr in the rsdp table
20:26:43 <Bitweasil> Returning the address shouldn't cause a #GP, though trying to access a nonsense-address can.
20:26:45 <alberinfo_osdev> You can see my repo if you want github.com/alberinfo/Slidoor-OS/tree/master/
20:26:47 <Bitweasil> Is the returned address sane?
20:26:53 <Bitweasil> Yeah, want to point to lines of code or something?
20:27:11 <alberinfo_osdev> Its in include/acpi/acpi.c
20:27:29 <Bitweasil> ew. You've got c files in your include dir.
20:28:21 <eryjus> Since you are not getting a #PF, I am going to assume you are getting a nonsense address back or a non-canonical address
20:29:11 <alberinfo_osdev> Im going to see whats in there, but i dont really know. I discovered that this return was the problem a few moments ago
20:31:19 <alberinfo_osdev> Ok... returned address: 0xFE15FC, value 0x54445352
20:35:27 <eryjus> that looks good -- signature is "RSDP", so that is a good start. you will need to get to figure out exactly what is creating the #GP. Your return statement? if so then stack alignment? something else where you might be treating a 32-bit address as 64-bits and picking up extra bytes?
20:38:55 <alberinfo_osdev> Well, is when i return the address what causes #GP and if i comment that line it just keeps on with execution, but after that i cant tell... afaik the stack is ok and(at least the rsdp one) the addresses for acpi are treated as 32-bit,so no extra bytes
20:41:35 <eryjus> ok, post a link to that return statement
20:42:30 <alberinfo_osdev> Its in my repo, in include/acpi/acpi.c, line 31
20:43:04 <eryjus> can you post a link?
20:43:20 <eryjus> as in "http://..."
20:43:32 <alberinfo_osdev> github.com/alberinfo/Slidoor-OS/tree/master/
20:44:15 <eryjus> you mean this one: https://github.com/alberinfo/Slidoor-OS/blob/master/include/acpi/acpi.c#L31
20:44:45 <alberinfo_osdev> Yeah
20:45:25 <eryjus> https://github.com/alberinfo/Slidoor-OS/blob/master/include/acpi/acpi.h#L20
20:45:37 <eryjus> extra bytes -- structure alignment is a problem
20:45:38 <wcstok> Do you know what the instruction is at that exception point, values of the registers involved, etc?
20:45:53 <eryjus> it may not be the cause, but you need to pack this structure
20:49:27 <alberinfo_osdev> Ok... irc pushed me off :(. Absolutely didnt know that i had to pack it, but stills throwing #GP
20:49:35 <eryjus> Also when you comment out this line, https://github.com/alberinfo/Slidoor-OS/blob/master/include/acpi/acpi.c#L31, you mentioned that execution continues as if nothing was found? So, let's see a link to the call to this function. Are you conditioning some execution on != NULL and if so the problem might be there
20:49:43 <wcstok> Well now that you're back, do you know what instruction is triggering the exception
20:50:18 <wcstok> The source line isn't always detailed enough when debugging exceptions like that, also the register state if the instruction uses any might help
20:52:24 <alberinfo_osdev> Yep, it continues as if nothing was found(if i comment that line). I use != null when i finish seeing if the rsdptr is valid or not
20:52:36 <alberinfo_osdev> In acpigetrsdptr
20:53:57 <Bitweasil> If you're commenting out the line, is the compiler getting smart and dropping a bunch of other code?
20:54:14 <alberinfo_osdev> No(?)
20:54:29 <eryjus> alberinfo_osdev, i am not familiar with your code base and since I am trying to help you during my working hours, please help me out. Links are a great way to do that. Also, wcstok is absolutely correct here -- we are going to need to get to the asm instruction that is causing the problem.
20:55:54 <alberinfo_osdev> Ok.. i will try to see whats the compiler doing with and without the comented line
21:13:20 <alberinfo_osdev> ok... gcc doesnt want to compile at all, so.. i dont know.
21:13:40 <wcstok> Find the instruction that'
21:13:42 <sortie> Evening y'all
21:13:43 <wcstok> s faulting
21:13:56 <wcstok> Then find what the inputs to said instruction are
21:14:13 <wcstok> Then you'll be able to work out why it's faulting and maybe move forward
21:14:20 <sortie> How's osdeving going? Any cool screenshots? Uncool screenshots can also apply!
21:14:40 <sortie> I also accept stack traces.
21:15:00 <sortie> Compile errors too. But no compile warnings. I draw the line there.
21:15:11 <alberinfo_osdev> Not a photo, but a clear image in my mind of my isr telling gp everytime lol
21:15:39 <wcstok> Then you have your faulting rip and register state, so, what is it
21:20:57 <alberinfo_osdev> ok... when i add the asm("xchgw %bx, %bx") it doesnt get #GP but also does not catch the rsdp
21:21:51 <wcstok> You're not helping yourself move forward. Do let us know when you're ready to.
21:26:59 <alberinfo_osdev> Ok, back here. Rax: 0xf, rcx: 0x780, rdx: 0x18, rbx: 0x0, rsp: 0x127f20, rbp: 0x127f50, rsi: 0x7, rdi: 0x3d5, rip: 0x100291
21:27:16 <wcstok> And the instruction at that rip...
21:27:24 <alberinfo_osdev> The return one
21:27:45 <alberinfo_osdev> i mean, the one who returns the rsdp address
21:28:38 <wcstok> It might be, it might be. You do know the difference between a machine instruction and a source code line, yes?
21:31:05 <alberinfo_osdev> Yes, sorry... https://github.com/alberinfo/Slidoor-OS/blob/master/include/acpi/acpi.c, line 31
21:31:57 <eryjus> are you using a cross compiler? what optimizations are you using? what are the machine instructions that are being executed to get you to that instruction
21:32:43 <wcstok> That still isn't an instruction. How about the instruction
21:33:13 <alberinfo_osdev> No, im not using a cross compiler, no optimizations. No idea about the machine instructions
21:33:39 <eryjus> do this -- objdump -D bootloader.bin and post the output in a gist
21:36:10 <eryjus> ok, so these are all critical to os development. you have some homework to do: https://wiki.osdev.org/GCC_Cross-Compiler
21:36:56 <eryjus> and then, you will need to brush up on your tools like x86_64-elf-objdump and the like
21:38:15 <eryjus> you will need to be able to use those along with your debugging output to answer the questions. Many times the questions we ask will get you to something that is not what you expected and then you have something you can trace back
21:42:06 <alberinfo_osdev> Https://gist.github.com/alberinfo/3653e76e90e429729c73fbbd8c05deed. will set the cross compiler
21:44:23 <j`ey> hmmmmm. I have my kernel code has some kinda function pointer / vtable use, and now when I remove the 1:1 va<->pa mapping, that pointer value is incorrect :|
21:45:44 <wcstok> 100291: 48 8b 45 e0 mov -0x20(%rbp),%rax assuming your rip from earlier is a) correct and b) still valid. rbp seems fine (again assuming you have it correct), something doesn't seem right. Have you tried live debugging this thing?
21:47:34 <alberinfo_osdev> No, not really. Should try with 'step' of bochs?(well probably yes, but just for being sure)
21:49:30 <wcstok> set a breakpoint on that rip, run it to that point, check the register state, step past it and see if it still hits the #GP, go back and consider what caused the #GP
21:52:32 <eryjus> also, read the intel/amd manuals on what instruction generated the #GP and determine the possible causes for the #GP; investigate each one pedantically.
21:54:50 <j`ey> looks like Im going to have to get relocating working sooner than expected
22:01:53 <alberinfo_osdev> Ok, well more info now. Bochs throws access_read_linear(); canonical failure. So non canonical address, when excecuting memcmp
22:03:58 <alberinfo_osdev> More exactly, when searching for S5
22:08:48 <wcstok> Well, that'll do it
22:50:37 <Bitweasil> Non-canonical addresses are a /great/ way to #GP. :)