Search logs:

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=18&m=5&d=16

Wednesday, 16 May 2018

00:00:00 --- log: started osdev/18.05.16
00:01:51 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
00:03:27 --- quit: hydraz (Ping timeout: 240 seconds)
00:04:51 --- quit: ybden (Ping timeout: 255 seconds)
00:05:02 --- join: DeepIO (~deepio@dyndsl-080-228-180-202.ewe-ip-backbone.de) joined #osdev
00:05:07 --- join: hydraz (hydraz@coleridge.vehk.de) joined #osdev
00:05:07 --- quit: hydraz (Changing host)
00:05:07 --- join: hydraz (hydraz@unaffiliated/demhydraz) joined #osdev
00:05:34 --- join: ybden (ybden@coleridge.vehk.de) joined #osdev
00:06:26 --- quit: DeepIO (Quit: quit)
00:09:13 --- part: ifr0zen left #osdev
00:11:32 --- join: bauen1 (~bauen1@gate.josefstal.de) joined #osdev
00:11:46 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
00:18:05 --- nick: azonenberg -> azonenberg_
00:18:07 --- nick: azonenberg_ -> azonenberg
00:22:58 <klange> Just another day at work... got a (linux) kernel module that's not functioning properly (it's for a serial port chip, and it spits out incorrectly ordered / duplicated bytes) when built under gcc 6.3 with -O2, but in an older Debian Wheezy it was working fine. -O1 in the newer gcc works as well.
00:25:15 <klange> my usual approaches have failed, ubsan doesn't catch anything interesting...
00:25:53 --- quit: bauen1 (Remote host closed the connection)
00:38:32 <variable> klange: lol
00:39:44 <klange> worse, it's a 3rd-party driver that was deprecated because upstream got support for this device in 4.11 or something
00:39:55 <klange> but we're on 4.9-rt
00:52:46 <Sjors_> nice
00:52:49 --- nick: Sjors_ -> Sjors
00:52:52 <Sjors> sounds like fun
00:57:48 --- quit: ZephyrZ80 (Quit: Leaving)
00:59:50 <Mutabah> printf spam?
01:01:31 --- join: sdk93 (uid290141@gateway/web/irccloud.com/x-ptpmnywdvbieqtci) joined #osdev
01:02:06 --- join: Kimundi_ (~Kimundi@dynip-129-217-073-102.wifi.tu-dortmund.de) joined #osdev
01:05:11 --- quit: aalm (Ping timeout: 256 seconds)
01:09:16 --- quit: Goplat (Remote host closed the connection)
01:10:19 --- quit: zeus1 (Ping timeout: 240 seconds)
01:14:24 <geist> klange: hmm, that smells like something isn't using volatile register access like it should
01:14:37 <geist> and/or in general not ordering read/writes properly
01:15:41 <klange> here's some mysteriousness: I slapped an __attribute__((optimize("O2")) on the receive function and this magically fixed it, despite the fact that the module was already being built O2...
01:16:05 <klange> What could be different about O2 as a function attribute and O2 globally...
01:16:25 <geist> that's for the dissassembler to tell you
01:16:29 <Sjors> klange: can you compile the file to assembly with and without that, and diff the result?
01:16:34 <Sjors> or disassemble it, indeed
01:16:36 <geist> actually that's a perfect situation
01:16:53 <geist> now you have a reproducible test case with theoretically a single function difference
01:17:04 <Sjors> did you put that attribute in the source or header file? i.e. could it influence other compilation units or not?
01:17:08 <geist> so now you go to dissassembler and see what's different about em
01:17:18 <geist> i'm thinking it may influence if the function gets inlined perhaps
01:17:30 <Sjors> i.e. is it a difference in how it's called or what it does internally
01:17:39 <geist> or you thought it was being built with O2 globally but it really wasnt, etc
01:18:13 <geist> when looking through the dissassembly pay careful attention to the order that it acceses registers
01:19:17 --- join: divine (~divine@2001:470:8247:2::1000) joined #osdev
01:19:25 <klange> I explicitly built with O2 globally
01:19:45 <klange> it's a simple kernel module, there's only one compilation unit, and gcc docs say __attribute__((optimize)) only applies to definitions
01:20:05 <geist> either way, now you ahve something that theoretically is fairly narrow but makes a difference, so verify the dissasembly
01:20:20 <klange> but I am totes gettin different results with the two versions
01:20:31 <klange> global O2 is jumpier
01:20:38 <geist> that's a perfect situation
01:20:52 <Sjors> I am eagerly awaiting your upcoming ah erlebnis
01:21:44 --- join: pclj (~user@183.62.141.106) joined #osdev
01:22:22 <klange> I see different inlining for sure in the function-attribute O2 version
01:22:39 <klange> global one has more inlining
01:22:56 <geist> yeah that was my guess, it breaks the ability for it to inline
01:23:05 <geist> another way of testing that is put in the 'dont inline' attribute on it
01:23:20 --- join: zeus1 (~zeus@197.239.7.45) joined #osdev
01:23:24 <geist> no inline i think
01:23:56 <klange> the function itself is an interrupt handler, so I don't think *it's* being inlined anywhere, but I'll toss a few inline hints at it and see what happens
01:24:20 <geist> so anyway, did you validate that it's using voltilate register accesses?
01:24:37 <geist> if it weren't and the compiler generally inlined the crap out of stuff, it'll have much more ability to reorder register accesses
01:24:51 <geist> and/or elide them
01:25:55 <klange> eh, it's all mmio readb/writeb
01:26:22 --- quit: MaryJaneInChain (Remote host closed the connection)
01:26:33 <geist> and those for sure can't be rearranged?
01:27:00 <klange> uncertain, but possible
01:27:35 <geist> well, i'm going to sleep. i expect a report on my desk in the morning
01:29:19 <Sjors> :D
01:43:03 --- quit: ACE_Recliner (Remote host closed the connection)
01:46:53 --- join: aalm (~aalm@37-219-237-30.nat.bb.dnainternet.fi) joined #osdev
01:51:43 --- quit: zeus1 (Ping timeout: 255 seconds)
01:52:21 --- quit: hmmmmm (Remote host closed the connection)
01:57:43 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
01:59:23 <Vercas> klange: So something that gets inlined *inside* it is messing up... First thing I'd look at is uninitialized variables passed as values. :P
02:02:10 --- quit: booyah (Remote host closed the connection)
02:02:52 --- quit: MarchHare (Ping timeout: 256 seconds)
02:06:03 <klange> inlined memcpy_fromio seems to be at fault
02:08:12 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
02:08:27 --- join: zeus1 (~zeus@h1abf.n1.ips.mtn.co.ug) joined #osdev
02:13:22 <klange> replacing it with a loop over ioread8 seems to have fixed it - I wonder if the inlined memcpy was clashing with some memory caching - there's some warnings around that memcpy_fromio shouldn't be used in certain cases
02:23:08 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
02:28:57 --- quit: zmzm (Quit: zmzm)
02:30:50 --- join: pclj` (~user@183.62.141.106) joined #osdev
02:32:06 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:32:06 --- quit: pclj (Remote host closed the connection)
02:32:55 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
02:40:15 --- quit: vaibhav (Quit: Leaving)
02:42:30 --- join: Tazmain (~Tazmain@196.35.34.5) joined #osdev
02:43:01 --- quit: Tazmain (Changing host)
02:43:01 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
02:43:27 --- quit: Arcaelyx (Ping timeout: 276 seconds)
02:46:54 --- quit: doug16k (Read error: No route to host)
02:50:43 --- join: Kimundi__ (~Kimundi@dhl1116.cs.uni-dortmund.de) joined #osdev
02:51:19 --- quit: Kimundi_ (Ping timeout: 240 seconds)
02:57:20 <Vercas> klange: Is that meant to be a wrapper for `rep insb`?
02:57:42 --- quit: kasumi-owari (Ping timeout: 256 seconds)
02:58:29 --- join: kasumi-owari (~kasumi-ow@ftth-213-233-237-007.solcon.nl) joined #osdev
03:00:06 <klange> it does appear to just be an alias to memcpy on x86, which... whatever that ends up being in linux
03:00:06 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:00:24 <klange> x86-64 i should specify
03:01:50 --- join: lachlan_s (uid265665@gateway/web/irccloud.com/x-jympbpmwbxcchrxd) joined #osdev
03:03:07 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:03:14 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:03:19 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
03:03:20 --- quit: doug16k (Max SendQ exceeded)
03:03:47 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:03:49 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
03:03:50 --- quit: doug16k (Max SendQ exceeded)
03:04:19 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
03:04:19 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:04:20 --- quit: doug16k (Max SendQ exceeded)
03:04:49 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
03:04:50 --- quit: doug16k (Max SendQ exceeded)
03:05:19 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
03:05:20 --- quit: doug16k (Max SendQ exceeded)
03:05:46 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
03:06:49 --- join: booyah (~bb@193.25.1.157) joined #osdev
03:08:22 --- quit: oaken-source (Quit: Lost terminal)
03:09:14 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:10:27 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:14:24 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:14:25 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:14:58 <izabera> what could cause gcc to emit an instruction between push %rbp and mov %rsp, %rbp ?
03:15:04 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:15:53 <Mutabah> Are you seeing that? or asking if it would?
03:16:02 <izabera> i do see that
03:16:21 <izabera> like, i have the binary and it was compiled with gcc
03:16:21 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:16:35 <izabera> i'm trying to reproduce this behavior and i'm not sure how to do it
03:20:17 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:20:17 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:25:45 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:26:59 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:31:00 <ZipCPU> pipeline scheduling?
03:31:13 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:31:44 <izabera> yeah i'm looking at instruction scheduling right now
03:31:44 --- quit: Oxyd76 (Read error: Connection reset by peer)
03:31:50 <izabera> not really something i'm familiar with
03:31:54 --- join: lldd_ (~atrapado@unaffiliated/atrapado) joined #osdev
03:32:21 <izabera> there's -msched-prolog but that seems to be arm only
03:33:06 --- join: zmzm (~zmzm@gateway/tor-sasl/zmzm) joined #osdev
03:47:31 --- quit: Naergon (Ping timeout: 264 seconds)
03:48:39 --- quit: zmzm (Quit: zmzm)
03:51:39 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
03:51:43 --- quit: pclj` (Ping timeout: 240 seconds)
03:58:51 --- quit: Oxyd76 (Read error: Connection reset by peer)
04:01:56 --- join: pclj` (~user@183.62.141.106) joined #osdev
04:02:00 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
04:02:07 --- quit: Oxyd76 (Read error: Connection reset by peer)
04:02:34 <jp> izabera: which instruction was it?
04:04:41 <izabera> i have two examples: one is
04:04:43 <izabera> push %rbp
04:04:45 <izabera> mov $0x7b,%eax
04:04:47 <izabera> mov %rsp,%rbp
04:04:58 <izabera> and the other is
04:05:00 <izabera> push %rbp
04:05:02 <izabera> mov %edi,%r11d
04:05:04 <izabera> mov %rsp,%rbp
04:05:39 <izabera> they come from the vdso implementation of getcpu and clock_gettime
04:06:09 <izabera> so you can probably find them in any modern system
04:06:15 <izabera> i'm on fedora 28
04:06:25 <izabera> linux 4.16
04:07:18 --- join: frolv (~frolv@CPE00fc8d4905d3-CM00fc8d4905d0.cpe.net.cable.rogers.com) joined #osdev
04:09:14 <jp> i was wondering if maybe it was stack alignment related
04:09:19 <jp> but it isn't at all
04:09:19 <jp> hm
04:09:32 <izabera> the funny thing is that getcpu needs 0 stack space
04:09:59 <izabera> it looks like this int getcpu(unsigned *cpu, unsigned *node) { unsigned eax = __getcpu(); if (*cpu) *cpu = eax & 0xffff; if (node) *node = eax >> 12; return 0; } and __getcpu is a static inline function that just does mov $123, %eax; lsl %ax, %eax
04:10:11 <jp> the pipeline scheduling does seem like the most plausible
04:10:20 * jp also doesn't know too much about that
04:13:58 --- join: Asu (~sdelang@80.202.154.77.rev.sfr.net) joined #osdev
04:14:11 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
04:23:25 --- join: NaNkeen (~nankeen@115.164.80.206) joined #osdev
04:25:46 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
04:54:51 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
04:57:43 --- quit: immibis (Ping timeout: 248 seconds)
05:03:47 --- join: kimundi (~Kimundi@dynip-129-217-073-102.wifi.tu-dortmund.de) joined #osdev
05:04:11 --- quit: Kimundi__ (Ping timeout: 260 seconds)
05:11:22 <doug16k> izabera, you can make the compiler omit frame pointer on leaf functions: -momit-leaf-frame-pointer
05:11:33 <doug16k> on some architectures. it is available on x86
05:11:52 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:12:31 <Vercas> izabera: It's simply a pipeline optimization. The push changes RSP so the mov that uses RSP and source needs to wait for the register to be available to read it.
05:12:56 --- quit: pclj` (Read error: Connection reset by peer)
05:13:18 <Vercas> Can't say this optimization is effective these days, but at some point it was really handy.
05:15:41 <doug16k> x86_64 abi requires the stack to be realigned (the call instruction's push of the return address misaligns it), so it is almost free to push rbp. the alternative would be to sub 8 from rsp
05:16:43 <doug16k> in a leaf, you could just leave it misaligned though, it wouldn't matter, nothing would "see" it misaligned anyway
05:17:05 --- join: bender (uid106562@gateway/web/irccloud.com/x-hctvmyiclhofwtra) joined #osdev
05:35:19 --- quit: ACE_Recliner (Ping timeout: 240 seconds)
05:35:48 --- quit: qeos|2 (Read error: Connection reset by peer)
05:36:12 --- join: qeos|2 (~qeos@ppp91-79-242-242.pppoe.mtu-net.ru) joined #osdev
05:43:09 --- join: rafaeldelucena (~rafaeldel@2804:14d:ba83:2709:8c8e:1e43:f519:7c7c) joined #osdev
05:46:43 --- join: oaken-source (~oaken-sou@p5DDB5060.dip0.t-ipconnect.de) joined #osdev
05:57:56 <izabera> does the x86-64 abi guarantee that all the registers are zeroed at startup?
05:58:02 <izabera> like, all except rip and rsp
05:59:43 <izabera> ah i found it in the standard
06:00:12 <izabera> actually no
06:00:44 <izabera> ah i see
06:00:52 <izabera> only rbp rsp and rdx are specified
06:01:12 <izabera> but linux seems to zero everything else
06:08:04 <doug16k> izabera, probably to avoid leaking any information. for the same reason, I clear all of the call clobbered registers when returning from a syscall, for example
06:12:11 --- quit: NaNkeen (Ping timeout: 276 seconds)
06:17:40 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
06:18:13 <doug16k> does anyone have a version of x86-64 abi higher than version 0.99.7?
06:18:35 --- quit: Oxyd76 (Read error: Connection reset by peer)
06:19:37 <doug16k> chapter 8 of mine has one sentence: "Not done yet" :D
06:19:45 <doug16k> not done yet? more like not started yet
06:20:17 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:21:45 --- join: NaNkeen (~nankeen@115.164.80.206) joined #osdev
06:22:59 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
06:25:16 --- quit: aalm (Ping timeout: 260 seconds)
06:26:27 --- quit: Oxyd76 (Read error: Connection reset by peer)
06:28:20 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
06:28:49 --- join: vmlinuz (~vmlinuz@2804:431:f725:9354:9a98:c273:9571:d75d) joined #osdev
06:28:49 --- quit: vmlinuz (Changing host)
06:28:49 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
06:28:49 --- quit: Oxyd76 (Read error: Connection reset by peer)
06:37:19 --- quit: NaNkeen (Ping timeout: 264 seconds)
06:39:42 <doug16k> what is gcc doing with 0x3FFFFFFFFFFFFFF here: https://godbolt.org/g/NW2y5n
06:39:44 <bslsk05> ​godbolt.org: Compiler Explorer
06:44:09 <doug16k> checking for numeric overflow?
06:44:12 <Mutabah> upper limit on a value?
06:44:27 <doug16k> yeah that's what I tought
06:44:31 <doug16k> thought*
06:46:02 <doug16k> yep, that's what it is: https://godbolt.org/g/LtXETa
06:46:04 <bslsk05> ​godbolt.org: Compiler Explorer
06:46:04 --- join: light2yellow (~l2y@185.220.70.163) joined #osdev
06:47:17 <doug16k> it's pretty paranoid eh? :)
06:47:30 <XgF> common class of bug tbh
06:49:17 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
06:50:49 --- quit: jimi1 (Ping timeout: 240 seconds)
06:53:09 --- quit: elderK (Quit: WeeChat 1.9)
06:53:45 --- quit: Oxyd76 (Read error: Connection reset by peer)
06:54:17 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
06:56:24 --- quit: Oxyd76 (Read error: Connection reset by peer)
06:59:34 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
06:59:34 --- quit: Oxyd76 (Read error: Connection reset by peer)
07:09:43 <doug16k> izabera, oh by the way, -fno-schedule-insns2 prevents the prologue scheduling here: https://godbolt.org/g/F8J8zc vs https://godbolt.org/g/aF681d
07:09:44 <bslsk05> ​godbolt.org: Compiler Explorer
07:09:45 <bslsk05> ​godbolt.org: Compiler Explorer
07:09:57 <doug16k> I'm guessing you figured that out already though :)
07:12:37 <doug16k> should have just put them in one page -> https://godbolt.org/g/kYvvms
07:12:39 <bslsk05> ​godbolt.org: Compiler Explorer
07:17:27 <Vercas> doug16k: Did you find that documented anywhere...?
07:18:13 --- quit: JusticeEX (Ping timeout: 240 seconds)
07:22:47 --- nick: BronzeBeard -> EricB
07:26:12 --- quit: Humble (Ping timeout: 276 seconds)
07:26:16 --- join: aalm (~aalm@37-219-237-30.nat.bb.dnainternet.fi) joined #osdev
07:27:00 --- quit: m712 (Quit: bye-nyan!)
07:27:21 --- join: m712 (~annoying@unaffiliated/thefam) joined #osdev
07:28:01 --- nick: m712 -> mission712
07:28:03 --- nick: mission712 -> m712
07:32:55 --- join: hmmmm (~sdfgsf@pool-72-79-162-68.sctnpa.east.verizon.net) joined #osdev
07:35:58 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
07:37:48 --- join: Humble (~hchiramm@106.208.161.1) joined #osdev
07:38:43 --- quit: Oxyd76 (Read error: Connection reset by peer)
07:39:33 --- join: raiz (~root@fardan.info) joined #osdev
07:41:06 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
07:41:10 --- quit: Oxyd76 (Read error: Connection reset by peer)
07:41:35 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
07:42:15 --- quit: Oxyd76 (Read error: Connection reset by peer)
07:42:57 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
07:46:51 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
07:47:01 --- quit: Oxyd76 (Read error: Connection reset by peer)
07:47:11 --- join: m_t (~m_t@p5DDA104E.dip0.t-ipconnect.de) joined #osdev
07:54:06 --- quit: drakonis (Remote host closed the connection)
07:54:45 --- quit: xenos1984 (Quit: Leaving.)
07:55:41 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
07:56:21 --- join: masoudd (~masoudd@5.52.192.247) joined #osdev
07:57:34 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
08:08:41 --- join: m3nt4L (~asvos@2a02:587:a023:f000:3285:a9ff:fe8f:665d) joined #osdev
08:09:30 <bauen1> https://i.imgur.com/rXeeYB7.png
08:10:06 <bauen1> so this is the lower-left of a rather big framebuffer, any idea's why it doesn't clear correctly ?
08:11:22 <klange> are you totally sure you're writing to all those bytes?
08:12:33 <bauen1> no
08:13:05 <bauen1> yeah, it's an issue with the way I do tripple buffering somewhere ....
08:14:23 --- join: daniele_athome (~daniele_a@5.170.125.252) joined #osdev
08:15:26 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
08:16:43 --- quit: bender (Quit: Connection closed for inactivity)
08:17:04 --- join: S_Gautam (3bb6f5cd@gateway/web/cgi-irc/kiwiirc.com/ip.59.182.245.205) joined #osdev
08:17:49 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:25:45 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:29:40 --- quit: grouse (Quit: Leaving)
08:31:44 --- quit: S_Gautam (Changing host)
08:31:44 --- join: S_Gautam (3bb6f5cd@unaffiliated/gautams) joined #osdev
08:31:44 --- quit: S_Gautam (Changing host)
08:31:44 --- join: S_Gautam (3bb6f5cd@gateway/web/cgi-irc/kiwiirc.com/ip.59.182.245.205) joined #osdev
08:42:47 --- quit: daniele_athome (Ping timeout: 248 seconds)
08:48:28 --- quit: spare (Quit: leaving)
08:49:40 --- join: daniele_athome (~daniele_a@5.170.129.150) joined #osdev
08:50:19 --- join: dennis95 (~dennis@i577BCE1F.versanet.de) joined #osdev
08:56:49 --- quit: ACE_Recliner (Read error: Connection reset by peer)
08:59:16 --- quit: daniele_athome (Ping timeout: 260 seconds)
09:08:52 --- quit: drakonis (Remote host closed the connection)
09:13:37 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
09:16:19 --- quit: Tazmain (Quit: Leaving)
09:17:53 --- join: ZephyrZ80 (~Frank@c-67-181-64-37.hsd1.ca.comcast.net) joined #osdev
09:17:58 --- join: Asu` (~sdelang@AMarseille-658-1-42-7.w90-37.abo.wanadoo.fr) joined #osdev
09:18:07 --- quit: Asu (Ping timeout: 264 seconds)
09:18:20 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
09:19:57 --- quit: kimundi (Ping timeout: 240 seconds)
09:26:07 --- quit: banisterfiend (Ping timeout: 268 seconds)
09:44:21 --- join: BartAdv (uid90451@gateway/web/irccloud.com/x-ztxoqdnbuiqmsqlz) joined #osdev
09:48:26 --- quit: elevated (Quit: bye)
09:54:58 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:55:16 --- join: kimundi (~Kimundi@i577A9375.versanet.de) joined #osdev
10:12:32 <doug16k> Vercas, no, best version I could find is 0.99.7 from 2014
10:12:54 --- quit: vmlinuz (Ping timeout: 256 seconds)
10:16:25 <geist> doug16k: hmm, that no schedule insn2 is interesting
10:16:41 <geist> is that generally disabling a class of instruction scheduling optimizations, or is it specific to prolougues?
10:17:05 <doug16k> it disables an optimization pass. not specific to prologues afaik
10:17:31 <geist> yah that seems to be what the docs on the switch say
10:17:39 <doug16k> "2" is a pass done after register allocation
10:18:47 <geist> yeah unclear how much of that matters on a highly OOO machine nowadays, but it probably wont hurt, and then it benefits non OOO machines
10:19:19 <geist> something like an atom or an a53 definitely still call for this sort of thing
10:20:54 <doug16k> Vercas, oh you meant -fno-schedule-insns2. lol I thought you meant a newer x86-64 abi doc :D
10:21:13 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
10:21:16 --- quit: S_Gautam (Quit: S_Gautam)
10:21:44 --- join: MarchHare (~Starwulf@mo-184-5-204-232.dhcp.embarqhsd.net) joined #osdev
10:21:50 <doug16k> yeah, scheduling usually isn't very aggressive on x86 because heavy scheduling tends to increase register pressure
10:22:44 <doug16k> by extending the live range of values
10:23:11 <doug16k> and of course because OOO does it for you in hardware
10:23:16 <geist> yeah was thinking about that with something like vax or m68k where you had instructions that could operate memory to memory
10:23:30 <geist> the scheduling choices there are more complex, since you can just decide not to even bring it into a register
10:23:52 <geist> or maybe simpler, but it's basically a whole nother avenue of decision making, i guess
10:24:16 <geist> i gues you can on some class of x86 instructions too. add to memory address, that sort of thing
10:27:39 <doug16k> yeah, mem to mem is such a common operation, it's strange that it was not implemented more
10:28:13 <geist> oh -fdeclone-ctor-dtor is interesting
10:28:26 <geist> i've seen that exact problem before, annoying for embedded
10:29:05 <geist> -fdevirtualize-speculatively
10:29:25 <geist> i've seen the compiler do that before, and i was surprised. i think it was clang
10:29:35 --- join: vmlinuz (~vmlinuz@187.11.110.13) joined #osdev
10:29:35 --- quit: vmlinuz (Changing host)
10:29:35 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
10:30:53 <doug16k> I've always been amused by how vague the documentation is for "fexpensive-optimizations"
10:31:04 <geist> probably on purpose
10:31:13 <doug16k> "Perform a number of minor optimizations that are relatively expensive"... duh! really?
10:31:30 <geist> -fmerge-all-constants
10:31:33 <geist> is interesting too
10:32:05 <geist> says it may make your code non conformant since i may merge distinct constant variables
10:32:12 --- quit: bemeurer (Quit: WeeChat 2.2-dev)
10:33:08 <geist> with regards to the prologue/epilogue having stuff in it, -fshrink-wrap may also fix that
10:33:31 <geist> or specifically, turning it off
10:35:19 <doug16k> should, right? didn't though -> https://godbolt.org/g/k13Yr3
10:35:21 <bslsk05> ​godbolt.org: Compiler Explorer
10:35:54 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:36:17 <geist> ah guess not
10:36:43 <geist> guess it only affects that it must do it near the top of the function, and not after some amount of work
10:41:11 <doug16k> that code is an example that gcc barely even tries to schedule x86 code. it could have easily pushed rbp first, then started the movslq %edi,%rsp much earlier, then pushed r12, then started mov rbp,r12, etc
10:41:15 <geist> oh that's interesting, i've been using -ffunction-sections and -fdata-sections mostly because of linker time gc
10:41:26 <geist> but the optimization page warns that it may kill some optimizations
10:41:45 <geist> since the compiler cant assume a relative distance between stuff and there are certain optimizations that it can't do
10:41:57 <geist> like relaxing short calls
10:42:22 <geist> now whether or ot x86 or arm64 actually benefits from any call relaxing, i dunno. probably not, since their call reach is decent
10:43:04 <geist> and -fsection-anchors, which seems fairly useful
10:45:03 <geist> https://godbolt.org/g/737zTS is a good example of how data sections kills this optimization
10:45:04 <bslsk05> ​godbolt.org: Compiler Explorer
10:45:32 <geist> less so on x86 i think, because the need to do the data anchoring is probably less important because you can generally just directly rip relativ address something
10:47:18 --- quit: kimundi (Read error: Connection reset by peer)
10:48:05 --- join: kimundi (~Kimundi@i577A9375.versanet.de) joined #osdev
10:49:24 --- quit: MarchHare (Ping timeout: 260 seconds)
10:50:16 <doug16k> with PIE it is almost as bad, since it can't array index rip-relative -> https://godbolt.org/g/6PJj2a
10:50:18 <bslsk05> ​godbolt.org: Compiler Explorer
10:51:08 <doug16k> oops should have included non-pie -> https://godbolt.org/g/JGeQRq
10:51:09 <bslsk05> ​godbolt.org: Compiler Explorer
10:54:19 <doug16k> also check out the total lack of scheduling :D
10:55:17 <doug16k> ah, I guess it would rather squeeze something into the add dependency chain than try to get the address calculations ready earlier
10:56:06 <doug16k> if I were hand writing it I would probably do lea lea lea add add add, since I want that load to start asap
10:57:28 <doug16k> gcc probably did it right though, on second thought. I don't think it can lea that much in parallel
10:59:44 <geist> yah
11:00:08 --- join: zesterer (~zesterer@cpc138506-newt42-2-0-cust207.19-3.cable.virginm.net) joined #osdev
11:02:30 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
11:05:46 --- quit: masoudd (Read error: Connection reset by peer)
11:06:08 --- join: masoudd (~masoudd@5.52.192.247) joined #osdev
11:06:22 <doug16k> funny how that arm code doesn't try to get started on the first load as soon as it has the address ready
11:07:24 <geist> feed it a different cpu, like -mcpu=cortex-a72
11:07:29 <geist> it'll start moving some of the ldrs out
11:07:51 <doug16k> yeah it does there. neat
11:08:39 <geist> a53 is probablyclose to the real model, though interesting that i'd expect you to need to schedule even more on that core, which is mostly in order
11:09:11 <geist> a72 is OOO so you'd expect it to be less important there
11:11:23 --- join: Asu (~sdelang@80.202.154.77.rev.sfr.net) joined #osdev
11:11:34 --- quit: Asu` (Ping timeout: 268 seconds)
11:11:48 --- quit: masoudd (Quit: May your strings always be '\0' terminated.)
11:17:53 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
11:18:26 --- join: Ryanel (~Ryanel@104.220.91.246) joined #osdev
11:19:18 --- quit: andrei-n (Read error: Connection reset by peer)
11:20:07 <Ryanel> Hello, it's been a long time since I've been here.
11:20:43 --- join: andrei-n (~andrei@51.214-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
11:20:55 <matviy> On an x86 system, is there a way to clear or flush the serial output buffer using i/o ports?
11:23:34 <Ryanel> Seems there is. FIFO Control register has "Clear Receive FIFO" and "Clear Transmit FIFO" bits.
11:24:05 <Ryanel> source: https://en.wikibooks.org/wiki/Serial_Programming/8250_UART_Programming#FIFO_Control_Register
11:24:06 <bslsk05> ​en.wikibooks.org: Serial Programming/8250 UART Programming - Wikibooks, open books for an open world
11:25:35 <matviy> Ryanel: How did i miss that while googling :( Awesome, thanks!
11:27:06 <Ryanel> No problem, matviy
11:28:24 <geist> because you're relying too much on googling, instead of looking at the docs for the actual uart
11:43:25 --- quit: light2yellow (Quit: light2yellow)
11:45:14 --- quit: Asu (Remote host closed the connection)
11:48:27 <Ryanel> Hey, so I'm having an issue with my kernel. It's an i686 higher-half kernel in C++. I enabled the stack-smashing protector using -fstack-protector. I have a stub setup, so it theoretically should panic. Instead, when it gets to a place where the protector should be called, it jumps to a random address (usually 0xe05b), which is obviously wrong since it's a higher half kernel. Where should I start investigating?
12:05:42 <doug16k> Ryanel, jumping to e05b sounds like you did an indirect call using address 0
12:06:29 <doug16k> or it is simply triple faulting and you end up there from the reset
12:07:08 --- quit: MDude (Quit: Going offline, see ya! (www.adiirc.com))
12:07:31 <doug16k> Ryanel, what is telling you it ends up at e05b?
12:07:39 --- quit: vmlinuz (Ping timeout: 276 seconds)
12:08:19 --- join: vmlinuz (~vmlinuz@187.101.157.30) joined #osdev
12:08:19 --- quit: vmlinuz (Changing host)
12:08:19 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
12:10:09 <doug16k> matviy, there is a bit in the line status status register that tells you whether the transmit holding register is empty. when that goes to 0, every bit has been transmitted
12:10:28 <doug16k> er, when it goes to 1
12:10:42 <Ryanel> doug16k: I'm debugging using GDB (through qemu), currently. Once do_printf is called, IP = 0xe05b
12:10:57 <doug16k> Ryanel, then it reset
12:11:34 <doug16k> Ryanel, that is the address of the first instruction that the bios executes on cold boot / reset
12:11:48 <Ryanel> Oh, I see.
12:12:30 <doug16k> Ryanel, you can add "-d int" to your qemu command line and it will spew out information about every interrupt. that may help you narrow down what is happening
12:14:02 <doug16k> wild guess: you get a #GP, then it fails to execute that and it does "#DF" then it fails to execute that and it resets due to "triple fault"
12:16:16 <doug16k> another idea: maybe stack protector uses ud2 instruction to raise an undefined opcode exception, which is not hooked in your IDT: kaboom
12:16:33 <Ryanel> Where in the output for -dint does it say what exception was raised?
12:16:50 <doug16k> Ryanel, the interrupt number should be in there somewhere
12:16:52 <rain1> https://www.youtube.com/watch?v=kZRE7HIO3vk
12:16:53 <bslsk05> ​'The Thirty Million Line Problem' by Handmade Hero (01:48:55)
12:18:34 <doug16k> Ryanel, v=something <-- something is the interrupt number
12:18:53 <Ryanel> I see, 1 sec
12:18:55 <doug16k> (in hex)
12:22:33 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
12:24:38 <Ryanel> So, it's 0xE, 0x8, 0x3, 0xD, 0x8, then a bunch of SMI, and repeat (reset). So a Page fault, double fault (as interrupts are not configured), NMI, stack fault?, double fault, and reset.
12:26:07 <Ryanel> Wait whoops, page fault, double fault, breakpoint, GP, and another double fault
12:26:20 <doug16k> Ryanel, paging is on?
12:27:40 <Ryanel> Yes. Paging is on. Higher half kernel, First 4MB is mapped to 0xC0000000
12:28:17 <doug16k> you don't expect any page faults, right?
12:29:29 <doug16k> put a breakpoint at the very beginning of the page fault handler, and when it breaks there execute this gdb command: x /45wx $esp
12:31:02 <doug16k> the page fault entry point that is - the address in the IDT entry for exception 0x14
12:31:11 <doug16k> the 1st dword will be page fault error code, the second dword will be the address of the faulting instruction, 3rd should be your code segment selector
12:31:32 <doug16k> oops, command should be x /5wx $esp
12:31:39 <Ryanel> I don't have a page fault handler setup at this point.
12:32:02 <doug16k> do you have an IDT setup at all?
12:32:11 <Ryanel> It's early in the boot. This takes place after the console has been setup, as soon as do_printf() is called.
12:32:19 <Ryanel> IDT hasn't been setup yet, no.
12:32:36 --- join: tacco| (~tacco@i59F4A704.versanet.de) joined #osdev
12:33:41 <doug16k> ok, a more tedious approach would be to break into gdb before it happens, do "layout asm" do "si", then hit enter repeatedly to step until it fails
12:33:53 <Ryanel> Already there.
12:34:07 <doug16k> you know which instruction faults? what is it?
12:34:32 <Ryanel> 0xC01015b3: mov %gs:0x0, %eax
12:34:52 <doug16k> do you know how to get into the qemu monitor?
12:35:05 <Ryanel> Yup
12:35:17 <doug16k> go in there and execute: info registers
12:35:24 <doug16k> what does it say on GS line?
12:35:37 <Ryanel> gs =00010
12:35:57 <doug16k> further on that line, you see a base and limit, right?
12:36:34 <doug16k> ah... I see what's happening
12:36:37 <Ryanel> GS = 0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA]
12:36:50 <doug16k> the stack protector code is trying to get the address of the thread local data for this thread
12:37:46 --- quit: Oxyd76 (Read error: Connection reset by peer)
12:37:58 <Ryanel> hmm
12:38:07 <doug16k> Ryanel, your code isn't following the ELF ABI spec. the compiler assumes it is in effect
12:38:27 <doug16k> er, your environment isn't following the ELF ABI spec
12:38:59 <Ryanel> I don't understand how it couldn't be. I'm using an i686-elf cross-compiler, and my assembly code is using elf32.
12:39:08 <doug16k> at %gs:0 there should be a pointer to the thread local storage for the current thread
12:40:00 <doug16k> in your case, you didn't initialize the gsbase, so it is ending up accessing address 0. that page faults.
12:40:30 <doug16k> you expect accessing address 0 to page fault, right?
12:40:30 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
12:40:49 <Ryanel> Yeah, that makes sense.
12:41:22 <Ryanel> It's still not hitting me what to do though. I'd assume the compiler would set that up automatically.
12:41:43 <Ryanel> Oh. I disabled the startup code it would do that in, so it's not?
12:42:37 <doug16k> it isn't that hard to setup gs / TLS. see the elf spec. the linker does most of the work. basically you infer the needed size of the TLS from a few symbols in your linker script, allocate space for it, set gs segment base to point to it, put a pointer to itself at gs:0, and you should be good to go
12:43:51 <Ryanel> Alright, I'll work on that. Thank you. To be honest, I've been doing this for fun, so I hadn't really read the ELF spec yet.
12:43:53 <doug16k> I had TLS in a really early version of my kernel but have backed it out since, so I can't just point you to an example
12:44:41 <Ryanel> There appears to be an article on the wiki
12:44:45 <matviy> Sorry, noob question. When writing to the FIFO serial register using IO ports, there's no way to only write a single bit right? How can i set one bit from 1 to zero without messing all the other bits up?
12:44:52 --- quit: m_t (Quit: Leaving)
12:45:03 <doug16k> what you could do as a total hack is allocate a nice big chunk of memory, point gs segment base to the middle of it, and point gs:0 to the same address as the segment base. that should get you going
12:45:04 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
12:45:49 <doug16k> where "nice big chunk" is maybe 64KB or something. that should be tons
12:46:39 <doug16k> don't forget to zero it out before setting gs:0
12:47:07 <Ryanel> matviy: I think you have to just set all the bits. So, figure out which bits are set, and just write that byte.
12:47:50 <doug16k> matviy, no way to send bits. the whole point of a UART is for it to frame your bytes and shift out the bits
12:47:56 <Ryanel> doug16k: So essentially just what I did with my stack, give it a bunch of space and hope it works
12:48:36 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
12:48:40 <matviy> doug16k, sorry, i it's the control register that configures the UART, not the data in/out register
12:48:42 <doug16k> Ryanel, should work. I had fully working real TLS and my suggestion is basically the same thing, except I made it the exactly correct size
12:48:44 <matviy> I think i have to write all 8 bits at once
12:50:54 <doug16k> matviy, yes, all 8 bits at once, and depending on how you set up the line control register, the lower N bits of the written byte get sent, where N is 5, 6, 7, or 8
12:51:15 <doug16k> you almost certainly want it set to 8 bits, and maybe 7. 5 and 6 are ancient
12:54:41 <doug16k> Ryanel, oh, and since the compiler may generate code using a negative offset with gs, make the limit unlimited (4GB)
12:55:08 <Ryanel> Alright, i'll keep that in mind
12:58:46 <doug16k> matviy, oh. I see. if you want to set part of a register, you first read (in) that register, zero out the relevant bits in the value, set those bits to the desired value, and write (out) the whole byte to the port
12:59:57 --- join: gareppa (~gareppa@unaffiliated/gareppa) joined #osdev
13:01:46 <Ryanel> doug16k: The register in question says it's write only
13:02:03 <doug16k> which register?
13:02:10 --- quit: m3nt4L (Remote host closed the connection)
13:02:21 <doug16k> data register? you just write the whole byte there
13:02:47 <doug16k> tx data register I mean
13:03:59 <Ryanel> The FIFO Controller register is write only.
13:04:40 <doug16k> oh sorry, in that case you must write all of the fields of the register at once
13:06:11 <doug16k> I think it is only write only on really old UARTs. you need to read it on newer ones to detect fifo support
13:08:05 <doug16k> to detect 16550A, you see if the "receive trigger" field preserves both bits value. to detect (crap) 16550, it loses one bit of receive trigger. to detect 16750, you see if attempting to set the fifo64 field preserves the written value
13:09:03 <doug16k> on old uarts, writing the field has no effect and reading it back does not give you back the written value
13:10:32 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/device/serial-uart.cc#L455
13:10:34 <bslsk05> ​github.com: dgos/serial-uart.cc at master · doug65536/dgos · GitHub
13:19:43 --- quit: gareppa (Quit: Leaving)
13:20:36 --- quit: aalm (Ping timeout: 260 seconds)
13:21:48 --- quit: awang_ (Ping timeout: 255 seconds)
13:24:30 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
13:27:28 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
13:31:49 --- quit: awang_ (Ping timeout: 240 seconds)
13:34:03 --- join: MarchHare (~Starwulf@mo-184-5-204-232.dhcp.embarqhsd.net) joined #osdev
13:34:17 <Ryanel> doug16k: So I've added a GS and FS segment to my GDT, and I'm setting them (0x38 and 0x30 respectfully). Now I'm having trouble with figuring out storage.
13:34:49 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
13:39:30 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
13:42:56 --- join: aalm (~aalm@37-219-237-30.nat.bb.dnainternet.fi) joined #osdev
13:49:26 --- quit: elevated (Ping timeout: 268 seconds)
13:50:58 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
13:51:43 <pounce> doing CI on an OS is hard XwX
13:53:53 <Ryanel> pounce: What are you using? Travis?
13:55:14 --- quit: lldd_ (Quit: Leaving)
13:58:05 <geist> it is. CI for building is fairly easy, i use travis-ci for that
13:58:09 <geist> but actually runnign tests is more difficult
13:58:35 <pounce> yeah travis for building isn't bad, but I'm adding tests to it too
13:59:04 <Ryanel> Yeah, like how do you get output? My first guess is the serial port with a timeout, then comparing the logs with a "perfect" log.
13:59:06 --- quit: aalm (Ping timeout: 260 seconds)
13:59:35 <pounce> Ryanel: make a "test" target that will output TAP to the serial port and pipe it into a harness
13:59:56 <Ryanel> huh
14:00:22 <pounce> then you can run a bunch of tests in different parts of the kernel that are read by it
14:01:13 <lachlan_s> Do you have that running in Travis as well?
14:01:40 --- join: awang__ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
14:01:48 <geist> we have something like that for zircon, and basically we have a set of tests that run and output at the end of the run a known printf that can be grepped for
14:01:53 <geist> it's not amazing, but it works
14:02:11 <geist> fire up an instance in qemu, run the tests, look for the results on the serial port, etc
14:02:26 <pounce> lachlan_s: I do now! https://github.com/ESALP/ESALP-1/pull/32
14:02:29 <bslsk05> ​github.com: Use travis for testing TAP by 4e554c4c · Pull Request #32 · ESALP/ESALP-1 · GitHub
14:03:24 <pounce> gotta add some stuff (quick failure/shutdown on kpanic, assertions for interrupts, actually /passing/ my own tests) but it's looking good so far
14:04:03 <lachlan_s> Cool!
14:04:12 <pounce> speaking of qemu: since it's such a big project, if my patches aren't responded to for awhile should I ping it?
14:04:23 <lachlan_s> It's be useful to have something like that on nebulet
14:04:55 --- quit: awang_ (Ping timeout: 264 seconds)
14:09:05 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
14:15:37 <doug16k> Ryanel, set the base for the gs descriptor to point to the middle of the fake TLS block. then load gs. store a pointer with the same value as gs's base at the address where gs's base points
14:16:03 <doug16k> that should be valid enough to make TLS accesses work
14:16:26 <doug16k> note that that area should be zero initialized (except the pointer to itself as explained)
14:20:38 <doug16k> what will happen is, the compiler will emit thread local variables to a special section. each thread local variable will end up having a negative offset from the end of the TLS. the compiler will either access them directly using gs:negative_offset, or it will copy the pointer at gs:0 into a register and use that with an address calculation that uses the appropriate offset from that to access this thread's copy of that thread local
14:20:39 <doug16k> variable
14:20:39 --- quit: vmlinuz (Quit: Leaving)
14:21:07 <Ryanel> The issue I'm having is that I've set the area as part of the tbss section, and GCC doesn't like that I'm trying to get the address of a symbol from there in non TLS code
14:21:29 <doug16k> in the case you are fixing, it is using the 2nd technique
14:21:52 <doug16k> the compiler has no way of knowing that you are doing that
14:22:02 <doug16k> ah...
14:22:11 <doug16k> don't put it in tbss... that's a chicken and egg problem
14:22:26 <doug16k> you want to access TLS to setup TLS?
14:22:37 <doug16k> put it as a normal char array in bss or something
14:22:42 <Ryanel> Oh, that makes sense. BSS it is
14:23:04 <doug16k> remember we're just simulating proper TLS... well enough to get past this issue
14:23:27 <doug16k> in a real implementation, you'd do things in your linker script and run some code at runtime to init a separate TLS block per thread
14:24:00 <doug16k> and each thread would have the gs base setup to its own copy of that block
14:24:50 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
14:24:55 <doug16k> if your code took the address of TLS, it would read the base from gs:0 to get the ds relative pointer to it, then it would calculate the address of that thread's copy of that variable relative to that
14:25:05 <doug16k> address of a variable in TLS*
14:26:15 <doug16k> hopefully there aren't initialized TLS variables. most TLS code uses uninitialized (zero initialized) TLS variables so faking it for now will probably work
14:27:06 <doug16k> let me see if I can dig through my repo history and show what I did for TLS early on (before I took it out)
14:29:11 <Ryanel> That would be helpful, thank you
14:30:46 <doug16k> I think this is the latest commit that still had it: https://github.com/doug65536/dgos/blob/f11e1c2ed0711464eaf5c46d90bd61007ba12953/kernel/arch/x86_64/kernel.ld#L199
14:30:48 <bslsk05> ​github.com: dgos/kernel.ld at f11e1c2ed0711464eaf5c46d90bd61007ba12953 · doug65536/dgos · GitHub
14:31:20 --- join: Nouv (~user@unaffiliated/nouv) joined #osdev
14:31:56 <doug16k> https://github.com/doug65536/dgos/blob/f11e1c2ed0711464eaf5c46d90bd61007ba12953/kernel/lib/tls.c
14:31:57 <bslsk05> ​github.com: dgos/tls.c at f11e1c2ed0711464eaf5c46d90bd61007ba12953 · doug65536/dgos · GitHub
14:32:26 --- quit: MarchHare (Ping timeout: 256 seconds)
14:32:39 <doug16k> https://github.com/doug65536/dgos/blob/f11e1c2ed0711464eaf5c46d90bd61007ba12953/kernel/arch/x86_64/kernel.ld#L61
14:32:41 <bslsk05> ​github.com: dgos/kernel.ld at f11e1c2ed0711464eaf5c46d90bd61007ba12953 · doug65536/dgos · GitHub
14:32:46 <doug16k> sorry for link spam
14:33:27 --- join: MDude (~MDude@c-73-187-225-46.hsd1.pa.comcast.net) joined #osdev
14:36:20 <doug16k> ^ that's how to do it formally. earlier I explained half-assed hack that might be good enough :)
14:36:51 --- quit: zesterer (Ping timeout: 256 seconds)
14:38:03 <Ryanel> Alright, it seems good. I'm gonna keep working on the hack, and then when I'm up for it, I'll do it properly. My kernel's really early in development, so I don't really have the infrastructure for threads yet.
14:38:13 <doug16k> I reverted that because I now use gs for cpu-local storage to implement SMP efficiently
14:39:53 <doug16k> and because it was more trouble than it was worth to try to have compiler-provided TLS in my kernel
14:40:33 <Ryanel> I see.
14:40:42 <doug16k> for the couple of places where I need something like that, I added it to the thread context and provided a way to get it by indirecting current_thread->thread_info->tls_thing
14:42:02 <doug16k> it worked though. it was fun to prove that I could shoehorn it in :)
14:43:05 --- quit: kimundi (Ping timeout: 268 seconds)
14:49:45 <Ryanel> Shoot... it didn't work
14:50:44 <doug16k> what does info registers say (in qemu monitor) at the point of the crash?
14:50:55 <doug16k> what is gs's base?
14:51:00 --- quit: spare (Quit: leaving)
14:51:27 --- quit: sortie (Quit: Leaving)
14:52:11 <doug16k> before the crash, of course. reset clobbers everything
14:52:55 <Ryanel> .... it's 0030 00000000 ffffffff 00cff3000 DPL=3 DS [-WA]
14:53:15 <Ryanel> Assuming it's base first, i have no idea why it's 0
14:53:16 <doug16k> you either didn't set the base of the descriptor or you didn't set it before loading gs
14:53:39 <doug16k> what does GDTR say in that monitor output?
14:54:15 <doug16k> er, GDT=
14:54:36 <Ryanel> c0106020
14:55:06 --- quit: immibis (Ping timeout: 260 seconds)
14:55:09 <doug16k> ok, what does x /2wx 0xc0106050 say?
14:55:21 <doug16k> ^ qemu monitor command
14:55:47 <Ryanel> c0106050: 0x0730ffff 0xc0cff311
14:58:05 <doug16k> you expect base to be 0xc0110730 right?
14:58:09 --- join: Oxyd76 (~quassel@5.18.99.0) joined #osdev
14:58:43 <Ryanel> Yes
14:59:03 <doug16k> then you must have loaded gs before you setup that descriptor
14:59:21 <Ryanel> Not possible. The GDT is compile time.
14:59:21 <doug16k> you have to load gs after you set that up. the cpu only accesses the gdt while loading a segment register
14:59:53 --- quit: bork (Ping timeout: 256 seconds)
15:00:28 <Ryanel> The GDT is defined with macros, using the symbol address of tls_middle as the base. Then the gdt pointer is constructed on the stack, which then is loaded by lgdt.
15:00:37 <Ryanel> Then I set the segment registers
15:01:50 <Ryanel> memset the tls_bottom -> tls_top space, set [tls_middle] to tls_middle, then go on booting
15:03:28 <bcos_> Try using the MSRs (and "swapgs") to set GS base..
15:03:35 <doug16k> you intended DPL=3? this will be accessed in user mode?
15:03:40 --- join: bork (ayy@cpe-76-173-133-37.hawaii.res.rr.com) joined #osdev
15:03:40 <doug16k> bcos_, it's 32 bit
15:03:45 <bcos_> D'oh
15:05:05 <Ryanel> Nope, shouldn't be DPL=3. Trying that now
15:05:22 <doug16k> should be DPL=0
15:05:53 <doug16k> but based on your x output above, 0xf3 means "present, DPL=3"
15:06:05 <doug16k> ...writable, accessed
15:06:41 <Ryanel> Switching to DPL=0 did nothing.
15:06:42 <doug16k> that 0xf3 should be 0x93 unless I'm mistaken
15:07:20 <bcos_> "base = 0, limit = 4 GiB, DPL=3, writable" is exactly what you'd expect for a user-space DS/ES/SS descriptor..
15:07:42 <doug16k> is it usermode though? Ryanel doesn't even have IDT set up yet
15:08:09 <doug16k> bcos_, he's trying to use stack protector and it is generating a TLS access
15:08:15 <bcos_> I'm just wondering if it's supposed to be "gs = 0x38" and not "gs = 0x30"
15:08:16 <Ryanel> It's not usermode, this is early in the kernel, like, just after getting into C++, and encountering the stack smash protector.
15:08:56 <Ryanel> It's DPL=0 now, and it's still showing up as the base being 0x0
15:09:21 <doug16k> Ryanel, single cpu so far, right? no SMP right?
15:09:22 <Ryanel> No, it should be. There's 6 segments, null, kernel code, kernel data, user code, user data, F, and G.
15:09:29 <Ryanel> doug16k: Correct.
15:09:48 <geist> _mjg_: hmm, i'm starting to think why it was so fast. just reran the syscall benchmarks on zircon and it's coming out to be something like 42ns on this machine
15:10:02 <geist> same machine (xeon haswell) reads 59ns on linux
15:10:08 <bcos_> What does the macro that creates GDT entries look like? It's almost impossible to use a macro for this because "base" is split into 3 different pieces and the linker can't support it
15:10:22 <doug16k> ^
15:10:31 <geist> note thats the 'null' syscall on zircon, that just goes through the layer and then turns around, but it doesn't short circuit anything
15:11:02 <Ryanel> While I was debugging this, I actually used sortie's GDT implementation, to get earlier then C++ definition of the GDT
15:11:49 <Ryanel> https://puu.sh/AnuAA/b56c844d12.png screenshot here
15:12:02 <doug16k> bcos_, the GDT entry is correct though. checked GDTR in qemu monitor then x'd the descriptor. has expected base
15:12:09 <_mjg_> geist: well there is a little bit of branchfest for getuid/getppid
15:12:28 <geist> yah, so it's slightly unfair. but it's nice that we're not egregiously blowing things
15:12:47 <_mjg_> side question is if you have slowdowns re meltdown & friends
15:12:59 <_mjg_> at least stemming from supporting the mitigation to begin with
15:13:02 <geist> no, not yet
15:13:04 <_mjg_> not necessarily it being enabled
15:13:12 <_mjg_> ye, so you should probably bench against a pre-meltdown kernel
15:13:22 <geist> but i have pti disabled on this machine as well
15:13:29 <_mjg_> but it still looks like roughly the same ballpark
15:13:33 <geist> yah
15:13:52 --- quit: Tazmain (Quit: Leaving)
15:13:55 <geist> which since the machine liks 3.9ghz when turboed up, means just south of 200cycles or so
15:14:00 <_mjg_> my argument was that the fact that the kernel supports the mitigation probably pessimized the path
15:14:07 <_mjg_> regardless of whether it is enabled
15:14:10 * geist nods
15:14:24 <_mjg_> it probably can be fixed with hotpatching at boot time
15:14:31 <_mjg_> but also probably not worth it
15:14:46 <doug16k> geist, I don't think it is that hard to beat linux
15:14:47 <geist> as an AMD owner i take exception to that :)
15:14:53 <_mjg_> :)
15:15:09 <_mjg_> doug16k: yes and no
15:15:17 <_mjg_> linux has selectively super optimized stuff
15:15:19 <geist> what i was really playing with was nested hypervisor, which i had historically assumed was crazy slow, but right now i'm not seeing that much of a slowdown
15:15:23 <doug16k> try linux in bochs. it's ridiculously bad
15:15:39 <geist> well, of course. so is everything else
15:15:49 <doug16k> I can't even boot without 20 things erroring/timing-out during boot
15:16:31 <bcos_> geist: I suspect that (at least for frequently used kernel API functions) using "old school call gate per function" probably works out faster than "syscall plus stack fixing plus switch(function_number)"
15:16:33 <bcos_> ;-)
15:16:38 <doug16k> ya but linux server distro should be able to boot on a few hundred MHz processor without catastrophe
15:17:03 <geist> bcos_: right,when running a per-instruction emulator you almost always win by using less instructions to do the same thing
15:17:08 <geist> which may not reflect reality at all
15:17:26 <doug16k> I'm not saying linux is bad - I'm saying linux is trying to be so everything to everyone that it can't be absolutely as fast as possible
15:17:34 <Ryanel> doug16k: From what I can gather, it's almost like the cpu ""forgot"" the base. Which is really weird. I'm setting the GDT first thing after I set the page directories, before I call kStart. I don't know what it could be.
15:17:35 <geist> so yeah, use crazy ass call gates or TSS task switching there
15:17:49 <bcos_> geist: Erm. The reality is that "switch(function_number)" is an upredictable disaster on real hardware
15:18:01 <bcos_> ..so removing that from the critical path..
15:18:12 <geist> yeah have fun with that
15:18:29 <geist> sometimes you gotta crack some eggs
15:19:56 <doug16k> geist, you spam the same syscall in an loop right? should be 100% predictable in the synthetic bench
15:20:00 <geist> jumping through a gigantic hoop like using multiple syscall int vectors to avoid a switch statement is pretty silly
15:20:10 <geist> doug16k: yep, but so is the benchmark that i'm comparing against
15:20:42 <Nouv> test
15:20:53 <doug16k> Nouv, ack
15:20:55 <geist> this was part of a weekend benchmarking fest and _mjg_ and i were doing, comparing essentially null syscalls against pti/no pti, *bsd, etc
15:21:17 <geist> i assumed zircon would get owned since we haven't really optimized that path, but turns out it's not so bad
15:21:29 <doug16k> ah
15:21:33 --- join: aalm (~aalm@37-219-237-30.nat.bb.dnainternet.fi) joined #osdev
15:22:06 <_mjg_> the only other surprise was that netbsd was not terrible
15:22:08 <_mjg_> 8)
15:22:27 <_mjg_> which makes me even more curious about openbsd and illumos
15:22:29 <geist> _mjg_: also i did manage to install openindiana on this atom machine last night, but its got some problems that i need to sort out
15:22:34 <doug16k> Ryanel, try stepping the code that loads gs and see if qemu monitor shows the expected base at that point
15:22:47 <_mjg_> geist: cool
15:22:54 <geist> anyway, will let yield the floor back to the existing osdev
15:23:37 <_mjg_> i can't get over weird ass pessimizations in fbsd case
15:23:53 <_mjg_> there is support for syscall registration at runtime
15:24:10 <_mjg_> it adds wtf branches even for static syscalls (read: almost all of them)
15:24:34 <_mjg_> and when a dynamic syscall is used, it is being refcounted with an atomic on syscall entry/exit
15:24:38 <_mjg_> :[
15:24:44 <_mjg_> reads like a student project
15:27:12 <Ryanel> doug16k: I can see GS change but not the base.
15:28:02 --- nick: EricB -> BronzeBeard
15:28:35 --- quit: ecraven (Ping timeout: 276 seconds)
15:28:40 --- nick: BronzeBeard -> EricB
15:28:48 --- quit: dennis95 (Quit: Leaving)
15:28:49 <doug16k> Ryanel, what does x /2wx 0xc0106050 say now?
15:28:54 <Ryanel> doug16k: https://puu.sh/Anv5C/f38d2a182e.png this is the boot code, for reference.
15:28:57 <Ryanel> 1 sec
15:29:42 <Ryanel> c0106050: 0x0000ffff 0x00cf9300
15:30:10 --- join: ecraven (~ecraven@www.nexoid.at) joined #osdev
15:30:44 <doug16k> that and gdt_init look right
15:31:02 <doug16k> the instruction that accesses gs:0 is still the one that faults?
15:31:41 <Ryanel> Yup
15:33:20 <Ryanel> at that point, c0106050: 0x0730ffff 0xc0cf9311
15:33:36 <doug16k> in my (64 bit) kernel, I see gs base in info register output -> GS =004b ffffffff800c9980 ffffffff 00cff300 ...
15:33:48 <doug16k> I don't see why 32 bit kernel wouldn't show the base too
15:35:31 <doug16k> er, 32 bit guest
15:35:34 --- quit: BartAdv (Quit: Connection closed for inactivity)
15:36:26 <doug16k> Ryanel, ah wait, that x output looks wrong
15:36:59 <doug16k> what is GDT= in monitor now? (it may have moved since last check)
15:37:27 <doug16k> oh nevermind, you showed good output after
15:38:23 <doug16k> assuming 0xc0110730 is the value of tls_bss_middle
15:38:40 <Ryanel> Yup!
15:40:45 <doug16k> which qemu are you using? qemu-system-x86_64, or qemu-system-i386, or something else
15:40:46 <Ryanel> For me, the question is "Why is this not showing up in the monitor window", because, if I had the GDT setup correctly, which i'm pretty sure I do, and I'm loading it correctly, which I assume I am, then it should show in the monitor window correctly, and be loaded correclty
15:40:52 <Ryanel> qemu-system-i386
15:41:29 <geist> are you using kvm?
15:41:55 <Ryanel> How would I check? I'd assume no, since I'm doing this through a virtual machine.
15:41:57 --- join: quul (~weechat@unaffiliated/icetooth) joined #osdev
15:42:09 <doug16k> Ryanel, do you have -enable-kvm in the qemu command line?
15:42:10 <geist> if you're not explicitly enabling it you probably aren't
15:42:19 <Ryanel> doug16k: no
15:42:24 <geist> my experience is the cpu introspection stuff gets a bit wonky when using kvm
15:43:01 <Ryanel> info kvm reports kvm is disabled
15:43:02 <doug16k> yeah, it does. qemu doesn't reliably get the context at every point where it should, for performance
15:43:33 <doug16k> does get wonky*
15:44:33 <doug16k> at least that is what I was told/warned in #qemu when I submitted info registers patch :)
15:45:23 <geist> otherwise when using tcg i've had okay results. the only difference there is it's not emulating it one instruction at a time
15:45:34 <geist> and it always ends up stopped at a break in a run of instructions
15:45:42 <geist> branch, hlt, pause, etc
15:45:57 <doug16k> yeah, should be fine in TCG
15:46:08 <Ryanel> But no, I'm not using kvm. I'm single stepping using si in gdb attached to qemu, and using info registers in the monitor window
15:46:38 <geist> i dont have the full context here, but that *should* work
15:46:41 <geist> i dont see why it wouldn't
15:47:06 --- quit: xenos1984 (Quit: Leaving.)
15:47:17 <Ryanel> Would uploading the code to a branch on github help?
15:48:07 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:49:10 <geist> by itself no. if you could then convince someone to look at it they may be able to help
15:49:47 --- quit: Drakonis[m] (Changing host)
15:49:47 --- join: Drakonis[m] (drakonisma@unaffiliated/drakonis) joined #osdev
15:49:47 --- quit: Drakonis[m] (Changing host)
15:49:47 --- join: Drakonis[m] (drakonisma@gateway/shell/matrix.org/x-ruzktfrrnrawfdww) joined #osdev
15:50:33 <doug16k> Ryanel, I'd look
15:50:51 <doug16k> it doesn't hurt to meteor-proof the code anyway
15:50:57 <Ryanel> doug16k: https://github.com/Ryanel/Akiros/tree/tls-broken/src/kernel/x86/i686
15:50:59 <bslsk05> ​github.com: Akiros/src/kernel/x86/i686 at tls-broken · Ryanel/Akiros · GitHub
15:51:23 <Ryanel> boot.asm is where I'm doing the loading, while src/kernel/x86/gdt.cpp is where I setup the GDT
15:51:53 --- quit: Shamar (Quit: Lost terminal)
15:52:04 <Ryanel> essentially, it's just a modified higher-half-kernel
15:52:04 --- join: drakonis (~drakonis@2804:18:83f:62fe:f1df:a161:79a3:955a) joined #osdev
15:52:50 --- quit: drakonis (Changing host)
15:52:50 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
15:55:49 <doug16k> Ryanel, where does it call gdt_init? github search isn't finding it
15:56:35 --- quit: drakonis (Client Quit)
15:56:44 <Ryanel> gdt_init is in boot.asm . It isn't called, it's merely a label inside of the _kernelInit function.
15:57:00 <doug16k> ah
16:04:32 <geist> well, wow. looks like the hifive1 board finally shipped
16:08:25 <Ryanel> From what I can gather, that's running a custom architecture?
16:11:12 <geist> it's a risc-v
16:11:37 <Ryanel> neat
16:11:46 --- join: freakazoid0223_ (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
16:11:56 <Ryanel> love open source hardware stuff, it's neat
16:12:06 <doug16k> no ram eh? 16KB scratchpad is not bad though for a microcontroller
16:12:30 --- quit: freakazoid0223 (Ping timeout: 268 seconds)
16:13:26 <doug16k> should blow the doors off an atmel arduino
16:19:12 --- part: raiz left #osdev
16:23:35 <doug16k> Ryanel, looks okay. I'm going to modify a tiny 32 bit kernel I created to repro the issue and see if info registers shows the expected value for gs
16:23:54 <Ryanel> Alright, sounds good.
16:35:16 <geist> doug16k: more importantly it doesn't seem to have onboard flash, which is i suspect mostly a deal breaker
16:35:49 --- quit: JusticeEX (Ping timeout: 240 seconds)
16:37:20 <ALowther> Hello, my favorite IRC community. Good evening :)
16:37:32 <Ryanel> Good evening
16:37:34 <rain1> hi
16:38:34 <geist> hola
16:40:48 --- quit: jordyd (Quit: Bye!)
16:42:58 --- join: jordyd (~jordyd@pampanic/co-maintainer/jordyd) joined #osdev
16:43:11 <doug16k> geist, really? how? does it slow to a stop reading code from SPI flash in code cache miss?
16:43:43 <geist> that's the rub
16:44:00 --- join: hussein (~hussein@slb-97-111.tm.net.my) joined #osdev
16:44:11 <geist> question is can you realistically rn out of SPI, even with a cache in front of it, with any amount of power/performance
16:44:19 --- quit: nur (Read error: Connection reset by peer)
16:44:21 --- quit: quc (Remote host closed the connection)
16:44:27 <geist> especially a core that fast. or is it assumed you're going to run a tiny bit of code in fast sram
16:45:09 <doug16k> hmm. I wonder if it is really code scratchpad, and the bootloader loads the code at boot
16:45:12 <geist> the average little cortex-m claass microcontroller has some sor of 4:1 or 8:1 on board flash to sram, and you basically run all your RO stuff (text/rodata/etc) out of flash in place
16:45:19 <geist> yah
16:45:29 <geist> well, i suppose i can dig up the docs, now that it's shipped i may as well find out
16:45:38 <geist> otherwise i wasn't going to get too excited until i knew it was coming
16:45:53 --- quit: Nouv (Ping timeout: 265 seconds)
16:45:54 <Ryanel> doug16k: Just checked in bochs, I'm getting the same result (GS=30, index 6), base = 0
16:46:28 <doug16k> Ryanel, in my tiny 386 kernel, loading gs updates info registers output -> GS =0018 001122e0 ffffffff 00cf9300 DPL=0 DS [-WA]
16:46:46 <doug16k> 0x1122e0 is my "mid" symbol value
16:47:16 <Ryanel> huh
16:47:43 --- join: KernelBloomer (~SASLExter@gateway/tor-sasl/kernelbloomer) joined #osdev
16:49:50 <doug16k> Ryanel, info registers shows the correct base for me
16:51:00 <doug16k> Ryanel, ah nice, bochs. run this command: info gdt
16:51:03 <doug16k> (I think)
16:52:05 <doug16k> also: sreg
16:52:11 <Ryanel> I haven't been able to get the bochs debugger working
16:52:46 <doug16k> working? what happens?
16:52:56 <doug16k> are you using command line bochs or some gui thing?
16:53:34 <doug16k> (I have contributed major patches to bochs debugger)
16:54:19 <Ryanel> bochs-debugger, installed from dnf on fedora
16:54:26 <Ryanel> dlopen failed for module 'iodebug'
16:54:53 <doug16k> oh, those damn modules, and crappy build bochs uses
16:56:19 <doug16k> the bochs debugger is 99% of the reason to use bochs. it's excellent when your kernel dies catastrophically
16:56:24 --- quit: AndrewBC_ (Read error: Connection reset by peer)
16:57:39 <doug16k> it doesn't get a stupid look on its face and fall flat on its face like qemu does :D
16:57:44 <doug16k> it tells you why it blew up
16:58:32 <geist> oh now come on
16:59:07 <doug16k> qemu tells you practically nothing about why it triple faulted, other than using that -d int flood
16:59:57 <doug16k> but qemu debugging kicks bochs' ass once you have a stable kernel and want to source level debug using gdbstub
17:00:04 <doug16k> so it depends on the scenario
17:01:03 <Ryanel> -sigh- and of course when I want to compile Bochs from source there's errors
17:01:51 <doug16k> Ryanel, try my fork: https://github.com/doug65536/bochs.git
17:02:12 <doug16k> git checkout fix_64bit_symbols after cloning
17:02:13 <geist> i have to say i do sort of wish qemu had some sort of crash loop detect on arm
17:02:35 <geist> the other day i ended up debugging something that resulted in for about a week, unknown to me, the kernel was occasionally failing to start one or more of the secondary cores
17:02:52 <geist> and they were just stuck in what onx 86 would have resulted in a triple fault, but on arm just puts them in a hard exception loop
17:03:08 <geist> and qemu faithfully does what a real arm would do: just sit there and branch to itself forever
17:03:22 <KernelBloomer> lol
17:04:10 <geist> triple fault is a nightmare on x86, and most risc machines are carefully designed to just never be able to be put in an invalid state like x86 does
17:04:23 <geist> but.... sometimes it's nice to have a definitive oops-im-screwed state
17:05:13 --- join: bemeurer (~bemeurer@185.236.200.248) joined #osdev
17:05:24 <jjuran> See also the Weird Machines talk by Dr. Sergey Bratus
17:05:32 <doug16k> Ryanel, this is the configure command line I use: https://gist.githubusercontent.com/doug65536/69519d3d5f12a3d02dd004a1cfe15e3f/raw/e1dc767e0df98b1f30631debeeddab6274f9753d/gistfile1.txt
17:07:07 <klange> geist: I have that report you wanted :)
17:07:13 <doug16k> geist, I think double fault was designed by an idiot, but triple fault is not bad. better to reset than hang
17:07:23 <Ryanel> getting yacc errors now :(
17:07:35 <Mutabah> doug16k: Why do you say that about DF?
17:07:37 <geist> klange: so what's the verdict
17:07:44 <doug16k> Mutabah, doesn't push return address to stack
17:08:13 <doug16k> #DF context is 99.99999% useless
17:08:14 <Ryanel> doug16k: 'implicit declaration of function 'yylex'; did you mean 'bxlex'?
17:08:42 <klange> tl;dr: memcpy_fromio on a region that was not memory-like; inlined and optimized version wasn't writing data from the mmio area into the temporary array in the right order, and was seeing other incorrect results due to larger reads being handled incorrectly, vs. the non-inlined version being a more straightforward `rep mov...`.
17:09:12 <jjuran> If double fault context is useless, than maybe there shouldn't be triple fault at all. Let double fault be the end.
17:09:16 <jjuran> *then
17:09:30 <geist> klange: oh yes. never ever memcpy to mmio, ever
17:09:30 <klange> The memory region, regardless of which byte you read from it, always returns the next sequential byte from the chip's receive buffer. Replaced the memcpy_fromio with a loop over ioread8.
17:09:49 --- quit: geordi (Ping timeout: 240 seconds)
17:09:49 <klange> I suspect the authors didn't read the docs.
17:09:55 <geist> that's downright fatal on something like ARM where the access of uncached memory like that is much more strict
17:09:59 <klange> And they only got lucky up until gcc 6.x :)
17:10:03 <geist> of course it being fatal is nicer than returning garbage
17:10:05 <doug16k> jjuran, well, if you _really_ want to recover you can kill the kernel thread in #DF, but that's about all you can do
17:10:24 <geist> well, cool
17:11:26 --- quit: KernelBloomer (Ping timeout: 255 seconds)
17:11:36 --- join: geordi (~geordi@ns510081.ip-192-99-4.net) joined #osdev
17:12:37 <geist> yah we went ahead and put in a IST per core to redirect the double fault handler to its own stack so we can dump a panic
17:12:40 <geist> but..that's about it
17:12:54 <Mutabah> I think that's the idea?
17:13:11 <geist> that's probably the only real reason the IST exists. maybe for NMI as well
17:13:18 <doug16k> Mutabah, sure, but you have no clue where it double faulted, so good luck troubleshooting
17:13:20 <geist> it was the replacement for the task gate that you used to do for 32bit
17:16:56 --- quit: X-Scale (Ping timeout: 264 seconds)
17:17:28 --- quit: z0ttel (Ping timeout: 256 seconds)
17:17:34 --- join: z0ttel (~z0ttel@reuenthal.z0ttel.com) joined #osdev
17:18:30 <doug16k> #DF could have easily worked like a page fault, where if you return without fixing the problem, it just double faults again. then you could actually have an actionable context dump if you get a bad stack pointer or stack guard page fault in kernel mode
17:18:36 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
17:20:40 <geist> i suspect it's most likely a microarchitectural issue with the original 8086 (or wherever #DF showed up)
17:21:01 <geist> where there wasn't some place for internal state to be saved across all situations
17:21:22 <geist> or it's at the wrong stage of the pipeline or whatnot when it detects it to dumb the state
17:21:38 <geist> like the original 68k cant-recover-memory-fault problem that required the 010 spin
17:22:37 <Ryanel> doug16k: Progress! When not using the symbol name in the gdt definition, the base is set.
17:23:17 <_mjg_> geist: do you have sortix or some other non-hello world toy os?
17:23:28 <_mjg_> geist: for the same test
17:25:22 --- join: X-Scale (~ARM@83.223.227.231) joined #osdev
17:25:39 <doug16k> Ryanel, I wonder if you are missing input section(s) in your linker script and something is discarded
17:26:23 <Ryanel> can you link me the linker script used in your repro project?
17:27:04 <doug16k> Ryanel, sure, but this project is 100% asm: https://github.com/doug65536/qemu-bmibug/blob/master/kernel.ld
17:27:05 <bslsk05> ​github.com: qemu-bmibug/kernel.ld at master · doug65536/qemu-bmibug · GitHub
17:28:05 <doug16k> Ryanel, you can be sure by adding "--orphan-handling warn" to your link options (or -Wl,--orphan-handling,warn to gcc link command line)
17:28:35 <doug16k> it will yell about discarded sections with that
17:29:55 <doug16k> you might be missing something like *(.bss) or *(.bss*) or *(COMMON) in your .bss output section
17:30:02 --- quit: variable (Quit: /dev/null is full)
17:33:17 <Ryanel> Nope, not missing either of those. It's just yelling about a bunch of debug_*, .stab sections, and some stuff from init and fini
17:33:41 <doug16k> stuff from init and fini is bad
17:34:14 <doug16k> it probably means some global initializations won't occur
17:34:57 <Ryanel> Sections are being placed, they're not being discarded
17:37:11 --- join: vaibhav (~vnagare@125.16.97.116) joined #osdev
17:39:14 --- join: sh3iny (~sh3iny@2601:141:201:4328:a53e:395c:5567:4a2e) joined #osdev
17:40:41 <lachlan_s> Anyone know if there are performance numbers on the cost of a context switch in linux?
17:41:58 <Ryanel> doug16k: tls_bss_middle is able to be printed by my kernel in logging functions... but when used to initialise the GDT it acts like it's 0. But it's a symbol, so it's value shouldn't change.
17:42:56 --- join: Naergon (~Naergon@unaffiliated/naergon) joined #osdev
17:43:32 <Ryanel> And boot.o is compiled before gdt.o, so the symbol "should" be defined at that point, as the compile order is the same as the link order.
17:48:27 <doug16k> Ryanel, the order doesn't matter for the list of .o files. order only becomes an issue when linking against archive (.a) files
17:49:34 <Ryanel> huh, neat. Then I don't see the issue where it's defined global in a .asm file, but the symbol's address isn't being read properly in a .cpp file
17:49:49 <Ryanel> even when the symbol's prototype is extern "C"'d
17:50:10 <doug16k> an archive is essentially a bunch of .o files in one file. the linker only grabs the ones it thinks it needs at the point that it scans the .a file
17:50:30 <Ryanel> well, there's no archives here. it's only .o files
17:51:35 --- join: Pseudonym73 (~Pseudonym@e-nat-unimelb-128-250-0-57.uniaccess.unimelb.edu.au) joined #osdev
17:59:35 --- quit: ohnx (K-Lined)
18:04:07 --- join: ohnx (notohnx@unaffiliated/ohnx) joined #osdev
18:07:01 --- quit: X-Scale (Ping timeout: 260 seconds)
18:13:15 --- join: MaryJaneInChain (~user@223.255.127.32) joined #osdev
18:17:17 --- join: Shikadi (~Shikadi@cpe-98-10-34-205.rochester.res.rr.com) joined #osdev
18:19:30 --- join: X-Scale (~ARM@83.223.227.47) joined #osdev
18:20:35 <Ryanel> doug16k: The symbol for some reason at compile time __was__ 0x0. A small stub function fixed it. Kernel is booting fine now. Thank you for the help, I wouldn't have been able to figure this out otherwise
18:22:34 <doug16k> nice
18:23:31 --- quit: Tobba (Ping timeout: 265 seconds)
18:25:28 --- quit: sh3iny (Ping timeout: 256 seconds)
18:27:16 --- join: MarchHare (~Starwulf@mo-184-5-205-69.dhcp.embarqhsd.net) joined #osdev
18:31:23 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
18:38:23 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:42:43 --- quit: Tobba (Ping timeout: 264 seconds)
18:44:12 --- join: oaken-so1rce (~oaken-sou@p5DDB4D14.dip0.t-ipconnect.de) joined #osdev
18:47:41 --- quit: oaken-source (Ping timeout: 256 seconds)
18:52:07 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
18:56:36 --- quit: bemeurer (Ping timeout: 260 seconds)
18:58:37 --- join: bemeurer (~bemeurer@2600:8802:5300:bb90:863a:4bff:fe06:c8b2) joined #osdev
19:01:59 --- quit: Shikadi (Ping timeout: 248 seconds)
19:07:31 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
19:12:17 --- quit: pounce (Quit: WeeChat 2.1)
19:18:13 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
19:29:15 --- quit: tomaw (Ping timeout: 619 seconds)
19:30:47 --- quit: freakazoid0223_ (Ping timeout: 248 seconds)
19:31:44 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
19:33:40 --- join: tomaw (tom@freenode/staff/tomaw) joined #osdev
19:34:31 --- quit: JusticeEX (Ping timeout: 260 seconds)
19:38:26 --- quit: tacco| ()
19:41:45 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
19:50:57 --- quit: lachlan_s (Quit: Connection closed for inactivity)
19:51:51 --- quit: quul (Quit: WeeChat 2.0.1)
19:52:44 --- quit: elevated (Quit: bye)
20:08:56 --- quit: nj0rd (Ping timeout: 260 seconds)
20:21:00 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
20:21:41 --- join: oldtopman (~oldtopman@unaffiliated/oldtopman) joined #osdev
20:23:30 --- join: nj0rd (~nj0rd@mue-88-130-48-049.dsl.tropolys.de) joined #osdev
20:26:34 --- quit: zeus1 (Ping timeout: 268 seconds)
20:33:44 <Belxjander> dpoug16k: I wonder if Ryanei was walking into the C/C++ vs Asm compiler trick of stripping "NULL" defined symbols when they are in-effect "unused" ... as part of the optimization stage... where anything defined in Asm (inline or assembled) entirely skips the optimization pass and is generated into an object regardless
20:35:23 <Belxjander> doug16k: the difference being the Assembled .o includes an address reference where the C/C++ compiler will not actually provide a reference at all (effectively just providing 0L as the address and stripping any offset reference entirely)
20:46:32 --- quit: drakonis (Read error: Connection reset by peer)
21:02:42 <Ryanel> Belxjander: It seems to work fine when used in runtime code, not compile time.
21:07:50 --- quit: Gynvael (Read error: Connection reset by peer)
21:08:07 --- join: Gynvael (~gynvael@80-219-208-230.dclient.hispeed.ch) joined #osdev
21:08:53 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:12:18 <geist> btw, laurel
21:18:12 <klange> because we're old and have lost reception of higher pitches
21:18:25 --- join: dbittman_ (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
21:18:44 <klange> https://www.nytimes.com/interactive/2018/05/16/upshot/audio-clip-yanny-laurel-debate.html
21:18:44 <bslsk05> ​www.nytimes.com: We Made a Tool So You Can Hear Both Yanny and Laurel - The New York Times
21:21:56 <geist> the funny thign is i haven't. i have recently tested and can still hear up to about 16k or so
21:22:07 <geist> and traditionally i was able to hear really high pitches
21:23:07 <geist> though i suppose being able to notice very high pitches and being able to actually discern them are two different things
21:25:17 <geist> but yeah
21:27:25 <doug16k> it stays laurel until 2 ticks from the end. is that good or bad?
21:27:44 <geist> oh no... oh god no
21:27:49 <geist> really? oh uh... wow.
21:28:18 <doug16k> not 2 pixels. 2 marks
21:28:38 * geist shuffles uncomfortably, unsure how to say it
21:28:50 <doug16k> bad?
21:31:53 <doug16k> that would mean I can still hear laurel until almost all of the low frequencies are eliminated. that should be good
21:32:17 <doug16k> most people get the majority of their sound perception from low frequencies
21:34:45 <doug16k> ah I see, I'm perceiving mostly the low frequencies, since laurel is prominent in low frequencies
21:35:19 <doug16k> geist, where is your transition point on the slider?
21:36:30 --- nick: oaken-so1rce -> oaken-source
21:37:15 <klange> doug16k: sorry mate, that means you're a lizard
21:41:54 <aalm> xD
21:43:05 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:43:51 <bcos_> Scientific research would probably indicate that people in the 15 to 25 age group are more likely to own larger subwoofers and turn the bass up on their sound system.
21:44:05 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
21:44:05 <doug16k> about 5 years ago I could hear all the way up to 20kHz. now I can hear up to about 10kHz
21:44:17 <doug16k> maybe 8 years ago actually
21:44:35 <klange> An ability to hear frequencies is only slightly linked to total frequency response.
21:44:52 * bcos_ hasn't been tested for years, but I'd suspect a notch at whatever frequency my workstations annoying fans cause..
21:45:02 --- quit: unixpickle (Client Quit)
21:45:34 <klange> While you may still be able to hear the higher pitches, you likely still have a lower response from them, changing the overall shape of sounds you hear, including, for instance, being more likely to hear Laurel over Yannie.
21:50:14 <pikhq> Hmm. Until 1 mark from the left I primarily hear "Yanny", but for most of the range between there and the center I can tell that both are being said.
21:51:41 --- quit: Ryanel (Quit: Leaving)
21:51:53 <pikhq> *shrug*
21:53:07 <geist> klange: yeah that's probably right
21:53:18 --- quit: rafaeldelucena (Ping timeout: 256 seconds)
21:53:21 <geist> doug16k: it only transitions to yanny to me within the last tick on the slider
21:53:33 <geist> however, it's fairly clear that if you slowly drag it to the right it takes longer to transition
21:54:00 <geist> than if you just randomly pick a spot. there's a bit of pre-conditioning of what you expect
22:07:46 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
22:13:41 --- join: Arcaelyx (~Arcaelyx@2604:2000:f14a:2500:f43c:9c9:7c61:b066) joined #osdev
22:22:34 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
22:24:15 --- quit: unixpickle (Client Quit)
22:26:27 --- quit: dbittman_ (Ping timeout: 276 seconds)
22:33:12 --- quit: freakazoid0223 (Quit: It's a dud! It's a dud! It's a du...)
22:38:17 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-uqepkrdyckgvhsrk) joined #osdev
22:40:03 --- quit: xenos1984 (Quit: Leaving.)
22:41:42 --- quit: CheckDavid (Max SendQ exceeded)
22:41:56 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-lnlxlafqxtgedxyl) joined #osdev
22:45:52 --- quit: oldtopman (Quit: *pouf*)
22:48:07 --- quit: awang__ (Ping timeout: 248 seconds)
22:48:11 --- join: eremitah_ (~int@unaffiliated/eremitah) joined #osdev
22:48:49 --- quit: eremitah (Ping timeout: 240 seconds)
22:48:50 --- nick: eremitah_ -> eremitah
22:50:38 --- join: awang_ (~awang@rrcs-24-106-163-46.central.biz.rr.com) joined #osdev
23:19:08 --- quit: andrei-n (Read error: Connection reset by peer)
23:20:43 --- join: andrei-n (~andrei@51.214-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
23:22:06 --- quit: hussein (Quit: Leaving)
23:22:43 --- join: nur (~hussein@slb-97-111.tm.net.my) joined #osdev
23:22:47 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
23:23:22 --- quit: nur (Client Quit)
23:26:38 --- join: nur (~hussein@slb-97-111.tm.net.my) joined #osdev
23:27:56 --- quit: bemeurer (Ping timeout: 256 seconds)
23:29:59 --- join: bemeurer (~bemeurer@185.236.200.248) joined #osdev
23:30:26 --- quit: Kazinsal (Read error: Connection reset by peer)
23:30:55 --- join: Kazinsal (~Kazinsal@unaffiliated/kazinsal) joined #osdev
23:35:55 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
23:39:03 --- quit: Pseudonym73 (Remote host closed the connection)
23:39:40 --- quit: pounce (Quit: WeeChat 2.1)
23:59:59 --- log: ended osdev/18.05.16