<doug16k>
info mtree will tell you the MMIO window as 000000003eff0000-000000003effffff (prio 0, i/o): gpex_ioport
<doug16k>
I think
<geist>
yah, i also think it's described in the PCI node in the device tree
<geist>
technically you can find all of the details of PCI, though its encoding is fairly arcane and complicated
<doug16k>
ah right. each pci bus might have a different one
<geist>
yah, the /PCI node in device tree is complicated because it is this list of type/length fields that in aggregate describe everything
<geist>
but it's a highly compressed stream of bytes so hard to even look at manually
<geist>
it's actually from the Old Days of device tree, so it's specced out as an IEEE thing i think
<geist>
but also means the docs are highly machine agnostic and use generic terms for everything
<geist>
i walked through it once and manually decoded what qemu puts together and it makes sense though
<doug16k>
what happens when a bar is 0
<doug16k>
is 0 special? I can't find it saying 0 is special in pci spec
<doug16k>
I can't put an MMIO at 0?
<doug16k>
I guess it relies on memory-space-enable and io-space-enable bits
<doug16k>
and 0 isn't special
<geist>
good question
<geist>
may be a reason linux seems to start allocating at 0x1000
<doug16k>
I can imagine implementation bugs related to zero, yeah
<doug16k>
hardware implementations
<doug16k>
it's not nice to put something at zero anyway. sloppy
<geist>
0 has to be special though right? since it starts off unconfigured that way
<doug16k>
unless it doesn't matter or only does it for a few tens of microseconds
<doug16k>
no, the command register is zero too. io-space-enable and memory-space-enable are not on
<geist>
though i guess it may simply be undefined to enable a device with its bars sets in an overlapping wawy
<geist>
ah
<geist>
so actually that kiunda implies that 0 is fine. i can think of one reason: you mighjt want to map some sort of faked out device that say acts like a vector table
<geist>
i've actually seen this on older ARMs
Mutabah has joined #osdev
<doug16k>
yeah, 0 should be allowed
<doug16k>
yeah I still need to fix the vector table like you mentioned
<doug16k>
I didn't quite catch that when we were talking, will have to get from scrollback
<geist>
VBAR_ELx
<doug16k>
thanks
<geist>
'vector base address register'
<geist>
separate one per EL, so if you start switching ELs you have to set it again
<geist>
i've been bit by that too
<doug16k>
I think that is causing it to jump back into my code all weird and end up in a weird state, because I overlap it badly
<geist>
yep.
<geist>
0x200 is one of the main exception vectors
<geist>
so you're trapping for some reason and it's branching back into your code
<doug16k>
yep, I have a 208 in my call stack
<doug16k>
fluke call to pci_read 3 insns after that entry :P
<geist>
this is fun now, so you get to write a little exception handler and print what's in ESR and FAR and whatnot
<doug16k>
yes
<geist>
ESR is the best register ever: exception syndrome register
iorem has joined #osdev
<geist>
my guess the reason linux starts allocating PIO from 0x1000 is it's leftover logic from x86 where 0x1000+ is where the un-fixed allocations come from
Oli has quit [Ping timeout: 245 seconds]
<doug16k>
msr x0,VBAR_EL3 then?
<gog>
exception syndrome
X-Scale has joined #osdev
<gog>
so does the register indicate something pathological with the system?
<doug16k>
I got it
<doug16k>
msr VBAR_EL3,x0
<geist>
yep, right to left, and with mrs/msr note the 's' and 'r' part line up with the register
<geist>
gog: it sounds serious huh? naw, it's just the register that describes with a large enum ad then some syndrome specific fields what the reason for the exception was
<geist>
basically all exceptions are funneled through a single vector, and your code then has a big switch to figure it out
<kazinsal>
"exception syndrome" sounds like it means "you have a hardware defect, contact your vendor for an RMA"
<geist>
right?
<doug16k>
ah, so all synchronous exceptions go through the 1st entry point. gotcha
<doug16k>
and a lower privilege one comes in at the 0x400 offset one? (half way down)?
<geist>
doug16k: yah in this case it's the 1st entry point in the second bank. since they're 0x80 apart it's the 5th vector from the base
<geist>
yah
<geist>
separated only by which mode the cpu was in at the time. so you can save less stuff on the stack if you came from 32bit land
<doug16k>
ah, half way down that half is the 32 bit ones
<geist>
the fist two banks are all same exception level, but varies depending on which stack pointer you were using at the time
<doug16k>
I was wondering why the repetition
<geist>
yah basically 4 copies of the same 4 vectors, all differentiated by what the cpu was doing at the time
<geist>
it's nice too, the from user/from kernel one is the biggie, since you can right off the bat customize what you save/restore without needing to test any bits in the SPSR
<geist>
and you know immediately wiether or not you're stacking on the current SP or not (since SP is banked between ELs)
<geist>
that's the reason for the first two copies: it differentiates whether or not the current EL was using SP0 or SPx at the time
<geist>
and that may affect how you treat the stack pointer, which iirc is always immediately switched to SPx
<doug16k>
ah, only a lower privilege can be 32 bit
Oli has joined #osdev
<doug16k>
and first two are normal stack and non-normal stack?
<geist>
right since by definition you're running in 64bit mode to be even getting this style of exceptions
<geist>
and you have to be running in 64bit mode in EL1 to take an exception from EL1 to EL1, so there's no bitness switch
<geist>
note this whole stacking thing works all the way up
<geist>
if you're in EL3 or something all the 'lower EL' means is 'i took an exception while the cpu was running in EL0, 1, 2'
<doug16k>
if el1 has a handler, where does it go if el3 has one?
<doug16k>
and exception was el0
<geist>
el1 *unless* el3 has explicitly overridden it
<gog>
geist: oh i get it
<gog>
so it's like in lieu of a code on the stack
<geist>
there's a whole series of control bits at EL3 and EL2 that say 'route exception X to me first' etc
<doug16k>
ok so you pick what to trap
<geist>
right. so if EL3 isn't interested in anything, which it usually isn't, it will simply mark everything as 'delegate to lower level'
<doug16k>
think of them more like virtualization guests
<doug16k>
the levels below 3, 2
<geist>
note RISCV does the asame thing: each level has a 'delegate' register which says woether or not the exception is delivered to you (or higher) or if the lower level can deal with it
<geist>
gog: right
<geist>
so, for example, EL3 could say 'i want to take all IRQs to me first' and then all irqs are sent to el3 which could then fairly easily relfect them down to a lower level
<doug16k>
I wonder if I am not delegating. it didn't seem to help when I set VBAR_EL3
<doug16k>
er, am by accident
<geist>
since nothing is automatically saved on the stack/etc it can simply eret to the lower levels exception handler, as if it was just delivered there in the first place
<doug16k>
wait, if the exception came from el3 then I definitely get it in el3 vbar right?
<geist>
setting VBAR has no difference at all. VBAR is never not set, it just defaults to 0
<geist>
not from, *to*
<doug16k>
in my case, el3 is throwing
<geist>
then you *must* deal with it
<geist>
all of the 'i want to take this exception' is only to do with whether or not EL3 'intercepts' it
<geist>
intercept is probably a better way of thinking about it
<geist>
but it can only intercept something that would normally be delivered to a lower level
<geist>
but if EL3 throws an exception EL3 *has* to handle it
<doug16k>
ah. if el3 throws then it's the 0x400 one right? SPx?
<doug16k>
what does SP0 mean?
<doug16k>
EL0's SP?
<doug16k>
or is it EL(currentEL-0)
<geist>
it's the 0x200 one most likely
<doug16k>
I mean SP(currentEL-0)
<geist>
so. there's another bit in thePSTATE register, CurrentSP I believe
<geist>
it basically lets you set at EL1 - 3 whether or not the current SP register is an alias for SP_ELx (where x is your current level)
<geist>
or if it's an alias for SP_EL0
<geist>
EL0 has no choice, it's stack is always SP_EL0
<geist>
most of the time you dont use this, but there are some reasons it's useful
<geist>
but by default the current SP is SP_ELx
<geist>
ie, it's pointing to the banked one for your EL
<doug16k>
ok
<doug16k>
not even sure what registers I am using :P
<geist>
but, since what the stack was at the time it took an same-EL exception may matter to stack recovery, they put it in a separate bank of vectors
<doug16k>
gonna run over some mailboxes for sure
<geist>
unless you went out of your way to set it to something else, you'll be using SP_EL3, in which case EL3 -> EL3 exceptions are all coming in via the second bank of exceptions
<geist>
0x200-0x380
<doug16k>
nice
<doug16k>
so if I just infinite loop at vbar+0x200 that should be good enough to start
<geist>
anyway so just set up your own vector table, align it on 11 bit boundary and set a pointer to it in your VBAR_EL3 when you boot
<doug16k>
I can't even get that far yet, apparently
<doug16k>
oh align it
<geist>
right. or put an infinite lop in all of them really
<doug16k>
I knew it
<doug16k>
I totally didn't align it that much
<doug16k>
I did put it in its own input section in preparation though
<geist>
yah it's 11 bit (2k) alignment because 0x80 * 16 == 2k
<geist>
note all thi sstuff is where riscv is like 'hold my beer'
<geist>
it has *one* exception vector. period.
<geist>
you want to get exceptions? here it is. you want interupts? sure, special case of exception
<geist>
(yah not entirely true, some riscv cpus can autovector some of the interrupts)
<clever>
and this is also where cortex-m and cortex-a vary? m has one slot for each irq? while a has one slot for all irq, plus fiq?
<geist>
yep. cortex-m has a fully vectored irq thing, much closer to x86
<clever>
and fiq was purely to auto-swap a bank of regs, and to skip having a branch in the vector slot
<clever>
but aarch64 has larger slots, so you rarely need that branch opcode, if your code is small
<geist>
yah though really 0x80 is barely enough to save your registers before branching into something else
<geist>
what i've seen most OSes do is simply have a 2K table with a single branc in them to some other code
<geist>
instead of trying to cram in your code to 0x80
<geist>
next time i get in there i'm going to do the same with fuchsia too, it's getting too tight and annoying in the exception code to fit the save logic in 0x80
<clever>
on cortex-m, is the vector table a list of addresses, or an array of fixed-size functions?
<geist>
iirc POWER/PPC has something like that too, N vectors separated by M bytes, at a fixed *physical* address (mmu is implicitly turned off in exception handlers)
<bslsk05>
www.eejournal.com: We Interrupt This Program… – EEJournal
<graphitemaster>
In case it was not linked here earlier
<clever>
geist: ah, so cortex-m and vpu are most similar
<doug16k>
oh wow, I need cfi that tells it to get the return address from a funny place at exception entry, don't I?
<geist>
graphitemaster: yah the FRED thing in particular is pretty deep cutting in intel
<geist>
doug16k: yah it's ELR_EL3 in your case
<doug16k>
I got it hitting the synchronous exception properly, now that it is aligned
<doug16k>
now dead stack trace
<doug16k>
perfect
<geist>
i'm gonna guess that the exception is something like an unaligned access with cache disabed (though i dunno if qemu emulates that) or maybe an unaligned stack (also dunno...)
<doug16k>
stack gets set to an extremely aligned place and I don't even touch the stack once
<doug16k>
until it gets to compiled code of course
<geist>
perfect. arm64 (unless you disable it) requires that the SP be at *all times* 16 byte aligned
<geist>
not even temporarily for one instruction
<geist>
the control bit for that behavior is in the SCTLR_ELx
<geist>
think of the SCTLR as CR0 for arm. it's the master control register where you set things like endianess of the cpu, whether or not the cache or mmu is enabled, etc
<graphitemaster>
Why don't we just have dedicated cores to handle interrupts as entries in shared memory
<graphitemaster>
That works great for I/O
<geist>
well, actually i dont think it does really
<graphitemaster>
But processor faults can just be I/O events
<geist>
very high end modern things theres a lot of value to running separate instances of the driver, essentially, on separate cores
<geist>
NVME is a good example. if cpu 17 queues a transfer then it can be set up to receive the completion interrupt on cpu 17 and cpu 17s local queue can get serviced by itself
<graphitemaster>
Also we should just get rid of faults for divide by zero (as an example)
<graphitemaster>
ARM doesn't do that shit
<geist>
graphitemaster: no complaint from me. arm and riscv doesn't do that shit
<graphitemaster>
x86 has a lot of really stupid faults
<clever>
geist: and due to crap design, the pi4 isnt capable of running 4 queues on nvme
<doug16k>
as an instant hack, I can just do this in gdb: `set $pc=$elr_sp3` then `bt`
<clever>
i'm pretty sure it funnels all of the irq's into one chosen core, even with the gic enabled
<doug16k>
having those exceptions, and having them occur are two different things
<doug16k>
about the only ones likely to occur are #GP and #PF
<bslsk05>
fuchsia.googlesource.com: zircon/kernel/arch/arm64/exceptions.S - fuchsia - Git at Google
<geist>
i dont understand it but someone that did set that
<doug16k>
names work for you?
<doug16k>
I have to say hideous register numbers
<geist>
seems to
<geist>
unless it's #defined somewhere else i guess
<doug16k>
yes that is how you do it
<geist>
oh it is, see line 25
<doug16k>
you can also do cfi_register rip,rcx (if you know what I mean)
<doug16k>
return addr is in rcx
<doug16k>
pc,elr1 in that case
<doug16k>
if it works there too, that is
<doug16k>
I find it more elegant to tell it "caller's rip is in rcx" than suddenly requiring you to know all about how frame info works and talk about a return column :D
<geist>
yah like i said i have no idea what a return column is, etc :)
<doug16k>
without that "simple" you'd need .cfi_register lr,lr to tell it the weird condition of caller's lr being in lr
<doug16k>
without simple it assumes .cfi_register pc,lr
<doug16k>
exception entry cfi is the most oddball
<geist>
oh makes sense. actually looking at the docs page here. doesn't seem *too* weird
<doug16k>
yeah all it is really is telling it where you put caller's things
<doug16k>
in case it catches you in the middle of something weird
<doug16k>
callee saved regs and return address
<doug16k>
on x86, instead of ret, you could pop %rcx, then .cfi_register rip,rcx, then jmp *%rcx
<doug16k>
no need for a correct stack frame
<gog>
i've meant to ask you how kernel-mode c++ exceptions perform. i read something about it being a bad idea due to performance reasons, but if exceptions are rare that shouldn't matter right?
<doug16k>
it's amazing if you don't throw, but yeah, unwind is a tad expensive
<doug16k>
it can throw again too, depending on what's wrong
junon has quit [Ping timeout: 252 seconds]
<gog>
i know it's easy to abuse them as a sort of flow-control which would make the performance drawback make sense
<gog>
but if you're not abusing them i don't really see why not to
<doug16k>
it's nice to be able to get stack traces at runtime as competently as gdb would
<doug16k>
even if you didn't actually throw, having unwind info is useful
junon has joined #osdev
<riverdc>
does gcc enforce a stack limit in freestanding mode?
<doug16k>
riverdc, enforce? it can't enforce anything. it will attempt to provoke a page fault if you use enough stack for reaching over a guard page to be a problem
<gog>
how would it?
<doug16k>
it will add 0 to rsp-4096
<doug16k>
then -8192... etc
<doug16k>
if you enable -fstack-check
<gog>
ah i see
<doug16k>
if you don't use a lot of stack then you will definitely touch the guard page, and it skips that
<riverdc>
doug16k: i see, thanks
<doug16k>
it has to be an instruction that modifies the memory - the kernel probably is making an illusion of a giant stack of zeros by repeating the mapping of the zeroed page
<doug16k>
mapped read only so it traps your first write, to demand grow it
<riverdc>
the programmer would have to add any such guard pages themselves, right?
<riverdc>
there won't be any by default, i mean
<doug16k>
if you are making the kernel and environment, right
<doug16k>
you are the one providing that to yourself and even user programs
<doug16k>
you probably don't demand-grow the kernel ones. just fault on overflow
<doug16k>
on user you can give them a goofy initial stack like 4K and grow it as they touch it
<riverdc>
yep makes sense
<clever>
there are also some exploits involving the self-growing stack
<clever>
if you trick a program into allocating an 8kb buffer on the stack, it can blow right past the guard page, and start writing into non-stack space
qookie has quit [Ping timeout: 245 seconds]
<clever>
gcc now has a stack-check function, which will prod each page involved in such an allocation, to trigger the guard pages, grow the stack, and fault if the stack runs out of room to grow
<doug16k>
the whole vaddr region is the stack though, how does that work
<doug16k>
so it faults in the page you reached over
<clever>
doug16k: at some point, the stack cant grow any bigger, and you run into something else
<doug16k>
..to
<doug16k>
ah at that point
<clever>
if you allocate a buffer of the right size, you can skip over the guard page, and the rest of the "future stack", and right into data
<clever>
the kernel would stop growing, and make the guard page fatal
<doug16k>
yeah but the demand paged area can get reached over and faulted in in whatever order, doesn't matter
<clever>
and the gcc fix, is to ensure it trips the guard pages
<dormito>
anyone know of a 'readelf' like tool, but for examining pe32+ binaries?
<doug16k>
fstack-check
<doug16k>
dormito, objdump
<clever>
doug16k: yeah, i think thats the one
<doug16k>
compiled with the emulation
<dormito>
oh, objdump can display meta data?
<doug16k>
yes, -p will show that stuff
<clever>
dormito: when using an objdump from a cross compiler, definitely
<dormito>
nice, thanks :)
<clever>
ive not tried using a non-cross objdump recently
<dormito>
doug16k: well, it's without the kernel (I hope), and hopefully no windows dlls either
<dormito>
:Pp
<doug16k>
yeah no dlls
<doug16k>
somehow I have an export section. no idea why
<doug16k>
I should have pasted -x and shown all
<dormito>
hmmm... I haven't paid too much attention to pe32+ specs (and related), but I guess an EFI program could load another binary, and link themselves together. (although why you'd ever want to do that is probably a great mystery)
<doug16k>
yeah you can have a bunch of efi programs in executables and run them at a shell prompt
<doug16k>
they all get called exactly as if they were a bootloader
<doug16k>
they just happen to return or exit instead of exiting boot services
<doug16k>
drops to shell prompt again
<doug16k>
you'd swear it was DOS
<doug16k>
DOS with stupid amount of RAM pretty much
<dormito>
if I can't do awful horrible things with TSRs, and geek out by secretly using himem, then I'd know it's not dos :p
<doug16k>
I think there is a way to do that (run as a service somehow)
<doug16k>
but yeah, they don't make you suffer for drabs of memory
<doug16k>
it interestingly has a decent timer system so you can make it spam poll to do whatever you want, with hardly an IRQ
<dormito>
thats horrifying
<doug16k>
it is a bit. thankfully we mostly wait for Read I/O to complete so it has little else to do that poll
<doug16k>
there are events too, which you can wait for, so it doesn't have to be all spinny
<doug16k>
probably wait for event with a polite enough timeout and do a poll each timeout
<doug16k>
then you can kick it or have it pick up things autonomously
<gog>
dos long mode interface
nyah has quit [Ping timeout: 244 seconds]
<gog>
i am not meming, this is a real thing that somebody was doing as a consequence of wanting to spin up AP's with DOS on the BSP
<geist>
i'd think the fancy uefi features are mostly there so you can write fancy looking bios guis in it
<geist>
with mouse cursors, animations, etc
<doug16k>
exactly
<geist>
need timers and event mechanisms and stuff
<doug16k>
and the SMP stuff is for when the hardware absolutely needs another cpu to initialize something
<doug16k>
not for parallelism/performance
<geist>
or some sort of test thing
<doug16k>
yeah, like memtest86
<geist>
right
<geist>
i never did seriously sit down with the EFI shell and see if there's a way to dump the list of internal modules and whatnot
<geist>
ie, can you start your bios gui from EFI by finding it's corresponding app and starting it
<doug16k>
it can dump some stuff like device trees
<geist>
is it basically just a static FS on the rom?
<doug16k>
there is some cool stuff to poke at
<geist>
etc
<geist>
yah
smeso has quit [Quit: smeso]
<geist>
at some point i poked around to see if i could find a device with an actual set of UEFI firmware on it
<geist>
nic or whatnot, but so far didn't find anything
<gog>
there's usallly a loaded image device path to the firmware interface app
<gog>
it's not really on a filesystem
<doug16k>
the shell is a program in the rom yeah
<geist>
yah not a FS per se but some sort of table of contents
<doug16k>
that enumerates all the filesystems and starts you on no drive whatsoever. you switch to an fs like fs0:
<doug16k>
it lists them at start
<geist>
oh sure
<doug16k>
yeah think of it like a drive letter table with string names, not one letter
<geist>
it doesn't howeer attempt to present the firmware itself as a FS though seems there there has to be some sort of TOC there with more than one piece of firmware
<doug16k>
fs0: fs1: ...
<doug16k>
that is just the shell though
<geist>
indeed. as basically all OSes i've worked with *other* than cpm and dos
<doug16k>
once you are in a program, you get an interface to one fs
<geist>
really it's the 8 bit 'i have a fixed number of entries' cpm that caused it to start numbering things a: b: c:
<geist>
most DEC oses that cpm was a simple clone of yet you define string:
<doug16k>
per pointer to EFI_SIMPLE_FILE_PROTOCOL or whatever
air has quit [Ping timeout: 272 seconds]
air has joined #osdev
<doug16k>
it made sense to just throw names on them like that. nice and short
<doug16k>
one instruction
<geist>
VMS itself worked much closer to, lo and behold, NT. SYS: is set up as a systemwide alias to DeviceFoo$partition$etc
<geist>
user: etc etc
<doug16k>
\\.\PhysicalDisk0
<doug16k>
IIRC
<doug16k>
would be accepted from CreateFile I mean
<doug16k>
sorry, PhysicalDrive0
<doug16k>
UNC name with . meaning this machine
<doug16k>
oddly
smeso has joined #osdev
<geist>
yep
<geist>
aliases and whatnot in VMS are kinda like a global environment for UNIX
<geist>
except they also work in stuff like open calls and whatnot
<geist>
vs just being a list of strings that code has to actualy choose to use
<doug16k>
tape drives are \\.\TAPE0 ..., changers are \\.\Changer0 ...
<doug16k>
stuff that nobody ever uses in windows
<geist>
yah and NT chooses to hide the whole alias stuff in the kernel for the most part
<doug16k>
I think the \\.\ scheme is alright, wonder if I should adopt that
<doug16k>
forward slashes though
<geist>
dunno but i do like the idea of being able to set stuff like $FOO or whatnot and then have all apis uniformly recognize it
iorem76 has joined #osdev
<geist>
though possibly it's a terrible security nightmare by todays standards, vs some sort of capability and/or restricted view like thing where your process only gets to see the fiction it was presented it
<geist>
fuchsia uses that like crazy
iorem has quit [Ping timeout: 268 seconds]
<gog>
ah yes like the matrix but for computational environments
<gog>
the thousands of agent smiths is just a forkbomb attack
<bslsk05>
gcc.gnu.org: Standards (Using the GNU Compiler Collection (GCC))
<moon-child>
clang and tcc ditto
<riverdc>
thanks
<johnjay>
> GCC does not provide the library facilities required only of hosted implementations, nor yet all the facilities required by C99 of freestanding implementations on all platforms.
<geist>
riverdc: note it doesn't *always* do it based on what it knows about the architecture, if it can just implement a copy locally, etc
<clever>
so you can give the right variation yourself
<geist>
note i think this can be ABI specific when implementing builtin copies like this. i *think* arm32 ABI has some notions of __aebi_memcpy8 or something like that. you can implement it as a wrapper around memcpy, but it's giving you a hint to the alignment, IIRC
matt|home has joined #osdev
<kingoffrance>
"though possibly it's a terrible security nightmare by todays standards" thats kind of, from what i see, why "magic symlinks" didnt go far....but it also generally would be transparent i believe...
<geist>
yah
<geist>
it's kinda neat how VMS solved stuff like drive letters and volumes by simply letting the global alias system deal with it
<geist>
seemed like kinda a nice unified system
<kingoffrance>
seems like would make life good for admins :)
<geist>
yah
<geist>
what i dont know is precisely how the scoping worked. i think some aliases may have been global and some local? which really also NT picked up with global environment variables and local ones
<geist>
also for example VMS didn't really have a notion of a current working directory, to cd you 'set def <path>' and that was a shortcut for setting the default prefix for non absolute paths
<geist>
you're really kinda just setting an environment varibale that is then resolved by subsequent dir and file opens
<kingoffrance>
that almost seems cleaner in a way.....
<kingoffrance>
because in unixland $PWD is gonna do that anyways...
<geist>
yah i guess that means path resolution on directories is basically always absolute
iorem76 has quit [Quit: Connection closed]
<geist>
well i mean path resolution on file path commands
<geist>
ie open("foo") internally expanded to $DEFAULT:foo or something
<geist>
i do know that you can, for example, cd to a non existant dir. shell dont care, stuff just stops working until you cd to someplace legit
<kingoffrance>
that happens on unix too if dir disappears out from under you :)
<geist>
true, but since cwd holds a open fd, you can end up in that place where you're inside a dir that has been deleted or moved
<geist>
and in some sense that's neat, but its also an anti feature in a lot of ways
iorem has joined #osdev
<geist>
$ show def
<geist>
SYS$SYSDEVICE:[USER.GEIST]
<geist>
for example
<geist>
ah it's a huge result, but 'show logical' gives a huge dump of all the assignments
<kingoffrance>
logical as opposed to bitwise, yes :)
<geist>
it's neat too, it shows a whole pile of tables, starting from process local, to session, user, node, and up through cluster
<geist>
lots of the logical assignments are per cluster, so all the nodes can see the same volumes, etc
<kingoffrance>
i am curious "scoping" now
<kingoffrance>
that sounds awesome
<geist>
seems to go LNM$PROCESS_TABLE to LNM$JOB_A11C5400 (the job my process is in, i thnk basically a session)
<geist>
LNM$GROUP_000030 is i think the user group i'm in
<geist>
LNM$SYSTEM_TABLE local to this node
<geist>
LNM$SYSCLUSTER_TABLE is local to this cluster
<geist>
theres a bunch of ACLs on each table as to what you can and cant do with it, so presumably the higher level ones i can't edit
<geist>
also the system assignment table is where you get volume names like
<geist>
"SYS$SYSDEVICE" = "SCSI$DIA0:"
<geist>
that's tying the volume name to the device path
<doug16k>
should I be mapping MMIO windows into a particular range in qemu aarch64 virt vm?
<doug16k>
I just realized it is still using x86 range - probably horrible
<doug16k>
I threw it all right below 0xe0000000 on x86, and below port 0xe000
<geist>
yah i think you probably shold yes
<geist>
the 0xe000.0000 is almost certainly not okay
<geist>
well may be okay if you know memory isn't there
<doug16k>
is that what this range is: 0000000010000000-000000003efeffff (prio 0, i/o): alias pcie-mmio @gpex_mmio 0000000010000000-000000003efeffff
<bslsk05>
github.com: qemu/virt.c at master · qemu/qemu · GitHub
<doug16k>
ok that's good place
<geist>
no, that's not 512GB offset, thats' 512GB *size*
<geist>
read it more closely. the second aperture is more dynamic
<geist>
see the comment above it
<geist>
i forget precisely when it decides to use the lower or the upper ECAM
<geist>
i think it may simply be based on what version of the virt machine it's emulating and the upper ecam is the new one
<geist>
or... the ecam is aliased in both spots
<doug16k>
I thought hideous PCI devices might have some upper bits stuck at zero if they don't support full address decoding
<geist>
well, possible, but this is all fake
<doug16k>
yeah
<geist>
fake devices dont do stuck bits. also arm64 being 64bit dont care about no <4GB stuff
<geist>
heck you can like your binary to load >4GB and it'll happily put it there if you want
<geist>
though i guess uefi can too if you want
<geist>
and since ram starts at 0x4000.0000 and just blows right over the 4GB mark there's only really ever once segment of ram. newer SoCs are doing that too, thye've generally moved their fixed bits below some physical mark and then just go ram from then on out
<doug16k>
nvram starts at 4000000 and ram starts at 40000000
<doug16k>
that was a bug before, lol
<doug16k>
ram has one more 0
thinkpol has quit [Remote host closed the connection]
<doug16k>
in gdb I defined a macro that does si then bt
<doug16k>
then run that and hit enter slowly
<doug16k>
in frame info it is always for this mode
<doug16k>
EL
<doug16k>
65 is easy. just remember 'A'
Oli has joined #osdev
elastic_dog has quit [Ping timeout: 245 seconds]
Oli has quit [Quit: leaving]
<doug16k>
not working now
elastic_dog has joined #osdev
srjek has quit [Ping timeout: 244 seconds]
<kazinsal>
ordered myself a macbook air m1 as an early birthday present. got a solid deal on a new-in-packaging but open box one, 1100 CAD shipped instead of 1400+ CAD shipped
<kazinsal>
entering the apple ecosystem feet first
<doug16k>
elr_mode is supposed to be 33
<doug16k>
page 9 of this is right, right? file:///tmp/mozilla_doug0/aadwarf64.pdf
<doug16k>
aarch 64 initializes all the displays and fills them
<klysm>
congratulations and good night
<doug16k>
GeDaMo, I sort of do that, my gdbstub gets a dedicated core
<doug16k>
so I can use a fork of the kernel image in private pages for the stub, and route the serial IRQ to that cpu so it won't interfere with the debug inferior
<doug16k>
can single step code with irq disabled by kicking it with NMI
<doug16k>
no IPI, no screwing with APIC while kernel is also doing stuff
<doug16k>
I mean no EOI
<doug16k>
stub uses private copy of the kernel pages so when step inserts breakpoints the stub won't trip them
<doug16k>
I have a thing though, that if the stub ever did manage to hit a breakpoint somehow, it singlesteps itself over it :)
<doug16k>
a breakpoint it knows about and has its old value
alexander has joined #osdev
dennis95 has joined #osdev
<klange>
ugh how does gcc find its own files... this was working fine in my last build...
<klange>
cc1, its special headers, etc.
<doug16k>
relative to itself I thought
<klange>
how does it know what itself is?
<doug16k>
the executable that is running
<klange>
Let me rephrase, by which method does it know where that binary is?
<doug16k>
you mean before you launched the compiler?
<doug16k>
oh exactly how? don't know
<klange>
darn
<klange>
yeah it seems it's... confused about where it should be looking for things
<doug16k>
usually it just works, right?
<klange>
oh great, I qualified its path and that fixed part of it... still can't find crtbegin.o or -lgcc (wut, there's an lgcc right _there_ you moron)
<doug16k>
did you enable multilib?
<klange>
irrelevant to this target?
<doug16k>
ok, but that affects where things end up, right?
<doug16k>
where they end up affects finding it
<doug16k>
not sure where I am going. just throwing it out there
<doug16k>
guessing what could make it get confused where things should be
<GeDaMo>
Would gcc -print-search-dirs help?
<klange>
why is my DESTDIR in this path
<klange>
THAT IS NOT HOW DESTDIR WORKS
<klange>
kljagelkwajgew;lakjgfewa
<klange>
wait that's not my destdir that's my current dir... is it... ugh... no, this is so wrong,
<klange>
now I get to figure out which function in my libc is wrong that didn't matter previously...
<klange>
> /usr/lib/gcc/x86_64-pc-toaru/10.3.0/libgcc.a: file not recognized: file format not recognized
<klange>
u wot
<klange>
hm, I rebuilt some headers while this was in t he middle of building, maybe it's screwing up a stat call...
mahmutov has quit [Ping timeout: 244 seconds]
Arthuria has joined #osdev
MarchHare has quit [Ping timeout: 252 seconds]
Arthuria has quit [Ping timeout: 268 seconds]
river has quit [Quit: Leaving]
qookie has joined #osdev
pretty_dumm_guy has joined #osdev
<klange>
$ gcc -o test test.c; ./test
<klange>
hello world
<klange>
okay finally
dutch has quit [Quit: WeeChat 3.1]
nyah has joined #osdev
transistor has quit [Ping timeout: 245 seconds]
<klange>
so I needed to fix 'struct stat' to use correct definitions, which required a full rebuild of a lot of stuff... I needed to add byte order macros to appease a configure script, but it didn't like my BSD ones, so I added the solaris one as well...
<klange>
and I had to fix a partially-implemented patch for fseek() and I'm actually slightly confused about how that worked and I suspect ghosts so I don't want to dwell on it
<klange>
no patches to gcc itself, no weird config options... runs on the thinkpad natively, so I can now hack on network tools on that - live!
<klange>
I should see if I can get the displayport output initialized for mirroring and toss one of my dp-hdmi adapters at one of my capture cards and then I can ~stream~
<doug16k>
nice, I finally know `make` well enough to do an out of source build, generate autodependencies, and put all that in an obj/ directory under the build dir, from a source tree that has a bunch of subdirectories, without VPATH
<bslsk05>
github.com: qemu-rom/Makefile at master · doug65536/qemu-rom · GitHub
richbridger has joined #osdev
gareppa has joined #osdev
<doug16k>
it's 242ms to clean build my rom :P
<doug16k>
and they said C++ compiles slow
<klange>
real 0m23.496s user 0m51.237s
<doug16k>
ya, C compiles at ludicrous speed
<doug16k>
never checked that before. after the build is finished, make is 2ms if you keep rerunning it
<doug16k>
I can only imagine the barrage of stat calls and stuff that occurred
gareppa has quit [Quit: Leaving]
<klange>
why imagine when you can strace
<doug16k>
yeah
<doug16k>
I meant how close together in time they'd be
<doug16k>
I need to figure out how to poke characters out the serial in aarch64 virt vm
<doug16k>
I must be poking at the wrong serial port
<klange>
virtio-console?
<doug16k>
pl011 - arm uart
<klange>
oh a legit one
<doug16k>
yeah
<doug16k>
oops, I forgot to pass -j32. clean build is 53ms :P
knebulae has joined #osdev
mahmutov has joined #osdev
<doug16k>
~3 monitor scans
<doug16k>
probably started every compile simultaneously and didn't have enough to use 32
<klange>
my preferred number is 16
<doug16k>
I have 16C 32T
<klange>
Desktop and Surface are 4C 8T, the T410 is 2C 4T.
<doug16k>
must be alright battery life on that
<doug16k>
I always get laptops with awful battery life because I get sucked into a fast cpu
<doug16k>
I think 17" screen is hardly tolerable. I end up with pizza box laptop
<klange>
The Surface is my fastest machine and also has great battery life. The T410 was... terrible even the day I bought it ten years ago _with_ the extended battery.
<doug16k>
wow
<klange>
That battery now has 65% manufacturered life, and I swapped it for a clone of the standard one.
<klange>
The T410 shows its age, the destkop (6600K, circa 2016) is just a bit disappointingly slower than the tablet, and I'm just bewildered by how stagnate the last decade feels.
<klange>
Anyway... gcc works, I made some minor improvements to the network tools, rain tomorrow so maybe I'll actually work on them more... time for bed.
<doug16k>
\o
<doug16k>
wow. make forgot toupper and tolower?
pretty_dumm_guy has quit [Quit: WeeChat 3.2-rc1]
alexander has quit [Ping timeout: 264 seconds]
mctpyt has quit [Ping timeout: 244 seconds]
Sos has joined #osdev
mctpyt has joined #osdev
transistor has joined #osdev
dutch has quit [Quit: WeeChat 3.1]
dutch has joined #osdev
gog has joined #osdev
alexander has joined #osdev
* gog
meows
air has quit [Ping timeout: 252 seconds]
gmacd has joined #osdev
Raito_Bezarius has quit [Ping timeout: 268 seconds]
Raito_Bezarius has joined #osdev
Oli has joined #osdev
iorem has quit [Quit: Connection closed]
theruran has quit [Quit: Connection closed for inactivity]
ZipCPU has joined #osdev
angelsl has quit [Ping timeout: 264 seconds]
angelsl has joined #osdev
MarchHare has joined #osdev
sortie has joined #osdev
asymptotically has quit [Remote host closed the connection]
<nur>
doug16k, hey... I didn't know gcc could compile asm
vai has joined #osdev
<GeDaMo>
gcc is the frontend for the GNU compiler collection
<nur>
ok let's see if this works
srjek has joined #osdev
Arthuria has joined #osdev
dennis95 has quit [Remote host closed the connection]
dennis95 has joined #osdev
dennis95 has quit [Remote host closed the connection]
dennis95 has joined #osdev
<geist>
nur: yah sorry, i assumed you knew that. that's why the c preprocessor is automatically run for #defines, etc
<geist>
name your file .S and feed it into gcc and it'll assemble it
<geist>
with a preprocessor, and still honor switches like -march and whatnot
dennis95_ has joined #osdev
dennis95 has quit [Remote host closed the connection]
dennis95_ has quit [Remote host closed the connection]
dennis95_ has joined #osdev
dennis95_ has quit [Remote host closed the connection]
dennis95_ has joined #osdev
<geist>
huh, my windows 10 VM that i'av ehad running forever just abruptly corrupted itself last night
<geist>
no repairs seem to be doable
dennis95_ has quit [Read error: Connection reset by peer]
<clever>
ive been using zfs snapshots around all of my vbox images
dennis95 has joined #osdev
<geist>
yah i can restore this one too from a btrfs snapshot, but it's still odd
<geist>
easy to chalk up to windows, but i worry that my VM setup isn't perfectly stable and this is a canary
dennis95 has quit [Read error: Connection reset by peer]
dennis95 has joined #osdev
<clever>
geist: i once had a windows machine blue-screening on startup, due to a bad sector in just the wrong spot, i used ddrescue to clone it, left the bad sector as nulls, and it booted like nothing was ever wrong.....
<doug16k>
nur, gcc can link too
<doug16k>
it's really just running ld or whatever actually linksd it, with some options possibly helpfully added
* sortie
delegates work to the people in the Sortix community
<sortie>
I am now unstoppable
* sortie
tries to let go of the need to have written almost all of his OS by himself and lets people help
<sortie>
Like people are trying to build on top of all my WIP stuff
<sortie>
I need this stuff *merged*
<sortie>
Even if imperfect, people can iterate
<sortie>
But there *are* blockers that needs fixing.
angelsl_ has joined #osdev
angelsl_ is now known as angelsl
angelsl has quit [Killed (strontium.libera.chat (Nickname regained by services))]
GeDaMo has quit [Quit: Leaving.]
<Sos>
hmmmm
<Sos>
my posix-uefi build compiled without maths lib
<Sos>
and linked
<Sos>
is it like static lib linking where it will just dangle extern calls?
<Sos>
and crash at runtime?
<Sos>
or did that thing actually pulled libm out of somewhere
<geist>
that's a good question
<clever>
Sos: i would run `objdump -d` against the file, and look at the call-site
<geist>
yah may be a bunch of unresolved externals, *or* however you compiled/linked it brought in some sort of libc
<geist>
uefi apps are PE based and i dunno precisely what the limitations are there
<clever>
ah right, uefi might do some runtime linking against a common library
<clever>
i'm used to fully static kernels, where i must supply everything
<Sos>
hmm i dissasembled it but i see nothing
<geist>
yah, but i dont think it does. fairly certain all the PE apps are self contained and the only external calls are via a runtime routine lookup mechanism and function pointers
<Sos>
ordinal calls?
<Sos>
nto mention of '_cosf' and such, should be there
<clever>
Sos: what about with `objdump -dr` i think it was?
<geist>
maybe it just did the work inline?
<geist>
did it call a local routine?
<geist>
or used an instruction
<Sos>
yeah my guess
<Sos>
just injected x87 code
<Sos>
treaded the calls as intrinsics
<Sos>
wait disasdsembly should find that
<geist>
try calling something more exotic
<geist>
right
<geist>
you'd see the equivalent, or a call to a library routine that got statically linked
<geist>
hence why dissassembly answers all
<Sos>
Search "fld" (0 hits in 0 files)
<Sos>
i'm just gonna let it crash and go look for a libm
<Sos>
(is there a nice minial libm out there?)
<geist>
well, you can tell from the dissassembly what it did
<geist>
like, did it make a call to something external, replace it with a local, or elide it
<geist>
it's all right there
<geist>
perhaps it elided it because it decided it didn't need the result?
<clever>
ive worked around that by storing the result in a volatile local var
<Sos>
i'm gonna need that libm one way or another :P gonna go hunt for one
<geist>
unless its already linking one. hence figure out the scope of your problem before diving into it
uplime has joined #osdev
<Sos>
alright the disassembly shows no calls nor x87 functions where the math stuff like cos and sin should be
<clever>
Sos: printf the result maybe?
<geist>
perhaps it elided it? did you actually use the result?
<Sos>
clever, got that
<geist>
or did you pass it a constant and the compiler solved it at compile time for you?
<doug16k>
yeah, there are builtins for practically every math function. if you make it too easy, the compiler will just know the ansewr and use a constant
<Sos>
but it looks interwined quite a bit dunno if i want to cut it out
<doug16k>
--static
<Sos>
i coudl jsut wirte intrinsics myself
<Sos>
doug16k, that's not libm :P
<doug16k>
Sos, what?
<Sos>
i'm jst lookinf for a minimal math implementation
<doug16k>
I thought you wanted nonsensical linking to stop. ok
<doug16k>
nosensically link libm
<Sos>
that might actuall help too, tho :)
<doug16k>
what does the disassembly at 0x78c0 look like, in that paste scenario?
<doug16k>
piles of sse?
<doug16k>
tons of "*ss"/"*sd" instructions?
<Sos>
it's not there
<doug16k>
can you show your link command line from your build or wherever?
<Sos>
it's alright,m I can take it from there, thanks!
<doug16k>
ok
<Sos>
thank you for all your help!
* Sos
learnt a lot
<doug16k>
I had to dink around a bit to get efi linking 100%
<doug16k>
I get bad codegen actually
<doug16k>
it's not the code - ld screws up relaxations
<doug16k>
if you are encountering that problem, try adding -mcmodel=large
<doug16k>
it makes the codegen never need that relocation
<doug16k>
relaxation*
dennis95 has quit [Remote host closed the connection]
<doug16k>
it was supposed to convert mov thing@got,%rax to lea thing(%rip),%rax but outputs mov thing(%rip),%rax
<doug16k>
and it's almost impossible to convince me it's the linker or compiler's fault. I'm convinced 100% on this one
<gmacd>
Hi - anyone here got experience of using bootboot? Looks like promising, but curious of others thoughts before I try to use it.
<doug16k>
I should add riscv64 to my rom project. all the non-x86 hardware stuff should port right over
<Sos>
gmacd, seen it but never used it
<Sos>
looks pretty promsing
<doug16k>
it's similar to my bootloader in several ways
<doug16k>
it enters your kernel in long mode, already high half, like mine
<doug16k>
I support {efi|bios}-{disk|cd|lan} boot, all 6. just x86_64 so far, but aarch64+rpi4 and aarch64vm+efi coming eventually
<gmacd>
I like the idea of a thin layer to hide some of the really crufty bits (like getting into 64bit mode and not having to worry about bios or uefi). Do you have a link for yours?
<bslsk05>
github.com: dgos/boot at master · doug65536/dgos · GitHub
<doug16k>
has full unicode fat32 lfn and joliet builtin fs
<doug16k>
you can make efi build use that or use efi apis
<doug16k>
inside the bootloader it presents an abstraction and various shims do whatever this type of boot should do
<gmacd>
thanks, will take a look
<doug16k>
bios call, call filesystem and block I/O, call simple filesystem protocol and high level I/O, "open" and "read" files on pxe by starting a download into a cache and download up to the point you need, on demand
<doug16k>
the elf loader just opens files and reads them, oblivious about being in pxe/lan boot
pieguy128 has quit [Ping timeout: 272 seconds]
<doug16k>
it's 32 bit mode in bios case, and long mode in uefi case. eventually it enters long mode kernel
pieguy128 has joined #osdev
<doug16k>
I hand-did all the efi stuff, from the tianocore references, and by configuring gcc to build and support those types of executables
<doug16k>
the declarations of efi I mean
<doug16k>
efi is essentially a pile of struct types and constants. you do the last mile of linking at runtime by getting vtables
<doug16k>
not one byte of binary stuff to link in. it's 100% your code using the pointer they gave at the entry point to bootstrap out to getting pointers to interfaces to everything
pieguy128_ has joined #osdev
pieguy128 has quit [Ping timeout: 264 seconds]
dormito has quit [Ping timeout: 268 seconds]
dormito has joined #osdev
<doug16k>
I have a baffling relocation truncated that doesn't make any sense
<bslsk05>
github.com: qemu-rom/pci.cc at master · doug65536/qemu-rom · GitHub
<doug16k>
what is the difference between fpie and fPIE anyway? "fpie and -fPIE both define the macros "__pie__" and "__PIE__". The macros have the value 1 for -fpie and 2 for -fPIE." <-- ok, that's nice. but why?
<doug16k>
PIE screams it, pie says it all softly?
<doug16k>
screaming is bigger number. makes sense
<doug16k>
sounds legit
alexander has quit [Ping timeout: 252 seconds]
<doug16k>
I found the bug
hgoel has joined #osdev
<doug16k>
I didn't pass -fpie to compile, only link. doh!
<clever>
doug16k: ive also found that most PIE flags, are never purely PIE, they just reduce how much relocations patching you need
<kingoffrance>
probably not helpful, but i did see target-dependent difference, ancient manpage fpic PIC for use in a shared lib fPIC PIC for dynamic linking, no limit on size of GOT pie PIE -- listed as synonyms, "but generated PIC can be only linked into executables" however, on "FRV" -mfdpic without anything else, implies fPIE with fpic or fpie, assumes GOT entries and small data are w/in 12-bit range from GOT base address with P
<kingoffrance>
IC or PIE, GOT offsets are computed with 32 bits
<kingoffrance>
so UPPER in that ancient instance, removes some limits
<kingoffrance>
did they stick with this convention? i have no idea
Oli has quit [Ping timeout: 245 seconds]
<doug16k>
ok, sounds like, sometimes, -fpi{c,e} is "small model" fastest code pic, and fPI{C,E} is large model PIC
transistor has quit [Ping timeout: 265 seconds]
<doug16k>
for processors that have some short range pc-relative stuff but easily overflowed on significant program, so need upper one then
<doug16k>
lower one means be super aggressive and try to use the short range stuff
<doug16k>
that makes sense
<doug16k>
so for "don't care, just compile the thing" use the upper one every time
<doug16k>
for "oooh, I bet I can save some nanoseconds", lower one
transistor has joined #osdev
<doug16k>
aarch64 is like x86 with pie - you might as well use it because the codegen is better usually
<doug16k>
because it's always there and even when you don't "use" pie, the codegen tries to use the pc-relative (pi{c,e}) encoding because it's smaller
<doug16k>
on x86_64
<doug16k>
same with aarch64 - it's pc relative by nature
<doug16k>
because that is a cool trick to make the numbers be within a reasonably small range
<doug16k>
the number it uses to represent where something is
gmacd has quit [Remote host closed the connection]
sortie has quit [Quit: Leaving]
krychu has joined #osdev
<doug16k>
geist, force youtube to give me a button to reverse the order of my youtube playlists for me, would you? :P
<doug16k>
it says "and suggestion taker" under the engineering title on your door, right?
riposte has joined #osdev
<doug16k>
maybe make it a code-golf thing, send one out where they have to reverse the order of a youtube playlist with less than 12 instructions
<doug16k>
fewer than*
<doug16k>
database connection and all
riposte has quit [Quit: Quitting]
riposte has joined #osdev
orthoplex64 has quit [Read error: Connection reset by peer]
Oli has joined #osdev
<doug16k>
this should make a character pop out, right? pl011_write addr 0x00000000 value 0x00000033
<doug16k>
without initializing anything
<doug16k>
trace proves I an poking at the UART data register
<doug16k>
'3' I think
<clever>
doug16k: for real hw or qemu?
<doug16k>
qemu
<clever>
i think qemu lets you do that, skip right to DR and not initialize anything
<doug16k>
yeah I thought so. I must be connecting the wrong serial to stdio
<clever>
if you open a gui, you can break each serial off into its own window
<doug16k>
oh right!
<clever>
the console too, so you can debug register states
<doug16k>
it's working
<doug16k>
thanks
<doug16k>
it is connecting the wrong one to stdio
<uplime>
very silly question, but its been a while since I've done this stuff... I don't need to do https://wiki.osdev.org/Building_GCC if my system compiler (v10.2) is the same version I need for the cross compiler right?
<bslsk05>
wiki.osdev.org: Building GCC - OSDev Wiki