0.1 Function Symbols gone

[fiery loom]

Hi, up to now I have been able to compile in ReleaseFast and was still able to do b break_fnand the smybols was found by gdb. Since the upgrade this is not the case anymore. How can I get my symbols back without using Debug Mode? greets!

[noble torrent]

i know there was a change to strip debug info from ReleaseSmall builds by default

it might have changed for ReleaseFast too?

[fiery loom]

The problem is that the debug mode doesn’t run my code. so is there anyway to have some symbol info in a release built?

[primal yacht]

If all that was changed is that -fstrip is the default, then you may be able to pass -fno-strip instead.

[sudden elm]

thats concerning

[fiery loom]

well, yes. on the other hand, it's a bare metal kernel and it runs in all different modes but doesn't even boot in Debug, not investigated yet as to why but it's isolated enough that I don't really care yet

[fiery loom]

yep, will try

[worn basalt]

what happens during boot with a runtime error…. perhaps debug’s runtime checks are causing a silent boot failure?

[fiery loom]

no did not make a difference ): (tried it before as well)

[fiery loom]

yeah I'm going to look into it

So instead of trying to describe what's happening I will just show you the relevant part at which part of the assembler boot (whereby bl_main is the zig boot entry fn) the Debug mode version crashes

https://pastebin.com/BwPwC8kc

to be frank I don't fully understand why exactly all of the instructions suddenly turn to 0xff...

[frozen kestrel]

That's a sign that you're writing to qemu pflash, it does that when you try to write to readonly flash

looks like you've ended up with the entry point not being at the load base address, your linker script may be wrong

that would explain it, because then you will have a function at the start, which will push some values on the stack, which will try to write to pflash accidentally

[fiery loom]

Yeah, that could be it. At which address does the pflash start?

[frozen kestrel]

the qemu virt machine has its first pflash device at address 0

https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L132

[fiery loom]

Oh, well, the stack is initiated later in the boot loader, so maybe the stack 0 at the beginning

[frozen kestrel]

Yes, most registers are zeroed out at boot

[fiery loom]

So the reason why that only occurs in the debug is runtime checks then?

[frozen kestrel]

I would recommend using a bootloader to not have to deal with relocating from pflash (from a location you're not linked against, so you have to manually do addressing modes here)

[frozen kestrel]

Probably that some debug data is being put before your code

depending on how you've set up your arguments to qemu

[fiery loom]

Okay, thank you very much! That really explains everything, is there someway to disable the runtime checks ?

[frozen kestrel]

with what I think you're doing, your qemu will probably start executing at address 0

[frozen kestrel]

no, that's not what you should be doing

[fiery loom]

Sure it does but I (for all I know) I am accounting for that

[frozen kestrel]

you need to fix your linker script so that your entry point ends up at the start of the binary

[frozen kestrel]

okay, but your entry point isn't at 0

it's at 0x000000000000386c in your paste

that's bad

[fiery loom]

What exactly do you mean?, My binary is loaded at zero, so I start executing there, don’t I? :D

[frozen kestrel]

yes

but the binary needs to start with your entry point

it has no idea how to find your entry point

so it just starts executing it from offset 0

[fiery loom]

I thought it’s automatically linked against zero then

[frozen kestrel]

what does your build.zig do

and what does your linker script look like

[fiery loom]

Build a standard elf, and I’m then loading the raw version

[frozen kestrel]

raw version?

did you use the section dumping I added to the build system?

[fiery loom]

Wait, there is a zig fn for that 1 sec

‘ run_step_serial_gdb.dependOn(&bl_exe.installRaw("bootloader.bin", .{ .format = std.build.InstallRawStep.RawFormat.bin, .pad_to_size = bl_bin_size }).step);’

[frozen kestrel]

ah okay so you're close

[fiery loom]

(Im on my mobile phone sry)

[frozen kestrel]

first of all, you only need .format = .bin

don't need to type it out

but you also need .only_section_name = ".my_blob_section"

and then you need to pack your sections into .my_blob_section in your linker script

https://github.com/FlorenceOS/Sabaton/blob/master/build.zig#L121

[fiery loom]

I will look into it in a minute, I need to catch a train sorry

But thank you

[frozen kestrel]

or you can just use Sabaton from your project and call this function to get a binary straight away :)

and get the rest of a bootloader for free

but feel free to copy as much code as you may need to too

I guess in theory you don't need to dump a specific section if you set your linker script up properly

[fiery loom]

What exactly does the “only section” change,?

[frozen kestrel]

It only dumps a single section to a binary file. That means you can have your .blob section as the binary running in the VM and all the debug sections left in the original ELF binary

so it looks exactly like a normal ELF executable except it only has a single code/data section, like it is when running a binary image from qemu pflash

[fiery loom]

Well, I am in defining the entry address via . = entry_addr at the beginning and then compensating for that in the exe

[frozen kestrel]

can you just send your linker script

are you putting the entry point at the start

[fiery loom]

Okay, that makes sense, I thought one could just execute it, and the sections would be ignored

[fiery loom]

Sure wait

https://github.com/luickk/MinimalRoboticsPlatform/blob/main/src/bootloader/linker.ld

[frozen kestrel]

That is true, but what happens is if you don't just dump a single section is that all sections will be present in the binary file. It will look just like a memory dump from address 0 (so if you link at address 0x1000, you will have 0x1000 padding bytes in the start)

