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=17
12:34:21 <brimonk> While trying to debug/test my kernel with qemu and gdb, I keep getting this message: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
12:35:50 <brimonk> Um. What should I do about that?
12:43:11 <brimonk> (it was that I wasn't using qemu for an i686, duh)
12:49:58 <bcos> brimonk: Does your OS use hardware virtualisation?
12:51:51 <brimonk> bcos: yes.
12:52:44 <bcos> In that case you'll need to avoid using TCG/make sure Qemu is using hardware virtualisation
12:54:05 <bcos> (and probably put up with the warning)
12:55:01 <bcos> Hrm
12:55:32 <bcos> Not sure if using GDB forces Qemu to drop back to TCG (not sure if they can support things like "single-step" with hardware virtualisation)
01:06:14 <clever> https://github.com/torvalds/linux/blob/master/Documentation/virtual/kvm/api.txt#L2819
01:06:26 <clever> at the lowest level, the kvm api appears to be capable of single-stepping
01:07:02 <clever> so its a question of if qemu can use that, and forward the ability to gdb
01:18:19 <doug16k> you can debug kvm
01:20:11 <doug16k> tcg has infinite hardware breakpoints - all breakpoints are hardware breakpoints which can't be overwritten and don't place a breakpoint opcode. in kvm, software breakpoints placed too early will get overwritten. you need a hardware breakpoint to catch it somewhere then place your software breakpoints
01:20:20 <doug16k> virtually infinite, I've never hit it
01:21:36 <doug16k> I have a helper startup macro for gdb which sets up a hardware breakpoint at the entry point, and there are commands attached to it which run when hit, which place several software breakpoints I always want when debugging
01:21:41 <doug16k> doing this makes it work even in kvm
01:22:16 <doug16k> if it felt like kvm not debugging properly , it was most likely software breakpoints getting overwritten, making it look bad
01:22:42 <doug16k> hb or hbreak to make guaranteed-to-work breakpoint
01:26:39 <doug16k> typically you can create breakpoints when you feel like it and by the time you can attach, the program image is already loaded. in qemu scenario, your program is nowhere near existence. the bios didn't even run one instruction yet. if you place your software breakpoints now, they'll be long gone by the time the kernel runs
01:27:14 <doug16k> in tcg it's magic, breakpoints are immune to memory overwrite
02:29:47 <brimonk> I mean, I don't get the error when I use qemu-system-i686, but I do when I use qemu-system-x86_64
02:30:52 <brimonk> *386
02:42:57 <bcos> brimonk: Just write your own hyper-visor!
02:47:23 <bcos> (more seriously; if it's actually a problem and you can't just ignore the warning; you might want to try a different emulator - I doubt Bochs would have any "nested virtualisation" problem, VirtualBox I'm not sure (its technically similar to Qemu, so..)
03:07:01 <doug16k> if you have an intel cpu you may have to separately enabled nested virtualization. on amd it is implicitly on
03:08:22 <doug16k> `cat /sys/module/kvm_intel/parameters/nested`
03:08:49 <doug16k> brimonk, ^
03:10:16 <doug16k> clever, kvm already has all that hypothetical debug stuff you mentioned
03:10:30 <doug16k> qemu gdbstub works fine on kvm if you know what you are doing
03:11:08 <doug16k> qemu already has, on -enable-kvm ...*
03:11:41 <doug16k> oh nvm lol I already responded to that
02:36:40 <mlugg> Has anyone been able to get lldb to play nice with qemu? GDB is annoying me and I want to see if I can make LLDB work
03:13:20 <d3x0r> so anyone have alist of like small OS's built on UEFI only? I found a couple...
06:38:47 <robert_> so I'm trying to get a dynamic ELF loader to load basic static ELF files, so I can load my kernel from my bootstrap process; my code is at https://gist.github.com/lighth7015/34226b46518ee30477cbe6c1e3d2dcd6 and it's segfaulting at 0xffca8ac5, and it either segfaults at "?? ()" (the address is some offset inside the image) or returns 1, which means it couldn't find what I was looking for.
08:05:09 <mlugg> When you start an AP with a SIPI, does it have the A20 line already set or do you have to do that for every core? Does the A20 gate actually even exist on a per-core basis?
11:27:56 <robert_> there lol
11:28:22 <robert_> (repost, because I lost connection because my internet decided to shit itself) so I'm trying to get a dynamic ELF loader to load basic static ELF files, so I can load my kernel from my bootstrap process; my code is at https://gist.github.com/lighth7015/34226b46518ee30477cbe6c1e3d2dcd6 and it's segfaulting at 0xffca8ac5, and it either segfaults at "?? ()" (the address is some offset inside the ima
11:31:43 <doug16k> robert_, your PROT_EXEC gives read permission?
11:32:02 <doug16k> something not seeing PROT_READ as well might do the wrong thing
11:32:08 <robert_> hm
11:32:30 <doug16k> PROT_READ | PROT_EXEC should work
11:32:45 <doug16k> also note that p_flags might be zero. not readable, writable, or executable. handle that
11:33:02 <robert_> hm
11:33:21 <doug16k> there might be very weird sections of debug info which you are going crazy with
11:33:26 <robert_> char *exec = mmap(NULL, fileinfo.st_size, PROT_READ | PROT_WRITE | PROT_EXEC,
11:33:27 <doug16k> they are not rwx
11:33:43 <robert_> it has read, write and exec
11:33:46 <robert_> oh
11:33:48 <doug16k> drop sections with 0 vaddr
11:34:08 <robert_> so I can just test for (vaddr > 0)?
11:34:25 <doug16k> I suggest >= 4MB (0x400000) but ya, don't let null pointer be valid
11:34:34 <robert_> okay
11:34:50 <doug16k> plus you will handle weird sections with 0 load address, which should be dropped I believe (by loaders)
11:35:01 <doug16k> vaddr I mean
11:35:10 <robert_> so the mmap should just be write and exec?
11:35:32 <robert_> ah
11:35:35 <robert_> yeah
11:35:35 <doug16k> what you have is fine, I meant line 198 should be PROT_READ | PROT_EXEC
11:35:44 <doug16k> OR make sure mprotect makes executable also readable
11:35:54 <robert_> oh yeah
11:36:00 <doug16k> depends on architecture though, you are allowed to force readable if executable in posix
11:36:05 <doug16k> spec
11:36:25 <doug16k> x86 can't be executable and not readable, so it falls under that relaxation
11:36:25 <robert_> oh
11:36:50 <robert_> yeah
11:37:49 <robert_> and I can combine the blocks at 95 and 102, yeah?
11:40:00 <doug16k> calculate the protection value then have one call to mprotect with a variable for permission? ya
11:40:20 <robert_> yeah
11:40:52 <robert_> like I can do initialize with all three
11:41:02 <robert_> and then drop them each as tests for each fail
11:42:50 <doug16k> the if inside the else at line 90 doesn't need to indent again. use else if
11:43:20 <doug16k> tab should deliver increasing voltage shocks as it is applied at higher column numbers
11:43:45 <doug16k> have defib around if you are a bad nodejs programmer
11:45:01 <doug16k> hm line 84 should be handling a lot of what I thought was wrong
11:45:11 <doug16k> if(phdr[i].p_type == PT_LOAD) {
11:46:45 <robert_> haha
11:50:30 <doug16k> robert_, you can load the symbols for the image you loaded
11:50:54 <doug16k> add-symbol-file name-of-executable-here address-of-.text-here
11:51:15 <doug16k> add-symbol-file hello-world 0x400000
11:51:28 <robert_> yeah
11:51:33 <doug16k> then do bt and it should be able to backtrace the program you loaded
11:51:42 <doug16k> might be obvious if you see that
11:51:54 <doug16k> problem might be*
11:52:26 <doug16k> program needs to have been compiled with -g though
11:52:43 <robert_> ah
11:52:47 <robert_> yeah