IRC channel logs

<gnucode>damo22: how much of your time is spent in assembly these days?

<damo22>uh too much

<azert>damo22: not sure I understand your question? You cannot store a far address in a register in x86

<azert>You have to use memory, or the stack

<damo22>yes you can

<damo22>you cant dereference the 32 bit memory address in real mode, but you can store the address to a 32 bit register

<damo22>you just have to force gas to use 32 bit addressing for that single instruction

<damo22>(09:05:27 AM) damo22: addr32 movl trampoline_start, %eax

<damo22>its a neater trick than what linux does

<damo22>demo@zamhurd:~/git/gnumach/build$ as

<damo22>.code16

<damo22>addr32 movl 0x12345678, %eax

<damo22>demo@zamhurd:~/git/gnumach/build$ objdump -M i8086 -D a.out

<damo22>...

<damo22>00000000 <.text>:

<damo22> 0: 67 66 a1 78 56 34 12 addr32 mov 0x12345678,%eax

<youpi>damo22: in real mode you only need the 16bit address

<youpi>since you're in the same segment, you don't need more

<damo22>no, its more complex, the 32 bit address is only used once it is in protected mode

<youpi>yes

<youpi>but for the beginning you can use just 16bit address

<damo22>you need to store the full 32 bit address somewhere so you can use it later

<youpi>you don't need that initially

<youpi>you just need to know where things are to be able to use lgdt etc.

<damo22>but you can also use addr32 lgdtl

<youpi>and "where" at that point is just a real address

<damo22>you can load a 32 bit address with a gdt in real mode

<youpi>but what for?

<youpi>the only issue we have is lgdt M(gdt_descr_tmp)

<youpi>where M currently has a constanta that we want ot make a variable

<damo22>so you dont have to know which offset is the gdt pointer

<youpi>but that's fine, it's just a 16bit address

<damo22>gdt_tmp needs to be updated too

<youpi>the content of gdt_tmp ?

<damo22>yes

<youpi>? no

<damo22>it needs the offset

<youpi>it's just the plain linear = physical segments

<youpi>what offset?

<damo22>gdt_descr_tmp:

<damo22> .short 3*8-1

<damo22> .long M(gdt_tmp)

<youpi>that's why I asked "the content of gdt_tmp"

<damo22>sorry

<youpi>that needs to be fixed, yes, but you can do that easily from C

<damo22>why not use the 32 bit address of gdt and load it directly from real mode then you dont need to mess with it

<damo22>addr32 lgdtl 32_bit_address

<youpi>? you can't load 32bit address while you're still in real mode

<damo22>i think the lgdtl instruction supports that, let me check

<youpi>until you have defined a page table and segments, that does not have sense

<damo22>ok

<damo22>but linux does this:

<damo22> /*

<damo22> * GDT tables in non default location kernel can be beyond 16MB and

<damo22> * lgdt will not be able to load the address as in real mode default

<damo22> * operand size is 16bit. Use lgdtl instead to force operand size

<damo22> * to 32 bit.

<damo22> */

<damo22> lidtl tr_idt # load idt with 0, 0

<damo22> lgdtl tr_gdt # load gdt with whatever is appropriate

<youpi>I don't know about that

<youpi>my point is that it's not needed

<youpi>you can just load the gdt from the 4K page in which you have the apboot code

<damo22>sure, i can patch it in 16 bit

<damo22>but i need the offset

<youpi>which offset?

<damo22>to the start of apboot

<youpi>you know it

<damo22>the trampoline_start offset is computed at compile time, its in a 32 bit section

<youpi>aiui apboot is at 0 in the segment

<damo22>ohhh

<damo22>that makes more sense

<damo22>so #define M(addr) (addr - apboot + 0)

<youpi>actually it can even *not* be anything else if your adress is dividable by 64k :)

<youpi>ah, perhaps you still have the offset between page alignment and 64k alignment

<youpi>but then, really, making the C code do dynamic linking by just putting the right address into the content of a mov instruction, is really simple

<youpi>just put a mov instruction with a random address, see what bytes that emits, and put these bytes instead of the mov, and a label before the address within the instruction, and you'll be easily able to update that from C

<youpi>of course .text needs to be turned into .data, but that's really not a problem

