<bslsk05>
'The Art of Noise with Max Headroom - Paranoimia (Official Video)' by Art Of Noise (00:03:25)
sdfgsdfg has joined #osdev
<vdamewood>
It's kind of amusing how many Sci-Fi movies, shows, and books take place in the past now.
<vdamewood>
Back to the Future takes place entirely in the past.
<GeDaMo>
There's still Futurama! :P
<geist>
yah and dune has a nice amount of padding in their timeline
<clever>
was going to mention starwars, but it was in the past from the start wasnt it?
<geist>
battlestar galactica too
<vdamewood>
clever: "A long time ago, in a galaxy far, far away"
<clever>
vdamewood: exactly
<vdamewood>
Star Trek now has two different conflicting descriptions of how the 90s went.
<geist>
sigh. damn windows backup
<geist>
the file backup thingy in windows always seems to fall over after a few weeks
<clever>
vdamewood: but dont they have the timetravel to blame? and those are technically 2 timelines that are both canon?
<geist>
you set it up, add the folders you want, etc
<geist>
and then go back a month later and it has run into some unspecified error 5 days ago. no alert, no warning
<geist>
subsequent backups just silently fail until you wipe out the database and start over
<geist>
on like cycle 5 of this now
<vdamewood>
clever: It's never explained like that.
<clever>
geist: sounds like a perfect backup solution, designed to ensure data loss!
<vdamewood>
clever: In TOS the 90s is dominated by the Eugenics Wars. In Voyager, it's like it was in 1996 (when the episode in question aired). Tom Paris (the 20th century nerd) acted as if everything there was to be expected.
* vdamewood
hugs his Time Machine
<vdamewood>
Oh hey, that comment works for both threads.
<clever>
vdamewood: i was thinking about the most recent reboot, wasnt aware of things not matching up between tos and voyager
srjek has joined #osdev
<clever>
ive not seen much of TOS
<vdamewood>
Yeah, in TOS Khan was from the 1990s.
<clever>
in the timeline i remember, wasnt khan created by soon?
pwng has joined #osdev
<geist>
i dont think khan and soong were related
<geist>
though possible they got connected later, i guess. it's the inevitable outcome when a fictional universe is created with a finite number of set pieces
<geist>
eventualyl some writer will try to connect the two
<bslsk05>
'Isekai is Changing' by Manime Matt (00:08:20)
* vdamewood
gives gog a fishy.
* gog
chomps fishy
<clever>
vdamewood: i'm not sure why, but i still have a distinct memory of khan's creator being banned from genetics, and trying to start over at creating the perfect life-form with cybernetics
<zid>
I don't watch youtube videos about anime
<zid>
I'm incredibly not interested in some gen-x'ers hot take :P
<GeDaMo>
clever: that's Arik Soong again
<vdamewood>
clever: That *did* happen with Soong's ancestor in Enterprise.
<GeDaMo>
But he didn't create Singh, he stole some augments and raided them hinself
Burgundy has joined #osdev
<vdamewood>
Arik is the ancestor?
<GeDaMo>
Yeah
<clever>
vdamewood: ah, and i was probably just missing the ancestor bit
<clever>
they have always been bad at putting a specific clear date on episodes
<clever>
so its hard to tell how far apart ENT and TNG are
pieguy128 has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
sdfgsdfg has joined #osdev
mahmutov_ has quit [Ping timeout: 256 seconds]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<vdamewood>
clever: Enterprise is about 100 years before TOS.
<GeDaMo>
And Discovery is about 10 years before TOS
<gog>
to start with
<gog>
:p
<GeDaMo>
Spoilers! :P
<gog>
sorry
<GeDaMo>
It's OK, I've seen it :P
<gog>
i thought so
<GeDaMo>
There's going to be a series where Pike takes over the Enterprise, I can't remember what it's called
<GeDaMo>
Ah, Strange New Worlds
<gog>
i want more lower decks
<GeDaMo>
There's also The Orville
<vdamewood>
I haven't seen Discovery.
wootehfoot has quit [Read error: Connection reset by peer]
<pwng>
Hey all
<gog>
howdy
<pwng>
Can someone tell me what are they using to debug RISC-V inside QEMU? Every version I tried for GDB is problematic in someway...
<bslsk05>
riscv-collab/riscv-gnu-toolchain - GNU toolchain for RISC-V, including GCC (623 forks/1426 stargazers/NOASSERTION)
<pwng>
oh great so that's working for you
<j`ey>
pwng: bslsk05 is a bot
<pwng>
oh thanks:D
<gog>
where's our risc-v experts when we need em
<pwng>
so I'll say what goes wrong for me in case someone can help:
<gog>
i'm just an x86_64 scrub
<pwng>
First, I was using regular `-ggdb` to compile my sources, but printing the value of anything resulted in: "dwarf2_find_location_expression: Corrupted DWARF expression."
<pwng>
I read somewhere that `-gdwarf-2` is the way to go, so I use that now
<pwng>
now the problem is: the execution flow is altered in an unreasonable way. Line numbers are all messed up and I find the "currently executing lines" very irrational (e.g. in functions I never call)
<pwng>
Also, I can't find any symbols to print. When I write `print <tab>` I get the source files as suggestions - but not a single variable or a function name
<pwng>
As a side: Using `riscv64-unknown-elf-gdb` at first resulted in the following error: `error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file`
<vdamewood>
There are RV experts?
<zid>
just build all the latest from source, easiest
<pwng>
I have gcc and binutils built from source but unfortunately they didn't have GDB, and that was before I knew about the repository>:(
<zid>
I meant gdb and qemu
<zid>
they need to speak the same proto
<zid>
gcc and gdb is less relevent, unless your gcc is significantly newer than your gdb
<pwng>
I'm currently using gcc and gdb from the same release so probably they should work together fine
<pwng>
I'll build gdb and give it a try, many thanks
<bslsk05>
riscv-collab/riscv-gnu-toolchain - GNU toolchain for RISC-V, including GCC (623 forks/1426 stargazers/NOASSERTION)
<pwng>
they have gcc and gdb (among everything else) packed together
<zid>
so there are riscv things you want that aren't upstream?
<pwng>
I'm not entirely sure - I can't pin the problem exactly
<zid>
Why use a fork, if you weren't having issues?
<zid>
sounds like you jumped to a fork you don't understand, and are having issues with it
<geist>
interesting
<geist>
i think that particular thign is pretty up to date, it's mostly a prebuilt thing
sdfgsdfg has quit [Quit: ZzzZ]
<pwng>
I never had a functioning GDB so I didn't have something working and jumped to something else
<geist>
what host platform are you on?
<pwng>
Building GCC and Binutils from the main sources and defining risc-v as the target doesn't build GDB as well, so I tried a fairly new gdb-multiarch and also the one from the risc-v-toolchain repo and I can't get them to behave normally for some reason
<pwng>
I'm on x86_64
<pwng>
linux ubuntu
<geist>
hmm, lemme see if my prebuilts has a functional gdb
<geist>
i honestly never use gdb so haven't tested it too much
<geist>
but i always have some prebuilts around
<pwng>
can you please tell me an alternative?
<geist>
alternative to what?
<pwng>
something like printf-debugging probabbly?
<pwng>
you say you never use gdb
<geist>
ah yes.
GeDaMo has quit [Remote host closed the connection]
<bslsk05>
github.com: toolchains/doit at master · travisg/toolchains · GitHub
<geist>
but like i said i dont really use gdb and basically just use printf debugging and/or the integrated qemu state inspection
<geist>
not really trying to boast about it. there are places where source level debugging is great, but i just dont like to rely on high level tools like that if i can help it. i've spent far too much time at various companies and whatnot where that was not available, so you get used to working with what you got
<geist>
and, honestly, you tend to forget that higher level stuff exists
<zid>
I'm too stupid to write gdb commands that persist through restarts
<zid>
so I tend to only use it for simple stuff
<zid>
otherwise I have to spend too long setting the gdb state back up
<geist>
honestly the x86-64 thing where it can't handle mode shifts has turned so many people off to gdb, since it's still a pain after all these years
<geist>
but it does tend to be simpler on other arches that dont have that mode shift
<zid>
Thankfully I don't have to care, all my stuff is looongboi
dennis95 has quit [Quit: Leaving]
ZombieChicken has joined #osdev
elastic_1 has quit [Ping timeout: 240 seconds]
<gog>
i gotta figure out how to automate the section offsets in my .gdbinit
<gog>
pita to have to tell it every time
<pwng>
Unfortunately, the problem persists so probably it's a problem with my setup, so I'll just stick with simpler stuff
<pwng>
many thanks all!
elastic_1 has joined #osdev
<geist>
pwng: sorry about that. also was just thinking, are you sure it's matched the bitness?
<geist>
ie, 32 to 32, 64 to 64?
<geist>
though the two bit modes are basically the same on riscv, there are a few subtle differences
<geist>
no idea if gdb just knows the bitness of the target or not
<geist>
or how its encoded
<gog>
disassembly mode and stepi sort of works agnostic of bitness mode
<gog>
but it'll tell you garbage on the backtrace
<gog>
or say it can't find it
<clever>
yeah, i had gdb giving me all kinds of garbage when i forced qemu into arm BE mode
<clever>
but i later discovered, linux will switch the arm core into BE automatically, and expects you to boot in LE mode
<clever>
(if using a BE linux build)
<zid>
Backtraces are always garbage, your program already crashed, all memory is now suspect :P
<pwng>
geist: I use the GDB command `set architecture riscv:rv64` so I think that's what you mean?
<geist>
yah
<pwng>
It's fine I think I better get used to not having it around as you said
<geist>
might have some luck asking on the #riscv channel as well
<geist>
might have to wait a bit for an answer but they seem fairly knowledgable