so only works if everything is correct, and will always load the entire elf, not just what you specified

[fiery loom]

The {@zig} is replaced with the variables defined in the build.zig here: https://github.com/luickk/MinimalRoboticsPlatform/blob/main/build.zig in line 185

[frozen kestrel]

oh boy.

does . = {@zig}; set it to 0?

[fiery loom]

Aha

[fiery loom]

For qemu virt machine yes

[frozen kestrel]

so it will read . = 0; after replacement?

[fiery loom]

For the raspberry it’s 0x8000

[fiery loom]

Jup

[frozen kestrel]

okay cool

aha

your bl_main function doesn't have linksection(".text.boot")

it definitely needs that

you need that on exactly one function, your entry point

also, I heavily recommend you writing an asm entry point, you can't set your stack pointer otherwise

so this function will also just crash, since you don't have a stack yet so you can't call zig

[fiery loom]

Okay, to be perfectly honest, I thought that name was just good practice, but not “ important”

[frozen kestrel]

It needs to match the first section emitted in your linker script

[fiery loom]

How do I define that?

[fiery loom]

Ohh in the zig code

Aha

[fiery loom]

Sure, I will do that

[frozen kestrel]

bl_main:
  ADR SP, my_stack
  BL bootloader_entry

also you have many other issues

[fiery loom]

Aha ok sure entry point as in entry point for the stack

[frozen kestrel]

no, the binary

you can't use global variables, because you're still in pflash (all your code and globals are readonly)

you need to relocate yourself to RAM.

[fiery loom]

I did to that in my boot loader, and not at the beginning, because when I’m booting from rom , I have to find the start address of the ram first…

[frozen kestrel]

that's known at compile time

[fiery loom]

Yeah, I’m doing that

[frozen kestrel]

For qemu virt, dram starts at 1GiB

[fiery loom]

But I didn’t know how to put it in the assembly code, didn’t really think about it too much, that was just a temporary solution, that kind of bit me know

[frozen kestrel]

but the device tree blob is at dram base, so you probably want to skip a little bit forward from there

[fiery loom]

Jup

[frozen kestrel]

yep

if you don't want to think about this, use an existing bootloader and just load a normal ELF file

[fiery loom]

🥲😅

[frozen kestrel]

but you gotta do this if you want to write one yourself

feel free to look at sabaton setup code

[fiery loom]

ha ha, the goal of the project was really to do everything myself

[frozen kestrel]

it relocates into dram properly

[fiery loom]

I am really appreciating your experience though!

[frozen kestrel]

Here is the entry point for Sabaton: https://github.com/FlorenceOS/Sabaton/blob/master/src/platform/virt_aarch64/entry.S

[fiery loom]

It absolutely does do so already

[frozen kestrel]

it does everything from DRAM relocation, stack setup and everything

[fiery loom]

Sure, but if I look at the solution, I didn’t do it myself 😂 jokes aside, I have already been looking at yours(when I didn’t know any better in pain) and it has been really helpful!

[frozen kestrel]

ah no worries

the license allows you to copy whatever you like and call it your own

[fiery loom]

Never gonna do so, I swear, it’s a question of moral, and ego, I guess…

[frozen kestrel]

I mean it's explicitly allowed but you do you

[fiery loom]

No, it’s not about that, it’s that I want to understand everything and one can only reach that point bye doing everything yourself

[frozen kestrel]

in general, you need to

1. Link your binary at the relocated address
2. Properly relocate yourself in asm to the new address, keeping addressing modes in mind to not get absolute accesses when you need a relative one (this is important as you're executing at different location than you're linked at)
3. Set up a stack
4. Call zig

in general, that's the process to get anything running on baremetal

I don't recommend making a position independent binary, because then you have to write your own dynamic linker

[fiery loom]

I have the bootloader and kernel binaries concatenated, and then just copy the kernel to dram, and then execute it there, the kernel is already linked to the dram entry right at the beginning

[frozen kestrel]

keep in mind you probably don't want to put your shit at the dram base

because that's where the dtb is

and you probably want to be able to reference it later

[fiery loom]

Ah, that is true

[frozen kestrel]

you need to copy the bootloader over too if you want to use globals in it

[fiery loom]

No, I don’t need to do so. I just wanted to have it in zig to have it as explicit and understandable/readable as possible.

[frozen kestrel]

also, it's very easy to not have to concat the files for qemu, since it can just provide you files on the filesystem to your code

but that's still a fair solution

[fiery loom]

Sure, but I want to have it deployable on physical boards as well

[frozen kestrel]

yep

that's a different deal entirely

[fiery loom]

Shh don’t spoiler me 😂

[frozen kestrel]

Yeah...

Qemu is a good start, gets you introduced to some hardware concepts

[fiery loom]

but I know, and I will concern myself in a few months with that when I’m done with the current stuff. But I can totally imagine that it will get reallly “gnarly”

And that I will have to overhaul 70% of my code…

[frozen kestrel]

Big yep.

[fiery loom]

))):

New challenge then but I have learned so much, has been totally worth it so far

[frozen kestrel]

Avoid uboot like the plague it is. That's my biggest recommendation

[fiery loom]

I have been looking at such code bases, plenty of times, and it really it is bad… lol

Zig for the win