<youpi>(in order to be able to modify th econtent)

<damo22>i dont understand that part

<damo22>but let me try what i have

<youpi>what part?

<damo22>dynamic linking

<youpi>I'm putting 32bit code because that's what I have at hand, but the principle is the same in 16bit mode

<youpi>c100bddd: 8b 1d 40 bd 00 c1 mov 0xc100bd40,%ebx

<youpi>that's from a movl instruction

<youpi>you can clearly see the encoded address

<youpi>so you replace that with .byte 0x8b, 0x1d ; address: .long 0

<youpi>and just write to `address` the actual address you want

<youpi>(for 16bit replace with whatever bytes you actually get, and .long with .word)

<damo22>oh ok

<youpi>that's basically waht dynamic linking does

<damo22>what do i need that for

<youpi>to make the apboot code read the actual pointer from the variable

<youpi>so it knows where it lives

<youpi>and then is able to lgdt from there, etc.

<youpi>well, actually you don't even need to read from the variable

<youpi> you can as well use a movw $0,%eax

<youpi>and replace the $0 with the actual address

<youpi>even simpler

<damo22>but i made a compile time 32 bit symbol readable in 16 bit mode

<youpi>I don't understand why

<youpi>until you have achieved lgdt, you cannot use 32bit addresses

<damo22>ah yes

<damo22>can i show you my current patch that almost works?

<damo22> https://git.zammit.org/gnumach-sv.git/commit/?h=fix-ioapic&id=7b765c20eba4a31c943843f739d7bd8df96dbb4a

<youpi>I really need to go to bed

<youpi>I don't understand most of it

<youpi>I don't see why using idt

<damo22>ok

<youpi>you probably wanted to use $ before trampoline_start, otherwise it'll be *reading* a poniter at trampoline_start

<damo22>next time

<damo22>ohhh thanks

<youpi>and as I said, you can just put a movl $0, %edx

<youpi>tinker it to replace $0 with whatever address was allocated (e.g. 0x7000)

<youpi>and make the code compute from that instead of using the M macro

<damo22>oh and write it from c code?

