<gorgonical>
another mystery afoot: an error in the pa_addr function for arm64 in my kernel, but we aren't sure why. the value 0xffffffc000082700 goes in, and and the value 0xffffffc000000000 is the start of the kernel map, and the physical offset is 0xaf000000, so we should be getting 0xaf082700, but instead we get some sign-extending and get 0xffffffffaf082700 instead. A look at the dump doesn't realllly show
<gorgonical>
why this would be happening. I can post the pastebin of the code and the dump
<gorgonical>
Are there any gotchas or similar I should be aware of?
<bslsk05>
pastebin.com: Disassembly of section .text.__phys_addr:ffffffc0000878b0 <__phys_addr>:ff - Pastebin.com
smeso has joined #osdev
<zid>
looks like it's asking if your kernel map is below ffffffbfffffffff and everything else uses the default path
<gorgonical>
This is the code dump from a version with only one printk call, before I got super paranoid
<zid>
which is to subtract some number, making it slightly negative
<zid>
but I don't read whatever ISA this is and I didn't read it hard
<gorgonical>
this is arm64
<zid>
k
<gorgonical>
Sorry for not mentioning that
<zid>
I still don't read it :P
<zid>
that ffffffbfffffffff constant is screwy given what you described it should be doing, anyway
<gorgonical>
I actually think that's not at fault. We're checking if virt_addr >= 0xfffffc00... and so that is one minus that
<gorgonical>
And it's checking less or same with b.ls
<zid>
ah arm is just silly that's fine then :P
<gorgonical>
What I don't understand is the mov 0x4000....
<zid>
ldr x0, [x20, #1536] what's this guy?
<gorgonical>
Because the op is supposed to be a subtract, but gcc has optimized to only adds?
<gorgonical>
I think that's loading either start_kernel_map or phys_offset, I can't really tell which one since it might re-order them
<zid>
lea x0, [x20+1536] looks mighty strange
<zid>
mov, whatever it is
<gorgonical>
Well I know it's loading one of those actually, but the I think part is which one
<zid>
I'm just a rubber duck here cus I can't read it
<gorgonical>
I think I need to understand how gcc is optimizing away the subtract to actually be an add instead
<zid>
well that's the thing it's adding to
<zid>
[x20+1536]+0x40000000 + x19 + 0x4000000
<zid>
is the calc it appears to be doing
<gorgonical>
That value is either going to be 0xffffffc... or something much smaller, like 0xaf000000
<zid>
0-4 = c
<zid>
so that's probably just the inverse of subtracting that out
<gorgonical>
Yeah it's impossible to know if gcc is doing something crazy like storing two constants at the same location and fixing them up when actually used
<zid>
arm is crazy ;P
<zid>
but the 4 constant makes sense to me
<zid>
kernel_base + 4000000000 = 0
<gorgonical>
yeah
<gorgonical>
So it adds the inverse instead of subtracts its actual value
<gorgonical>
?
<gorgonical>
That doesn't.... sound right
<zid>
by the looks of it
<gorgonical>
Unless the point is to intentionally abuse overflow?
<zid>
it's unsigned, unsigned is defined
<zid>
first thing I said
<gorgonical>
man that's still wacky to me
<gorgonical>
I mean you are right, that's well-behaved
<gorgonical>
So maybe I should suspend my disbelief then
<gorgonical>
lol
<zid>
and plus this is the machine code, it only has to be defined by the ISA, not C
<zid>
C can abuse anything that the ISA says is legit
<zid>
as long as it implements the C environment
<geist>
yah also risc machines sometimes have to be more creative with their constants, since they can't in all situations just as easily blat out a full immediate like you get on x86 or whatot
<geist>
so you'll generally see more trickiness like tha
<gorgonical>
wait
<gorgonical>
excuse my french, but holy shit
<gorgonical>
there's a literaly sign-extend operation on return from this phys_addr
<bslsk05>
pastebin.com: ffffffc000085430 <cpu_psci_cpu_boot>:ffffffc000085430: a9be7bfd s - Pastebin.com
<gorgonical>
is the dump and the code
<geist>
huh that's really strange
<zid>
all makes sense to me
<geist>
dunno, it is immediately passing it to printk
<geist>
but then it would have sign extended based on the 32bit value, not the full 64bit
<gorgonical>
so the sxtw x19, w0 i think is actually truncating the 64-bit retval in x0
<gorgonical>
?
<zid>
well the code has a truncation in it
<geist>
sure, but not befre the printk
<geist>
which it should be passing the full deal into
<geist>
the way i'm reading it it sign extends the bottom 32bits of e into x19, then moves it into x1 for the printk (2nd arg after the string)
<zid>
It does a mov for that later doesn't it
<geist>
later i dont care, just the few instructions right after __phys_addr to printk
<zid>
oh that printk
<zid>
what are the arg regs I am interested in here for printk?
<zid>
I barely know the normal abi much less the varargs one
<geist>
x0 has string, x1 is the frst one
<geist>
varargs just pass first 8 args as usual (x0 - x7) then spill onto the stack
<zid>
it reloading through x19 makes little sense to me
<zid>
unless sxtw x1 doesn't encode
<gorgonical>
the printk format is llx though, so it shouldn't be sign-extending anything right?
<geist>
it's just saving it into x19 ecause that's callee saved (first one actually)
<zid>
oh and w0 will get deleted by printk right
<geist>
and then it copies it back to x1 to prep for the function call
<zid>
forgot it isn't void
<geist>
right, x0-x18 are all trashed
<gorgonical>
yeah, phys_addr actually puts the retvals onto the stack but it can skip that
<geist>
it's the calling convention: x0-x17 are all callee trashed, x18 is special, x19-x30 are all callee saved
flx-- has joined #osdev
<geist>
so by moving it to x19 it's just arranging for it to be saved across the printk, no biggie
<gorgonical>
meaning the callee promises not to change them?
<geist>
right
<gorgonical>
just to make sure I don't have it backwards
<gorgonical>
right
<geist>
but what doesn't make any sense is thw `sxtw x19, w0`
<gorgonical>
and indeed if I take that printk out it doesn't bother with x19 until it calls cpu_psci_boot_cpu, where it puts the result
<zid>
also format doesn't matter re varargs, only the width of the args, which does have some restriction, but I don't see how they'd be relevent here
<gorgonical>
it does it without the printk, as if that might matter
<geist>
that really really really implies it thinks the result is a signed 32bit value
<zid>
unless you literally wrote (int)blah as your arg to printf
<geist>
again i'm focusing on why it sign extends the results. the printk is just the first thing that uses it
<geist>
so if i read that right it's sign extending the int from __phys_addr to a full 64bit word and then printing it
<zid>
i've not seen the C for this bit so I can't see if you've made a code mistake, but as far as this machine code is concerned, either both functions expect int, or the type is int
<geist>
which would be no sweat if that was the intention
<zid>
or the opposite
<geist>
anyway, i'm guessing something is mis-pastebinned somewhere
<geist>
i seriously doubt the compiler is confused
<geist>
but welcome to arm64! it's pretty neat once you grok it
<gorgonical>
I'll collate it all together in one paste, just a second
<geist>
soooo many registers to use!
flx- has quit [Ping timeout: 240 seconds]
<geist>
was there an actual original question or are we just tearing some asm apart for luls?
<gorgonical>
There is. I'm trying to boot a secondary CPU and the entry point addr is wrong
<zid>
well cpu_on only takes an int.. so there is that :P
<gorgonical>
Because it's returning 0xffffffff.... instead of 0x00000000
<geist>
ah well based on what i've seen thus far it really really thinks __phys_addr should return a 32bit value
<geist>
why i dont know, but it being a 32bit return type that it sign extends to the full register is very common
diamondbond has joined #osdev
<geist>
that doesn't jive with the code you've pasted, so something is off somewhere
<zid>
fishy macro expanding to the wrong function? :P
<bslsk05>
pastebin.com: Output I get:^M[0]:memstart af000000^M[0]:virt_addr ffffffc000082700^M[0]: - Pastebin.com
<gorgonical>
Incl. the output
diamondbond has quit [Read error: Connection reset by peer]
<gorgonical>
To note: the output is from when pa_symbol was beign printed, but the c code and dump are consistent
AssKoala has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
<gorgonical>
to be clear, the problem here is definitely the sign extension misinterpreting the value as a signed, negative value and sign-extending it with f's? *why* gcc wants to do this is unclear, but that is the problem?
<zid>
I was finishing my movie, I'll take a look at the big paste in a bit
<gorgonical>
I'm just glad anyone is interested really, thank you for your time
diamondbond has joined #osdev
<zid>
I don't see anything funny, I'd expect cpu-on to get called with whatever cpu_loglcal_map(cpu) is and AF082700
<gorgonical>
So my suspicion is that the fact that its 0xa... means the top bit is 1, and so the sign-extending sends it all up to 0xffffffffa....
<zid>
yea
<zid>
that's normal though
<gorgonical>
When it assumes the width is 32-bits, right?
<zid>
no
<gorgonical>
The problem is that the result of phys_addr isn't signed, so sign-extending it actually changes its value
<zid>
have you tried braindeadedly checking your printk btw
<zid>
with unsigned long e = 0x80000000UL; or something
<gorgonical>
making sure it isn't doing something silly?
dude12312414 has joined #osdev
<zid>
llx is presumably the wrong format specifier for long
<gorgonical>
I must come back to take my lumps: gcc wasn't complaining about a lack of function declaration, but apparently that was the issue. putting an extern declaration somewhere has convinced gcc that in fact the return type is unsigned long, and the sxtw is gone
<zid>
whoopsie, how did you manage to supress that
<zid>
it's super warny about that
<gorgonical>
Honestly I don't know. Is it -wno-format-security? I have -wstrict-prototypes
<zid>
I completely overlooked that possibility
<zid>
it'll be -wimplicit- something
<zid>
-Wimplicit heh
<zid>
Same as -Wimplicit-int and -Wimplicit-function-declaration. This warning is enabled by -Wall.
<gorgonical>
-Wall is on
<gorgonical>
so... ???
<gorgonical>
What a mystery
<zid>
apparently not
<zid>
you can technically pragma it off
<zid>
or have -Wno later in the invocation line
<gorgonical>
At least it's in most of the cflags. Yeah, I mean it must be right lol
<zid>
I'd erm, go out on a limb and say your Wall isn't propagating through your build scripts as far as it needs to
nyah has quit [Ping timeout: 240 seconds]
les has quit [Quit: Adios]
les has joined #osdev
air has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
les has quit [Quit: Adios]
les has joined #osdev
flx-- has quit [Ping timeout: 245 seconds]
ElectronApps has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
ZombieChicken has joined #osdev
gog has joined #osdev
ElectronApps has quit [Remote host closed the connection]
flx-- has joined #osdev
mctpyt has quit [Ping timeout: 240 seconds]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
flx- has joined #osdev
flx-- has quit [Remote host closed the connection]
AssKoala has quit [Ping timeout: 240 seconds]
tacco has joined #osdev
sortie has joined #osdev
ZipCPU has quit [Ping timeout: 240 seconds]
GeDaMo has joined #osdev
flx- has quit [Remote host closed the connection]
hgoel[m] has quit [Quit: Bridge terminating on SIGTERM]
paulusASol has quit [Quit: Bridge terminating on SIGTERM]
happy-dude has quit [Quit: Bridge terminating on SIGTERM]
paulusASol has joined #osdev
Burgundy has joined #osdev
mhall has joined #osdev
happy-dude has joined #osdev
hgoel[m] has joined #osdev
rubion has joined #osdev
nyah has joined #osdev
rubion has quit [Ping timeout: 240 seconds]
sortie has quit [Quit: Leaving]
dormito has joined #osdev
Arthuria has joined #osdev
rubion has joined #osdev
LittleFox has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
flx has joined #osdev
ZipCPU has joined #osdev
LittleFox has joined #osdev
diamondbond has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 245 seconds]
skipwich has quit [Read error: Connection reset by peer]
skipwich has joined #osdev
<amine>
I have this lgtd instruction I'm running in qemu which is acting wrong for some reason. So I do this, mov $0x7cd8,%ebx then lgdtw (%ebx), 0x7cd8 is the address of the gdt descriptor
<amine>
in gdb
<amine>
(gdb) p/x ((char*) 0x7cd8)[0]@3
<amine>
$4 = {0x18, 0x0, 0xc0}
<amine>
oh wait that's wrong
<amine>
(gdb) p/x ((char*) 0x7cd8)[0]@4
<amine>
$5 = {0x18, 0x0, 0xc0, 0x7c}
<sham1>
Are you actually hard-coding the address or is it generated by the assembler when it assembles
<amine>
so 0x7cc0 is the address of the actual gdt table
<amine>
it's generated by the assembler
<amine>
but the problem is what gets loaded in the GDTR register is totally different
<amine>
form the qemu info registers, this is what's loaded after that lgdt instruction
<amine>
GDT= ff53f000 0000ff53
<amine>
shouldn't GDT be loaded with the gdt descriptor content ?
<sham1>
GDTR holds the address of the GDT
<amine>
hm ok but that still seems to be totally off
<sham1>
Are you in 16-bit mode, 32-bit mode or 64-bit mode
<bslsk05>
github.com: xv6-public/bootasm.S at master · mit-pdos/xv6-public · GitHub
<amine>
now I see there they first set things to 16bits then transition to 32
<amine>
but on my Zig code I'm not doing any of that, I just compile to i368-freestanding, and the assembly is all in inline asm
<amine>
so I guess that's maybe a problem ?
<sham1>
Because the base address needs to have the length according to the mode. For 32-bit mode you want your GDT descriptor to have your 16-bit limit and 32-bit address, and with 64-bit you want 16-bit limit and 64-bit address
<amine>
err i386-freestanding, I never get those numbers right :D
<sham1>
Why are you doing the assembly with inline assembly in Zig
<amine>
no reason, other than playing with the language
<sham1>
Would it though. amine said that it's for i386 so that should be 4 bytes
<gog>
depending on the cpu's mode and the compiler's pointer size
<gog>
is the pointer size guaranteed to be 4 bytes here?
<gog>
sham1: maybe
<sham1>
I'd be surprised if a data pointer was anything other than 4 bytes in i386
<gog>
my other note is to uncomment cli
<sham1>
Yeah, that needs to be done
<sham1>
Wait wait wait
<sham1>
Why is the A20 investigated here?
<sham1>
That should be done by the bootloader
<amine>
this is a bootloader yeah
<sham1>
Is this actually 16-bit code perchance?:
<gog>
also the first field of the gdtr isn't a size, it's a byte limit
<gog>
so it's size - 1
<amine>
\\ is just multi line string in Zig btw
<amine>
ah right
<gog>
oh ok i see
mctpyt has joined #osdev
<gog>
in my code i just make the gdtr struct on the stack
<gog>
pushl gdt_base; pushs gdt_limit
<sham1>
I just have it in .data in both my kickstart and the actual kernel. Makes everything so much easier
<gog>
then lgdt -whatever(%rbp)
<amine>
hm though at that point I don't even have a stack right
<sham1>
Oh, seems like I actually don't have a GDT in my kernel. It's only set by the kickstart when it enters the 64-bit mode before handing control
<sham1>
I should probably fix that
<gog>
whoops lol
<gog>
does this paste site have a rick astley favicon lmao
<sham1>
Yes it does
<sham1>
You know the rules, and so do I
<amine>
hehe
<gog>
amine: so in your assembler template to load the gdt you have {ebx} (&gdt_desc) and i'm not entirely sure about that
<amine>
in gdb that translates to mov $0x7cd8,%ebx ; lgdtw (%ebx)
<gog>
hm ok
<gog>
so when _start() is 16-bit?
<gog>
s/when//
<sham1>
Yeah, that probably won't work because of different instruction encoding, perhaps
<amine>
gog yeah I don't think it's ever 16bit, as I target i386 during the build
<amine>
but I'm interested to understand the limitation fully, so far it's a bit blurry why that would be a problem
<amine>
sham1 what did you mean by "different instruction encoding" btw ?
<sham1>
Instructions and things like registers may be encoded differently if it's real mode vs protected mode vs long mode's 64-bit submode
<amine>
wouldn't that result in a totally broken instruction ? or it's still works (loads something to gdtr) but in a sort of a broken way
<sham1>
Yes
<sham1>
Little bit of both
<amine>
hmm so if I do ndisasm -b 16 on the bootblock it does indeed show something that looks off
<amine>
0000001D BBD87C mov bx,0x7cd8
<amine>
00000020 0000 add [bx+si],al
<amine>
00000022 660F0113 o32 lgdt [bp+di]
<sham1>
You'd have to explicitly tell Zig to emit 16-bit instructions with the inline assembly somehow
<gog>
if that's even possible
<amine>
I'm so glad this mystery is solved, it was driving me crazy :D
<sham1>
Yeah
<gog>
gcc has .code16gcc for inline asm but it's very dodgy
<gog>
no clue about zig i'm afraid
<sham1>
Honestly I'd just not use a high-level language for this stuff and just write enough assembly to set this stuff up
<gog>
^
<amine>
but just understanding what the issue is exactly is already nice for me
<amine>
I'm fine with hitting a blocking issue that I understand
<amine>
sham1 yeah sounds right
puck has quit [Remote host closed the connection]
bslsk05 has quit [Remote host closed the connection]
puck has joined #osdev
heat has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
srjek has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 252 seconds]
archenoth has quit [Ping timeout: 240 seconds]
archenoth has joined #osdev
jjuran has quit [Ping timeout: 272 seconds]
bslsk05 has joined #osdev
Oshawott has joined #osdev
flx- has joined #osdev
archenoth has quit [Ping timeout: 240 seconds]
flx has quit [Ping timeout: 258 seconds]
ElectronApps has quit [Remote host closed the connection]
jjuran has joined #osdev
Oli has joined #osdev
Arthuria has quit [Ping timeout: 240 seconds]
mahmutov has joined #osdev
zaquest has quit [Ping timeout: 240 seconds]
zaquest has joined #osdev
paulman has quit [Remote host closed the connection]
paulman has joined #osdev
kulernil has joined #osdev
paulman has quit [Ping timeout: 244 seconds]
rubion has quit [Ping timeout: 240 seconds]
Oshawott has quit [Ping timeout: 240 seconds]
zoey has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
zoey has quit [Remote host closed the connection]
rubion has joined #osdev
XgF has quit [*.net *.split]
Arsen has quit [*.net *.split]
thaumavorio has quit [*.net *.split]
Bitweasil has quit [*.net *.split]
Starfoxxes has quit [*.net *.split]
zhiayang has quit [*.net *.split]
froggey-1 has quit [*.net *.split]
CompanionCube has quit [*.net *.split]
Patater has quit [*.net *.split]
XgF has joined #osdev
froggey-1 has joined #osdev
Arsen has joined #osdev
zhiayang has joined #osdev
Patater has joined #osdev
thaumavorio has joined #osdev
Bitweasil has joined #osdev
dminuoso has joined #osdev
dbana has joined #osdev
dminuoso has left #osdev [#osdev]
dbana has quit [Quit: Lost terminal]
CompanionCube has joined #osdev
AssKoala has quit [Read error: Connection reset by peer]
AssKoala has joined #osdev
GeDaMo has quit [Quit: Leaving.]
brynet has quit [Ping timeout: 258 seconds]
pretty_dumm_guy has joined #osdev
dormito has quit [Ping timeout: 240 seconds]
freakazoid333 has joined #osdev
brynet has joined #osdev
dormito has joined #osdev
mavhq has joined #osdev
dennis95 has quit [Quit: Leaving]
<Bitweasil>
Anyone want a M1 Mini in the US?
gog has quit [Ping timeout: 240 seconds]
dormito has quit [Ping timeout: 240 seconds]
heat has quit [Remote host closed the connection]
immibis_ has quit [Ping timeout: 276 seconds]
dormito has joined #osdev
rubion has quit [Ping timeout: 252 seconds]
<kazinsal>
12th gen core processors will not have AVX-512 because they can't find a way to shove it into the little cores
<kazinsal>
good work intel
<acidx>
Bitweasil: what's the catch?
<Bitweasil>
acidx, I expect to be paid for it?
<Bitweasil>
kazinsal, lulz.
<acidx>
Bitweasil: ah. let me DM you for details.
<zid>
and avx-512 sucks
<moon-child>
kazinsal: lmao
<moon-child>
zid: <3 avx512
<Bitweasil>
AVX-512 is perfectly useful.
<Bitweasil>
It turns a processor into a solid version of a lightbulb.
<zid>
if what you want is a local denial of service instruction set it's solid
ahalaney has quit [Quit: Leaving]
<Bitweasil>
Other than the clock rate dropping if anyone touches it?
<moon-child>
the masking stuff is cool
<moon-child>
and makes esp. autovectorization much easier
<moon-child>
and afaik they fixed the power consumption stuff
<zid>
it's better
<zid>
They still drop 10% even on the latest chips, and it makes it much easier to hit thermal limits and downclock that way too, comparitively
<zid>
which is fine if all you care about is your avx-512 thread
<geist>
actually worse, looks like they're going to fuse off the avx-512 parts in the golden cove cores
<geist>
so it's dark silicon
<zid>
that's my band name
<geist>
if i read the tea leaves here this will pretty much kill off avx512 for consumer stuff
<zid>
good
<zid>
then I won't have to care about not having it :P
<zid>
unless someone buys me an 11900k or something I don't intend to
<geist>
though supposedly there is rumors that zen4 will have it. how ironic would that be
<zid>
11900k is close to being as good as sandy bridge!
<zid>
only missing 2 memory channels, 20 pci-e lanes and ecc
<moon-child>
man
<moon-child>
I really wanted to play with avx512
<moon-child>
apparently a lot of its primitives matched really closely to apl primitives, so I was gonna try to use them in my interpreter
<moon-child>
:/
<kazinsal>
the unfortunate part of that particularly is that using avx-512 turns your CPU into a space heater
<kazinsal>
often times the coolers used on CPUs can just about hold the actual TDP of the socket's highest TDP CPU available and that's it
perano has joined #osdev
<kazinsal>
and intel's TDP estimates are completely null and void when you start using AVX-512
<zid>
just undervolt it first ;)
<Bitweasil>
I mean, they're null and void, period.
<Bitweasil>
They're just nonsense numbers anymore.
<zid>
afaik they don't account for turbo?
<Bitweasil>
Correct.
<Bitweasil>
TDP is just "Max power at rated clocks if you're not doing anything too crazy."
<zid>
gj my turbo is only 200MHz above my base clock then? :p
<zid>
it's a whopping 5%
<perano>
The most important in life is not to show your greed or dominance or so called total dominative skills but show your passion humanity to settle for less, do not forget that all those skills from higher powers, and it goes dangerous to be greedy, cause your empathy was deesigned so that you'd have some senses that this is all what you have a lifem and this is boy what you have to defend, and money ain't gonna always do that or very agressive demontsration of
<perano>
some weird or exceptional "god" given talent to be greedy.
mahmutov has quit [Ping timeout: 248 seconds]
Burgundy has quit [Ping timeout: 240 seconds]
MiningMarsh has quit [Ping timeout: 268 seconds]
MiningMarsh has joined #osdev
<perano>
And i say, the girl i met on a trip, i never did anything to her bad, but i recognized right away that this girl has higher capacity available than what is available to me, and i am fine with that, it's up to her how to handle her resources because those do not belong to me. At times i am not fully agreeing how she destroyes her mind, but i have no rights there, i understand the huge power there, and it showes out also, maybe not trained to be the highest gear
<perano>
yet, but again it is up to her, i could advise only, and none would listen anyways.