<gorgonical>
If I am using gdb to debug linux on qemu, arm64 flavor, how can I get a backtrace?
<gorgonical>
The backtrace when I type "backtrace" gets me only the localmost frame, even if I specify backtrace 2 or whatever
<clever>
gorgonical: that would imply that the debug info for unrolling the stack is missing, does it give names to the functions?
sprock has quit [Ping timeout: 252 seconds]
<zid>
`bt full`
<zid>
is the command for a full backtrace
<gorgonical>
yep. at least the localmost one
<zid>
if it's missing then yea, no dwarf/stackframes
<clever>
dwarf debug symbols or frame pointers are needed then
<gorgonical>
find them and supply using symbols "file"?
<zid>
yea
<gorgonical>
oh obviously I need to recompile with -g then right
trufas has quit [Ping timeout: 245 seconds]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
computerfido has joined #osdev
dude12312414 has joined #osdev
sprock has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
<gorgonical>
After tweaking the config to put more debug information in, the vmlinux file's symbol table no longer corresponds to the kernel image in memory. So that's good
<gorgonical>
Is there some stripping that happens between the vmlinux and when it gets packed into arch/arm64/boot/Image? Before the reconfiguration that file at least told me the function stub names, etc.
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Belxjander has joined #osdev
freakazoid333 has quit [Ping timeout: 272 seconds]
rwb has joined #osdev
computerfido has quit [Quit: Leaving]
nyah has quit [Ping timeout: 276 seconds]
srjek has quit [Ping timeout: 252 seconds]
mctpyt has quit [Ping timeout: 276 seconds]
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
ElectronApps has quit [Ping timeout: 258 seconds]
sortie has joined #osdev
Vercas6 has joined #osdev
Vercas has quit [Ping timeout: 244 seconds]
Vercas6 is now known as Vercas
GeDaMo has joined #osdev
rwb has quit [Ping timeout: 240 seconds]
robert_ has joined #osdev
rwb has joined #osdev
dormito has joined #osdev
kspalaiologos has joined #osdev
anon16 has quit [Ping timeout: 258 seconds]
anon16 has joined #osdev
Arthuria has joined #osdev
mhall has joined #osdev
ElectronApps has joined #osdev
dragestil_ has joined #osdev
isaacwoods has joined #osdev
dennis95 has joined #osdev
<sham1>
Beep
<dzwdz>
how do y'all handle building the toolchain?
<dzwdz>
a shell script which builds everything in one go, a makefile which only builds the tools which aren't on the system already, or something else
<clever>
dzwdz: for me, its fully handled by the nix package manager, i just add more toolchains as needed
<clever>
once the toolchain is added, you can just request it to cross-compile any library to any arch, even baremetal ones
<clever>
baremetal binaries are a little more complex, but the complex you get on any os
<dzwdz>
do you have the repo up somewhere? that sounds interesting
<bslsk05>
github.com: rpi-open-firmware/default.nix at master · librerpi/rpi-open-firmware · GitHub
tenshi has joined #osdev
<clever>
dzwdz: the magic then starts here, this asks nixpkgs to create a complete tree of EVERY package, cross-compiled to vc4, arm-bare, arm7-linux, arm6-linux, aarch64-linux, aarch64-bare, and x86-64-linux!
<clever>
then i can just insert ${arm.chainloader} in the right spot, and it will fetch the arm32-baremetal build of the chainloader
<clever>
dzwdz: https://github.com/NixOS/nixpkgs/pull/72657 is an example of adding a whole new cross target and toolchain, but all of the usual ones already exist, so you likely dont need that
<bslsk05>
github.com: Initial implementation of vc4 cross-compile by cleverca22 · Pull Request #72657 · NixOS/nixpkgs · GitHub
tenshi has quit [Ping timeout: 256 seconds]
tenshi has joined #osdev
tenshi has quit [Read error: Connection reset by peer]
tenshi has joined #osdev
tenshi has quit [Ping timeout: 268 seconds]
nyah has joined #osdev
gog has joined #osdev
ElectronApps has quit [Ping timeout: 256 seconds]
kspalaiologos has quit [Quit: Leaving]
tenshi has joined #osdev
tenshi has quit [Ping timeout: 276 seconds]
arch-angel has joined #osdev
arch-angel has quit [Client Quit]
arch-angel has joined #osdev
arch-angel has quit [Client Quit]
tenshi has joined #osdev
freakazoid343 has joined #osdev
tenshi has quit [Ping timeout: 272 seconds]
fly_ has joined #osdev
<fly_>
hello!
<dzwdz>
\o
<sham1>
EHLO
<fly_>
this is my first time ever using irc!
<zid>
grats
<fly_>
how long have you guys been doing os dev ?
fly_ has quit [Quit: Lost terminal]
tenshi has joined #osdev
nismbu has quit [Ping timeout: 258 seconds]
nismbu has joined #osdev
mahmutov has joined #osdev
Izem has joined #osdev
mctpyt has joined #osdev
<Izem>
Say you made new hardware, what would you choose in order to boot? I know this question may be architecture independent but I am not sure how else to ask this question.
<sham1>
I doubt that I need to worry about that if I made the hardware
<GeDaMo>
You'd need some kind of bootloader in ROM or equivalent
<sham1>
Well okay, that
<sham1>
Although it does depend on if the boot firmware actually needs the device for anything
<GeDaMo>
Sorry, I was assuming some new CPU rather than a peripheral device
<sham1>
In that case you'd want to decide where and how you get your boot reset vectors
<Izem>
yes I am thinking about the bootloader
<sham1>
Do you just hardcode the address your CPU will start to
<sham1>
Oh bootloader
<sham1>
You would possibly load a module that has enough of your drivers and whatever you need that the kernel can then do everything else
<sham1>
Basically the bootloader just needs to set up things enough that the kernel has a comfortable environment
<Izem>
OK
<Izem>
ah sorry for caps
<sham1>
That's hardly caps
<GeDaMo>
If I type Ok rather than OK, my spell checker complains :P
<moon-child>
I eschew spellcheckers, except late in the editing process. Certainly would never consider them on something 'live' like irc
<GeDaMo>
It's just a wiggly red line under words, I can ignore it
Arthuria has quit [Ping timeout: 258 seconds]
<zid>
stage1 rom that can load ELF over serial or something, depends what the hw is
<zid>
if it has a unified gigantic blob rom then something more complicated
dennis95 has quit [Quit: Leaving]
<gorgonical>
Damn compiler has -fno-unwind-tables added to the kernel. No wonder bt full does nothing
<sham1>
Heh
<gorgonical>
To reassure the channel here that I know this is #osdev and not #linux-for-dummies, I'm messing about with getting Linux to run as a secondary VM using ARM64 virtualization. An OS I built is running as dom0
<gorgonical>
I promise its really osdev, lol
<zid>
just add some whitespace to the linux kernel
<zid>
now it's your gpl derived personal project
<gorgonical>
genius. now I finally will get some respect for my quality contributions
Izem has quit [Ping timeout: 258 seconds]
Arthuria has joined #osdev
tenshi has quit [Ping timeout: 245 seconds]
Izem has joined #osdev
<geist>
gorgonical: did they also disable frame pointers? not a real advantage to doing that on arm64 since there are plenty of registers to do FP tracking
<nur>
gorgonical, interesting. Your project up anywhere?
<sham1>
Has anyone here ever used `redo` for a build system instead of `make` for osdev stuff? Or, well, at all?
<zid>
never even heard of it
<geist>
same
<j`ey>
geist: linux's own stacktrace stuff on arm64 uses fp, so no!
<moon-child>
never used it, no. It seems cool, but I'm inclined to consider shake as a more sensible model of a build system
<sham1>
Hm, figured as much. Welp, would be interesting to experiment with
<geist>
in hat case a bit surprised the bt command doesn't revert to stack frame if there's no dwarf
<sham1>
I'm more surprised by the apparent lack of DWARF
<bslsk05>
redo.readthedocs.io: Introduction - redo: a recursive build system
<kingoffrance>
i dunno, i follow djb stuff always, but if i messed with that stuff i wouldnt get any code done
<kingoffrance>
maybe if i ever get to a userland i will see if i like the /service layout etc.
<kingoffrance>
i think there were some distros that tried to go full djb
<kingoffrance>
i guess if i did go, i would go all-out
<kingoffrance>
*go there
<kingoffrance>
so lots of guillotining required lol
nvmd has joined #osdev
Arthuria has quit [Ping timeout: 272 seconds]
<gorgonical>
geist: is there a flag I ought to check for? I have just seen that my version of gdb predates a patch that supports the signed addresses
<gorgonical>
i am also running linux in qemu and attaching gdb to it through that, if that matters for the stacktrace functionality
<gorgonical>
even after explicitly forcing -funwind-frames and -fasynchronous-stack-pointers or whatever bt full fails to show me anything
<gorgonical>
linux is parking itself in a delay loop which is totally undiagnosable without some stacktrace, so who knows
mhall has quit [Quit: Connection closed for inactivity]
<gorgonical>
nur: "built" is taking more credit for it than I deserve, but I have a lot of experience modifying this OS for virtualization so bits and pieces start to look more like my work. I wrote a hypervisor for x86 that supports it
<gorgonical>
the hypervisor I'm working on now is the Hafnium hypervisor, which is somewhat xen-like. We're modifying it to do all sorts of stuff
<gorgonical>
sham1: do you mean wrt to my project? The dwarf sections are in the vmlinux, but gdb fails to match them up to the running kernel in memory. When I do info file (I think that's the command?) it shows the symbol mappings but doesn't map any of the .debug sections
<sham1>
hm, odd
<gorgonical>
I think this might have to do with the objdump to binary to make it bootable. I tried removing the -S flag so it wouldn't strig ip, but it doesn't really seem to help
<gorgonical>
strip it*
GeDaMo has quit [Quit: Leaving.]
<j`ey>
why wasnt it bootable before?
<j`ey>
or you mean the boot/Image file?
<gorgonical>
yes
<gorgonical>
the vmlinux -> boot/Image process
Arthuria has joined #osdev
<gorgonical>
Sorry if I'm saying dumb things. Til now most of my OS debugging has been via print statements, so I'm still learning how to really use gdb for fancy debugging
<gorgonical>
Just don't know how a lot of this interconnects yet
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531!~user@user/arthuria))]
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
Arthuria has joined #osdev
<gorgonical>
Finally! I have a backtrace! Also thanks again geist for that excellent cross-toolchain script
<j`ey>
hm?
<j`ey>
wrong gdb?
<gorgonical>
Maybe. Using a newer GDB seems to have solved enough problems to give me a backtrace
<geist>
ah yeah that's generally a good idea
<gorgonical>
I was using 8.4 from 2018. That patch I referenced is from 2019, so this version definitely includes it. But support could have come from other patches too