<youpi>vm_page_grab_contig(PAGE_SIZE

<youpi>no you want pmap_grab_page

<youpi>yes

<damo22>pmap_grab_page does not alloc from low memory

<damo22>i got an address just below 2GB

<youpi>? it uses biosmem_bootalloc

<youpi>ah, it takes from the heap :/

<damo22>yes

<youpi>useing vm_page_foo then vm_page_to_pa is tedious

<youpi>you can probably just ask biosmem directliy

<damo22>ok goodnight

<damo22>thanak you

<damo22>thank*

<youpi>note that everything I say should be taken with a grain of salt, I haven't been looking at the code for possibly a decade

<youpi>I'm just saying waht I can remember

<youpi>you probably want to put the phys address in apboot_addr

<youpi>that'll probably lead to less kvtophys calls, and not many more phystokv calls

<damo22>yep

<damo22>heh code is readonly

<damo22>darn

<damo22>hmm the .data section is not within apboot -> apbootend so that would not be copied

<damo22>therefore it cannot be relocated to a 16 bit segment

<damo22>how do i define a data block that is at a known absolute offset and is 16 bit addressable?

<damo22>can i nest a .data section inside a .text section?

<damo22>it needs to be near the .text section

<damo22>gnumach/build/../i386/i386/cpuboot.S:131:(.text+0x227fc): relocation truncated to fit: R_386_PC16 against symbol `apboot_addr' defined in .bss section in gnumach.o

<anatoly>Shouldn't be in the same segment, so in total code + data should not be longer than a segment?

<damo22>how do i create a mutable variable near the .text section?

<damo22>in real mode you can self-mutate code i think, but not in protected mode

<damo22>basically i need to pass a variable from BSP to AP real mode

<damo22>maybe i need a second page of ram for data

<youpi>damo22: put the whole thing in the .data section

<youpi>that's what I meant by ".text need to be turned into .data"

<youpi>just replace .text with .data

<damo22>ahh

<damo22>a .globl asm symbol, is it a pointer to the location after the label?

<damo22>im getting confused how to use it from C code

<damo22>so .globl makes a symbol available to the linker from ASM, you can define the symbol as an ASM label if you wish and then C code can use it directly?

<etno>damo22: i think so

<etno>But the model does not handle segmentation other than something flat

<damo22>hmm my problem now is that sending the IPI to wake up the AP crashes the AP

<zamfofex>sneek: later tell solid_black: I’ve been reading the logs, and I decided to join to to tell you: Thank you for porting Ladybird! I’m definitely not competent enough to help with anything beyond cheering, but I’ve been enthused about both the Hurd and Ladybird, so I’m looking forward to using them as my daily drivers in future years (or months)!

<sneek>Okay.

<zamfofex>sneek: later tell solid_black: Also, about your “Hurd distro” endeavors, have you considered trying to use pkgsrc for it? It might contain fewer Linux‐specific things.

<sneek>Got it.

<youpi>damo22: you can run in qemu to catch the fault and see what state the AP is in

<solid_black>hello!

<sneek>Welcome back solid_black, you have 4 messages!

<sneek>solid_black, gnucode says: I have a VERY basic website set up for you. https://notabug.org/jbranso/craggy-hurd

<sneek>solid_black, gnucode says: You just need to clone the repo, install emacs, run ./render-locally, and you should be able to generate the website.

<sneek>solid_black, zamfofex says: I’ve been reading the logs, and I decided to join to to tell you: Thank you for porting Ladybird! I’m definitely not competent enough to help with anything beyond cheering, but I’ve been enthused about both the Hurd and Ladybird, so I’m looking forward to using them as my daily drivers in future years (or months)!

<sneek>solid_black, zamfofex says: Also, about your “Hurd distro” endeavors, have you considered trying to use pkgsrc for it? It might contain fewer Linux‐specific things.

<solid_black>zamfofex: I haven't considered pkgsrc, no

<solid_black>but it's way too lare to change that; this distro is already built on Alpine, basing it on something else would mean starting over

<solid_black>does pkgsrc only ship "third party" software on top of a base system, or does it ship everything down to libc and kernel?

<gnucode>well I am compiling the latest netsurf, which apparently supports CSS flexbox.

<gnucode>I tried to get my website gnucode.me/craggy-hurd/ to render solid_black's new Alpine based Hurd distro website.

<solid_black>403

<gnucode>I am making the site from scratch based on org-mode, I can render it locally, but it would be nice for others to see it.

<solid_black>but I did render and view your website locally

<gnucode>solid_black: yeah, I'll fix my website at some point. guix deploy is failing me for some reason. :(

<gnucode>solid_black: It is super super basic at the moment.

<solid_black>I saw that, yeah

<solid_black>but it's better than nothing

<gnucode>hahaha. I'm thinking about having a Downloads page with a torrent link.

<solid_black>I should probably push this week's work, and post an update on the mailing list

<solid_black>we don't yet have much to download :)

<gnucode>solid_black: how about I blog about your upcoming site on gnucode.me? I can republish your original mailing list annoucment.

<gnucode>It'll basically be inviting people to help build the project.

<solid_black>sure, sounds like a great idea

<solid_black>fwiw, the current status is

<gnucode>sweet. I'll send you the draft blog post before I publish.

<solid_black>some more things build

<solid_black>it boots with init=/bin/sh and things ✨️just work✨️, you can 'apk add' bash gcc etc etc

<solid_black>OpenRC starts booting and then hangs, it's unclear why

<gnucode>actually you can already see the blog post... that I am working on.

<gnucode>It's the "Why Alpine" article that I am working on for "craggy-hurd" (working name).

<gnucode>nice progress.

<gnucode>ok. I got to run to get ready for work. See ya'll later.

<zamfofex>solid_black: I don’t think pkgsrc includes the kernel and libc, no. Do you share your work somewhere I could see? (Ladybird and your distro, I mean.)

<solid_black>the distro's aports fork is at https://github.com/bugaevc/aports/blob/hurd/README.hurd.md (currently being updated, I'll push soon)

<solid_black>the Ladybird chages are upstream :)

<zamfofex>I see! Very good! 🎉

<damo22>youpi: i did that yes, and it hard reset the AP so it had everything in zero state and EIP = 0xfff0

<damo22>i need to check if the GDT is being loaded correctly

IRC channel logs

2024-01-27.log