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=2
12:25:43 <klange> bauen1: iirc (it's been several years) empty .SECONDARY will prevent make from removing intermediate files when a *later* rule fails, but not if that rule fails or is interrupted - the latter is what .PRECIOUS does.
12:27:00 * eryjus learned something today; thanks klange
12:29:03 <klange> There's also some weird stuff about how .SECONDARY and .PRECIOUS interpret patterns, so it's easiest to just throw your hands in the air and use empty .SECONDARY which means "everything" over trying to pick and choose.
12:49:51 <geist> yeah i've never used that feature, but it looks like it could be useful, if anything simply as a debugging switch you can turn on
03:33:11 <doug16k> going to patch rdgsbase and wrgsbase if not supported, if only to try out patching code on SMP :) -> https://gist.github.com/doug65536/6b8cc6593fe3f0debe1c8c25462facd7
03:33:19 <doug16k> nothing happens on modern cpu though
03:35:15 <doug16k> becomes call to function that does it by hand with msr or moves
03:35:56 <doug16k> those will trigger a few times then never again
03:36:51 <doug16k> interesting example of what I was saying the other day. the compiler understands those memcpy and uses a single mov that you would want
03:42:33 <doug16k> in the code I ensure they never cross a 16 byte boundary using trick .balign's
03:45:22 <doug16k> I suppose I should add a panic if the instruction begins too close to the end of the 16-byte
03:48:34 <zid> fwiw as long as your memcpy code isn't insane, lto will do it just fine too
03:49:55 <zid> https://godbolt.org/z/ITdYz9
03:50:00 <zid> for example
04:53:27 <gog> https://pastebin.com/TtTgx8QP
04:53:40 <gog> gcc is still generating %edx even though everything is uint16_t
04:54:03 <gog> i feel like i missed something or my abstraction is too much
04:55:06 <gog> p->pdev_base is also uint16_t
04:55:19 <Mutabah> Is it compiling?
04:55:23 <gog> no
04:55:29 <gog> well yes
04:55:31 <gog> it's not assembling
04:55:54 <gog> because for the inb function it generates in %edx, %al
04:55:57 <Mutabah> ... what version of gcc?
04:56:02 <gog> 8.something
04:56:13 <Mutabah> Do you have another version around to try?
04:56:35 <gog> not really but also the dN constraint was working before
04:56:43 <gog> maybe i should check my change history
04:56:54 <gog> i know i've missed something
04:59:51 <Mutabah> Hard-code `%dx` instead?
05:00:40 <gog> probably
05:00:49 <Mutabah> Maybe you have a `.syntax intel` somewhere?
05:00:57 <Mutabah> (Grasping at straws)
05:01:10 <gog> nah .syntax intel has always been a pita
05:01:24 <gog> i tried it and never liked the way it worked
05:01:48 <gog> even though i prefer it i just want gcc to generate the right code ;_;
05:02:08 <gog> ima smoke a cig and then look again
05:02:10 <Mutabah> I was more guessing that it might be emitting "correct" code, but the assembler isn't interpreting it correctly
05:02:21 <Mutabah> Do you have the `.s` file?
05:02:43 <gog> yeah the .S saays inb %edx, %al
05:04:08 <gog> wait nope i found a discrepancy but i need this cig first
05:09:44 <doug16k> gog say the type in the % constraint. %w0
05:10:00 <doug16k> b w k 8 16 32
05:10:55 <doug16k> q 64
05:12:13 <doug16k> it can't mindread what you are doing with it. it is doing what you said, the default whole register. have to say w or b to make it know that you want word or byte (or k in 64 bit code to say 32 bit)
05:12:47 <doug16k> you can scream 16 bit at it all day - that expression is promoted to int at the end of the day
05:13:09 <doug16k> only the % can make it really use the smaller register name
05:15:28 <doug16k> inb should be using Nd constraint too, so it can use immediate constant port for ports <= 0xFF
05:16:29 <gog> for some reason after adding the base and offset of the io ports the value becomes 32-bits to gcc
05:16:41 <gog> i casted the asm operand and it works now
05:16:45 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/ioport.h#L8
05:17:31 <doug16k> gog, C promotion. every expression is at least int. you can jump up and down and beat it over the head with uint16_t but all it will do is say "ok, I'll sign extend that 16 bit thing to int right away"
05:17:55 <gog> yeah that was the hypothesis i developed on my smoke break
05:18:06 <gog> marke that one FIXED
05:18:19 <doug16k> er zero extend for uint16_t. sign extend int16_t
05:18:40 <gog> i learned a valuable lesson
05:18:59 <gog> i don't learn that often lol
05:23:07 <gog> ah hell now i have to port everything to a new interface
05:23:41 <gog> so focused on one piece
05:26:16 <gog> do y'all use clang? its attribute((__naked__)) feature seems useful but i've had trouble with the gcc backend emitting memcpy signals that can't be resolved even with libgcc
05:26:33 <gog> s/signals/symbols
05:26:37 <doug16k> you need to implement memcpy
05:26:51 <gog> maybe it's that time /shrug
05:27:07 <doug16k> C almost can't work without it
05:27:31 <doug16k> eventually you will do an assignment of something big enough for the compiler to call it for you
05:27:56 <gog> well yeah i tried to fix that by including libgcc but i just had to go back to my other toolchain
05:28:09 <gog> s/including/linking i'm sorry i'm drunk rn
05:28:16 <gog> i drunk write kernel code
05:28:16 <doug16k> what arch?
05:28:20 <gog> x86_64
05:28:28 <doug16k> that libgcc is the system one?
05:28:34 <doug16k> it's useless
05:28:35 <gog> nah it's from the toolchain i made
05:28:45 <gog> x86_64-elf
05:28:51 <doug16k> did you make it compile a variation with -mno-red-zone?
05:28:54 <gog> yeah
05:29:04 <gog> i compile with no-red-zone and it gives the right libdir
05:29:08 <doug16k> ok good
05:29:21 <gog> but when link time comes it doesn't work right
05:29:45 <doug16k> the clang one is the system one though eh?
05:29:55 <doug16k> all those libs are not mno-redzone
05:30:01 <gog> yeah it wants to use the one in /usr/lib/whatever
05:30:12 <gog> even though i explicitly give it the one from the bare toolchain
05:30:44 <doug16k> I recommend you don't waste any time with compilers that aren't proper cross compilers. get the proper one working, it doesn't matter if a not-really-working compiler builds it
05:31:13 <gog> but i want attribute((__naked__)) so i can have first-level ISRs in C ;_;
05:31:22 <doug16k> you need memcpy if you are going to do the slightest thing
05:31:45 <doug16k> ew
05:32:03 <doug16k> then a bunch of string literals eh?
05:32:17 <gog> if you think that's ew you should hear my idea about self-modifying code to make ISRs
05:32:32 <gog> i thought of it and immediatly cringed
05:32:51 <doug16k> put significant blocks of assembly in assembly source files and assemble it
05:33:02 <gog> yeah that's what i do already
05:33:12 <doug16k> you can #include in as
05:33:22 <doug16k> __ASSEMBLER__ is predefined
05:33:28 <gog> yes yes i know i just have this picture of what i want
05:33:40 <gog> and gcc doesn't always render that picture in my vision
05:33:42 <gog> and it can't
05:34:36 <gog> what if michelangelo had to deal with gcc huh /s
05:34:48 <doug16k> if you want to do interrupt handlers use __attribute__((interrupt))
05:35:06 <doug16k> that will be less bad than a bunch of inlined assembly in a naked function
05:35:20 <doug16k> it won't save fpu state though on x86(_64)?
05:35:49 <gog> ohshi i forgot that attribute was added to gcc
05:36:08 <doug16k> I don't recommend that either but I recommend it over naked anyday
05:36:40 <gog> will it do iretq in 64-bit mode? i feel lik this needs an expieriment
05:36:58 <doug16k> it'a okay for what it says on the tin: interrupts. it's useless for context switching
05:37:01 <doug16k> I think so
05:37:22 <gog> i just want it for some supervisor mode interrupts
05:37:35 <doug16k> if they don't push error code, no problem
05:37:40 <gog> direct ones that aren't going to schedule anything
05:37:55 <gog> yeah anything that pushes an error code except page faults will probably be deferred
05:38:22 <doug16k> page fault would need to know a lot about the caller, probably shouldn't hack __interrupt__ attr for that ya
05:38:34 <gog> nah that's gonna have its own asm file
05:38:41 <gog> too important
05:39:17 <gog> and any other exceptions that the kernel should care about
05:39:37 <gog> #GP naturally
05:44:30 <doug16k> https://godbolt.org/z/fa2dKv
05:45:07 <gog> oh wow
05:45:12 <gog> useful
05:45:28 <doug16k> saves just enough https://godbolt.org/z/QG0VVQ
05:47:17 <gog> this is easier than invoking a gcc -S all the time lol
05:47:32 <gog> also when did 8.3 come out wtf
05:48:13 <gog> lol february wow my toolchain is old
05:48:14 <doug16k> you can add additional compiler windows there too with different compilers or command line options btw
05:48:32 <doug16k> and drag them around!
05:48:39 <gog> that's pretty cool and useful af
06:02:34 <doug16k> notice I had to add -mgeneral-regs-only command line option. I recommend you do that across your entire kernel. it may eventually try to vectorize or something if you don't
06:03:22 <doug16k> it will go "oh! I'm so smart I could just do 3 xmm stores for that and the user will be so happy that I wrote fast code automatically!"
06:04:54 <doug16k> unhappy user didn't setup OSMMEX or OFXSR yet. #UD exception
06:05:16 <gog> well i don't anticipate many users for my OS lol
06:05:21 <gog> but it's not bad advice
06:05:25 <doug16k> you are the user
06:05:30 <doug16k> of the compiler :)
06:05:43 <gog> the compiler uses me i think
06:07:19 <doug16k> I also set the preferred stack alignment to 8 because it doesn't care about 128-bit operands, ever
06:07:44 <doug16k> eliminates a lot of forced-in adjustments of the stack pointer
06:09:17 <doug16k> on x86_64 abi, the default has 16-byte stack alignment requirement before calling a function. that means that on entry to a function, the cpu pushed 8 bytes, so it is guaranteed misaligned. the codegen has to push an odd number of registers, and if it can't and it is even whether it likes it or not, then it will have to sub 8 from rsp
06:09:43 <doug16k> then, on the way out, it will have to account for that 8
06:10:20 <doug16k> same on i386 btw, since it too has sse
06:10:39 <doug16k> you can relax that to 8-byte on x86-64, or 4-byte on i386 and get some code density improvement
06:12:41 <doug16k> requires -mgeneral-regs-only though. if you don't, then your stdarg code (printf) has a 50% chance of crashing due to use of movabs to misaligned stack
11:06:53 <zid> gcc also has attribute((interrupt)) for x86 now
11:07:08 <zid> which again, needs mgeneral-regs-only as it has no path for saving/restoring sse etc
11:07:19 <lkurusa> about time gcc got it lol
11:07:23 <zid> ikr
03:50:09 <izabera> would it be useful to freeze the entire state of a program for later use?
03:50:22 <izabera> like, not for hybernating purposes or anything
03:50:40 <izabera> just freeze a random program now, reopen it later and find all your work still in place
03:50:45 <bcos> Like, if it crashes (and you want to freeze it while starting a debugger or doing a core dump)?
03:51:15 <izabera> not in case of crashes
03:54:48 <izabera> i mean criu is a thing on linux
03:54:56 <izabera> it would be nice if the os provided it by default
03:56:10 <bcos> Hrm
03:56:49 <bcos> The freezing part is mostly worthless for normal apps (they just get stuck waiting for keyboard/mouse events and not consuming any CPU time anyway)
03:57:08 <bcos> The "checkpoint to persistant storage" is..
03:57:17 <bcos> ..I don't know.
03:57:40 <bcos> Probably only useful if the app crashes, but then you'd be restoring it to a point just before it crashes, so it's hard to see the point
03:58:14 <bcos> ^ maybe to guard against unexpected power failures (e.g. no "shutdown safely" and no UPS)
03:59:37 <bcos> ..but even then it'd make more sense doing an automated "save the file like normal, but give it a *.bak" extension" every 5 minutes
04:02:21 <bcos> Note: various hardware/software developers think persistance is cool and propose things like "persistent objects" and non-volatile RAM; but I don't think any actual users want this - they want "reboot to restore everything to sane default state" (the old "did you try turning it off and on again" thing that's the first step in fixing all kinds of problems)
04:03:09 <bcos> I guess what I'm wondering is; are things like CRUI a solution looking for a problem?
04:03:14 <bcos> *CRIU
04:04:29 <bauen1> btw, you can now look at my build system at https://gitlab.com/myunix/myunix/
04:05:28 <bauen1> according to gitlab my repo is now 22.1% makefile :,(
04:05:36 <bcos> :-)
04:06:03 <bcos> Just add some documentation that describes how the makefile works!
04:06:43 <bauen1> yes ...
04:06:52 <bauen1> actually there are a few lines of comments somewhere
04:07:51 <bcos> Ah - delete the comments - see if gitlab says "22.0% makefile" :-)
04:08:12 <bauen1> lmao
04:17:23 <mischief> bcos: i think criu came out of openvz
04:17:36 <mischief> for things like hot migration
04:22:01 <bcos> For virtual machines (without any users) it makes sense I guess (but that excludes "applications")
04:23:28 <mischief> openvz isn't virtual machines
04:23:41 <bcos> Erm. What's it for then?
04:23:50 <mischief> it's more like early linux containers
04:23:53 <zid> opensource pencilcase visualizer
04:24:21 <bcos> Let's just define "container" as "light-weight virtual machine" then?
04:24:39 <mischief> https://en.wikipedia.org/wiki/OpenVZ#Checkpointing_and_live_migration <-- that part uses criu
04:24:40 <bcos> ..in the same way that I'd define "process" as "even more light-weight virtual machine"
04:25:24 <zid> In the same way I'd define a human as a featherless biped
04:46:45 <bauen1> am i understanding the multiboot 2 specs correctly: every tag provided **to** the operating system will only appear once (unless specified otherwise for eg. module) ?
04:46:48 <bauen1> https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html
04:47:16 <bcos> Sounds right to me..
04:47:31 <bauen1> nice, it would be a pain to support more than one memory map
05:13:58 <bauen1> so i just learned about -Wwrite-string which warns you when you're doing stuff like `char *s = "hello";`, why is this even allowed in C and why isn't that warning enabled with -Wextra ....
05:17:13 <zid> It's not allowed to in C
05:17:34 <zid> any code relying on it is not strictly conforming C
05:18:22 <bauen1> yeah, but gcc doesn't bother enableing that warning, not even with -Wextra, i'm pretty sure these issues have already wasted way too much valuable programmer timer
05:18:41 <zid> It does it in a non-standard manner
05:18:52 <zid> it *changes* the type of string literals
05:19:00 <zid> so that it can later find the behavior
05:19:17 <zid> " These warnings help you find at compile time code that can try to write into a string constant, but only if you have been very careful about using const in declarations and prototypes. Otherwise, it is just a nuisance. This is why we did not make -Wall request these warnings."
05:20:34 <bauen1> still, it isn't in -Wextra either
05:22:05 <zid> submit a feature req for it
05:23:06 <bauen1> i'd it if my first patch would be roasted by linux himself
05:23:19 <zid> what
05:23:56 <bauen1> i guess i could
05:24:15 <zid> no seriously, what
05:24:25 <bcos> Roasted by Linus?
05:24:28 <zid> I would it if my first
05:24:41 <bauen1> s/i'd/i would prefer/
05:24:43 <bauen1> i can't english
05:44:39 <w1d3m0d3> c++ references are just implemented as pointers right? aka in the assembly a reference and a pointer are the same?
05:45:12 <zid> depending on what its doing with it, presumably
05:45:21 <zid> I don't know the full semantics of references, you could always check with godbolt
05:45:29 <w1d3m0d3> good idea
05:47:09 <w1d3m0d3> yeah it's just that
07:12:18 <geist> zid: fairly certain that's not right. there's some old carveout in the C language that lets you do exactly that
07:12:48 <geist> more specifically "strings" aren't const char * i believe
07:13:12 <geist> at least in older specs of the language, that may have been fixed in later ones. it's probalby because const was added much later in the language
07:13:30 <geist> so original basic things like a string literal were already defined
07:13:53 <geist> hence why it's not in the basic set of extended warnings
07:17:08 <geist> https://en.cppreference.com/w/c/language/string_literal doesn't mention const char there. it says string literals are char, however they're not writable
07:17:11 <zid> geist: Code exists that modifies them due to pre-ansi C, so you can't really stop supporting it, but they're not mutable per C
07:17:24 <zid> -Wwrite-string *makes* it const, which the spec says it isn't
07:17:30 <zid> in order to detect the writes
07:17:52 <zid> (That and there's nothing stopping me just putting it outside of a read only section)
07:18:05 <geist> indeed. but my point is that that's why the warning doesn't exist by default
07:18:23 <zid> the warning doesn't exist by default because it isn't specified to cause one, intentionally or otherwise
07:18:38 <zid> and making it cause one by changing it to const is non-standard
07:18:41 <geist> well, no because char *a = "foo"; is perfectly valid c
07:18:58 <geist> correct. hence why the warning isn't enabled by default
07:18:59 <zid> of course it is, string literals aren't const pointers
07:19:10 <geist> i think we're just talking in certains
07:19:18 <zid> correct
07:19:19 <geist> circles even (why did i type that?)
07:19:50 <geist> ah i guess it was bauen1 that originall brought it up
07:20:10 <zid> yes, I was saying things you then tried to correct me on, so I just re-iterated
07:39:27 <stisl> hi
07:40:03 <stisl> I am trying to debug my bootloader with qemu
07:40:25 <stisl> but it will not link to the sourcecode
07:40:33 <stisl> only a disassembly view is available
07:40:53 <geist> ooooh paging dr doug16k
07:41:26 <stisl> and I am using it with UEFI eclipse
07:41:44 <stisl> qemu-system-x86_64 -bios OVMF.fd -vga std -drive id=disk,file=usb.img,if=none -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0 -smp 4 -m 1024M -serial udp::4555 -device piix3-usb-uhci -device usb-mouse -s -S
07:42:41 <stisl> $(LD) -Og -Bsymbolic -shared -image-base 0x100000 --oformat pei-x86-64 --subsystem 10 -pie -e _start crt0.o reloc.o kloader.o -o kloader.efi
07:43:29 <stisl> and for the gcc targets I use -ggdb
07:44:13 <stisl> it looks like that there is some debug-information not compiled in
07:44:51 <stisl> with eclipse I can connect only to the disassembly view
07:45:00 <stisl> with Qt-Creator nothing works
07:47:09 <stisl> how can I tell gcc to compile the needed debug-sections in? or which debug sections do I need?
07:47:44 <geist> the PE binary may be the problem. PE stuff does debugging in a completely different way, at least on windows
07:48:00 <geist> From what I understand the debugging stuff is usually in a separate file. Dunno if gcc/ld/etc can generate it properly
07:48:58 <geist> if it were an elf target the debugging gets glommed inside the same thing with some debugging sections
07:50:16 <geist> anyway, it's just a hypothesis and I dont really know, but it could e that you have to figure out how to get the linker to generate an external debug file, and then see if gdb can use it
07:50:52 <stisl> ok, thanks I can try it
07:51:10 <geist> it may be the toolset you have simply can't deal with PE debugging files though, since it's not an ELF binary which it's used to doing
07:51:32 <geist> you may actually have better luck debugging from a windows debugger somehow
07:51:45 <geist> though you still have to make sur eyou link and generate the appropriate PE debug stuff (in whatever form that is)
07:52:02 <stisl> :(
07:52:13 <stisl> can I not do some objconv magic or sth. like this?
07:52:17 <geist> doug16k may have more info here, since he uses the debugger. I basically never use gdb for debugging, so i have very little experience with it
07:52:40 <geist> well, that may be another strategy. i think it is possible to link an ELF file and then objcopy it into PE
07:52:52 <geist> i've seen it done, i think, so i think it's possible
07:52:57 <mischief> yes, that's how edk2 works iirc
07:53:19 <geist> if that was the case and the objcopy doesn't change the fundamental layout of the file,then you could hypothetically use the ELF file's debugging stuff
07:53:41 <geist> the other problem you'll have there i believe is UEFI will load the file anywhere, so there's some relocation stuff to deal with
07:53:51 <geist> but i dont personally know
07:54:27 <stisl> the relocation is done on startup I can set a breakpoint in efi_main
07:54:49 <geist> okay
07:55:46 <stisl> does anybody have some linker script which is compiling the needed sections in?
08:36:50 <doug16k> stisl, you need to compile the source files with -g
08:37:16 <doug16k> the link will include whatever debug info ends up in the object files without asking for it
08:37:46 <stisl> doug16k, ah, this I have forgotten, I will try this
08:38:00 <doug16k> stisl, use Attach to Remote Debug Server... and put your kernel executable in there where it wants the executable name
08:38:20 <stisl> thanks a lot
08:38:25 <doug16k> s/Remote/Running/
08:38:41 <stisl> i will try this from commandline first
08:38:54 * doug16k nods
08:39:33 <doug16k> stisl, oh, this is pe executable? for that I also link an elf executable and point gdb at that
08:39:45 <gog> __attribute__((interrupt)) is p helpful it even saves registers for u
08:39:48 <stisl> yes I do actualy the same
08:39:49 <doug16k> it will be same-enough
08:40:50 <stisl> doug16k, now it looks good
08:41:07 <doug16k> nice
08:41:38 <stisl> nice I can see the source
08:41:54 <stisl> but then it terminates after the relocation
08:42:12 <stisl> maybe I can do it without relocation
08:43:48 <doug16k> you can force debug symbols to be adjusted to a different address. is that what you needed?
08:44:14 <stisl> it also terminates without relocation
08:44:39 <stisl> I don't know
08:47:31 <stisl> gdb is saying: "Cannot find bounds of current function"
08:47:52 <doug16k> assembly files need -g too to get debug info
08:48:04 <doug16k> do layout asm to see where you are
08:48:20 <doug16k> where is it?
08:48:40 <stisl> nasm -g -f elf64 $^ -o $@
08:49:08 <doug16k> should work but I rarely use nasm nowadays
08:50:09 <doug16k> if it says that then it is because you said to "line step" and it has no line number information for where it is right now
08:50:23 <stisl> ah, ok
08:50:30 <doug16k> if you think it is okay where it is you can place a breakpoint somewhere interesting and continue
08:50:43 <doug16k> b some_function
08:50:51 <doug16k> b somefilename.c:42
08:51:32 <doug16k> si is step instruction. always works
08:51:42 <stisl> Child terminated with signal = 0xb (SIGSEGV)
08:51:46 <stisl> under eclipse
08:58:24 <stisl> qemu-system-x86_64: Trying to execute code outside RAM or ROM at 0x00000000000b0000
08:58:40 <stisl> ?? VGA?
09:00:55 <gog> you can note in your assembler file the size of symbols
09:01:08 <gog> then GDB will be a little less unfriendly
09:01:09 <doug16k> stisl, 32 or 64 bit?
09:01:21 <stisl> 64 bit
09:01:26 <stisl> always
09:01:42 <doug16k> do this to see how it got there if you're lucky: x /1wx $esp
09:01:56 <stisl> ok, thx
09:01:57 <doug16k> that will tell you the return address if it called there
09:01:59 <stisl> not rsp?
09:02:08 <doug16k> ya rsp sorry
09:02:19 <stisl> ok, thx
09:02:37 <doug16k> or, if that doesn't help, increase the 1 to a higher number and see if anything looks like a return address
09:02:57 <stisl> -g3?
09:03:04 <doug16k> if you're lucky some residual of a call is there on the stack that may point you vaguely in the right direction
09:03:10 <doug16k> g3 might help
09:04:55 <doug16k> good trick is to put an infinite loop very early on in your efi program. let it get there and hang, then break into gdb. you'll be in your code in a nice place if it works out
09:05:17 <doug16k> then you can assign a value to $rip to force the cpu past the loop, and continue
09:06:05 <doug16k> easier method is do do: int volatile hang = 1; while (hang);
09:06:17 <doug16k> then in gdb when you break in: set hang=0
09:06:17 <doug16k> c
09:06:45 <doug16k> or step, or whatever instead of continuing
09:08:28 <doug16k> if you have it loading at the right address you can just place a breakpoint early and it should hit it and debug perfectly. I debug uefi source level just fine, nothing special done
09:09:25 <doug16k> when I was in the "I don't even know if EFI loaded it!" phase, the infinite loop trick helped
09:10:32 <doug16k> I think I left in the print of efi_main = 0x.... in my code too
09:11:10 <doug16k> if ovmf suddenly gets inspired to behave differently I can see if it loaded where I assumed (where I told gdb the symbols point)
09:20:17 <stisl> re
09:23:36 <stisl> I can debug a little bit now, but it still crashes
09:25:39 <stisl> I removed the nasm file in order to get a clean debug object
09:26:28 <stisl> under eclipse I can see the sourcecode but not under the commandline with layout src
09:26:40 <doug16k> I have no idea whether nasm does the debug info correctly or catastrophically wrong
09:27:05 <doug16k> I vaguely remember it not really working but I could be mistaken
09:27:18 <stisl> there are some bugs with nasm debug infos
09:27:45 <stisl> the line information is not handled correctly
09:28:05 <stisl> also with -F gdwarf or sth. like this
09:28:25 <doug16k> well, then all the information is not correct then :) all you want from assembly debug info is line numbers
09:28:45 <doug16k> other than that it is clueless. you can look at register window, etc
09:30:08 <doug16k> the symbols for labels need to work for the object file to work at all
09:30:25 <stisl> I hope I can improve the kernel debugger so that it will work with hardware breakpoints
09:30:44 <stisl> then I can debug directly on the target
09:30:52 <doug16k> you have a custom kernel debugger?
09:31:00 <stisl> I am writing currently one
09:31:09 <stisl> with an asm and disasm engine
09:31:23 <stisl> and some elf-disassembler
09:31:27 <doug16k> I implemented a gdbstub
09:31:39 <stisl> I tried to integrate it
09:31:49 <doug16k> but what you did/doing is cool too
09:32:24 <stisl> :) currently it crashes with the new bootloader
09:32:44 <doug16k> stisl, I have hardware breakpoints if you want to peek at the inline asm etc
09:33:02 <stisl> that would be nice
09:33:23 <doug16k> it's a bit trickier than normal because debug registers have to be hardcoded, can't access Nth one easil
09:33:26 <doug16k> y
09:34:17 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/control_regs.h#L209
09:34:17 <stisl> I only now how to debug with hardwre breakpoints because of my embedded background
09:34:49 <doug16k> and, https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/control_regs.cc#L10
09:36:05 <doug16k> if using C just make 4 versions of cpu_debug_breakpoint_set_0 thru cpu_debug_breakpoint_set_3 instead of <0>
09:36:22 <doug16k> and hardcode
09:36:47 <doug16k> (instead of using compile-time-constant template parameter)
09:37:09 <stisl> ok
09:38:16 <doug16k> in C you can use __builtin_constant_p(index) and if it is true, it is a compile time constant parameter and do what my template one is doing
09:38:44 <doug16k> otherwise it has to pick from a list of hardcoded mov instructions to use mov to/from drN
09:39:07 <doug16k> hopefully I wasn't confusing
09:39:40 <stisl> I tried to work with the dr3 register and so on
09:40:01 <stisl> but with little success at the moment ;)
09:40:22 <doug16k> note that in qemu, without enable-kvm, every breakpoint is a hardware breakpoint
09:40:35 <stisl> ah
09:40:51 <doug16k> it doesn't poke software breakpoints into it. it's emulating - emulator has magically large limit on hardware breakpoints
09:40:52 <stisl> kvm is really unstable on my machine
09:41:06 <stisl> but it shows more bugs
09:41:17 <doug16k> I doubt it is kvm's fault
09:42:02 <doug16k> I suggest believing it is all your fault until you have good evidence it is kvm
09:42:44 <stisl> I don't like to run so much things in the kernel space
09:42:48 <doug16k> this is half the fun of osdev right? almost-impossible-to-find bugs
09:43:31 <stisl> what I really like with osdev is when you try to port a program to your os you can see if it is really stable
09:43:44 <stisl> or if your os is stable
09:44:09 <stisl> mostly I program a console or desktop application first and then I port it to the os
09:44:38 <doug16k> I tend to run torture tests on stuff so it is usually decent by then for me, but definitely still lots of bugs can still be there
09:45:31 <stisl> when I test mostly the smallest code wins
09:46:11 <stisl> if the problem is not to hard
09:46:18 <stisl> +o
09:46:56 <stisl> that is whý I like small ocde, when it is also not cryptic
09:48:02 <doug16k> going to try connecting to qemu with my project in it from eclipse. hopefully you found qemu actually segfaulting in gdbstub and I can fix it :)
09:48:45 <stisl> the gdb integration of eclipse is one of the good things in eclipse
09:49:08 <stisl> a ot of embedded developers integrated some debuggers
09:50:31 <stisl> can you write to the harddrive with your os?
09:52:58 <doug16k> yes
09:54:19 <doug16k> I have FAT32 and ISO9660 with full long name and unicode, on ide/ahci/nvme/virtio/usbstorage
09:55:21 <stisl> nice
09:57:18 <stisl> the approach for the os I develop is to integrate some kind of IDE in it so that you can program / debug live
09:57:53 <doug16k> on the same machine? is that really feasible? for some things it can't work
09:58:29 <doug16k> if that's ok, go for it
09:58:52 <stisl> yes you can not make a breakpoint everywhere
09:59:21 <stisl> but everything runs as a thread
09:59:42 <stisl> maybe some kind of lightweight virtualization could do it in the future
10:00:16 <doug16k> in my gdbstub, you can put a breakpoint anywhere
10:00:45 <stisl> I could do it in the future also when it supports SMP
10:00:57 <doug16k> the stub forks off a clone of the entire kernel and has its own code and data and everything
10:01:37 <doug16k> now you can put breakpoint wherever and no problem. right at entry to debug exception? no problem, that's the kernel's copy not the stub's
10:02:28 <doug16k> I mean software breakpoint in this case. the 0xCC opcode. aka INT3
10:02:39 <stisl> ok, understand
10:03:21 <doug16k> my approach isn't that great either because it dedicates a cpu to debugging
10:03:32 <doug16k> but in exchange for that I get some neat capabilities
10:04:39 <doug16k> normally you push your luck and use the same cpu for debugging and the guest, relying on the cpu seizing control periodically or somehow using IRQs to get back into the stub code