-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RISC-V from scratch 2: Hardware layouts, linker scripts, and C runtimes #5
Comments
grep doesn't need cat. At all. It's called UUOC. |
@StephaneFr - fixed with 9c4840e. Thanks for the feedback! |
Please keep them coming! |
@limslarmo, work has officially begun on part three - stay tuned. 😄 |
hey!, I am not able to use tub option on macOS Mojave can you help me? |
Hey again @yashomer1994. I'm not sure what you mean by "tub option" - could you give me some more information? What command are you trying to run, and what error are you getting? |
Tui*option in gdb
On Thu, 1 Aug 2019 at 1:14 AM, Tyler Wilcock ***@***.***> wrote:
Hey again @yashomer1994 <https://github.com/yashomer1994>. I'm not sure
what you mean by "tub option" - could you give me some more information?
What command are you trying to run, and what error are you getting?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5?email_source=notifications&email_token=AEKGT3VRPQGPPBP5QX4TCR3QCHTS5A5CNFSM4HN3WXJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3ILB5Q#issuecomment-516993270>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEKGT3VD2ELTVBZIUTLA2RTQCHTS5ANCNFSM4HN3WXJA>
.
--
Sent from Gmail Mobile
|
Is this the command you are trying to run?
The
|
Hey, Yeah its done working.
I jus relinked my riscv64-unkown-elf-gdb
And its working fine.
On Thu, 1 Aug 2019 at 9:45 AM, Tyler Wilcock ***@***.***> wrote:
Is this the command you are trying to run?
riscv64-unknown-elf-gdb --tui a.out
The riscv64-unknown-elf-gdb executable should support the --tui flag. If
this indeed the command you are trying to run, could you give me the
version of your GDB installation? Here is mine:
riscv64-unknown-elf-gdb --version
GNU gdb (GDB) 8.2.90.20190228-git
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5?email_source=notifications&email_token=AEKGT3UMBAN75U6WD7SKEIDQCJPPHA5CNFSM4HN3WXJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3JIARQ#issuecomment-517111878>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEKGT3RKVH2IGW3V45FMDYTQCJPPHANCNFSM4HN3WXJA>
.
--
Sent from Gmail Mobile
|
hi Tyler, I got a way to allocate the initial stack without having to define a symbol in the linker script:
|
Hey @chillancezen, Looks promising — nice work! Not sure if this is applicable in this context, but you may need greater than a 4-byte alignment ( For more discussion on this subject, look here in part four. |
sure, you are right, it must be 16-bytes aligned. |
Hi, is there any way to use gdb from within Eclipse to attach to the QEMU gdbserver? |
Also, it would be nice to have some documentation stating what is the content of the ROM of the virt machine, placed at 0x1000. |
Hello @adeaarm!
Yes, that should be doable. In this section of the post, we run this command:
The https://stackoverflow.com/a/4235095/2421349
Digging around a bit, I found this, which seems to imply the value of the ROM is https://github.com/qemu/qemu/blob/02777ac3036187077c98a05843d888b4be8c51b3/hw/riscv/virt.c#L508#L509 I wasn't able to actually find this file in the First I compiled
And then connect to this with our GDB client:
From here, using GDB's examine command (also see GDB output formatting), we can check out what is in the memory address range of the ROM, 0x1000 to 0x11000:
Here's a screen recording of me doing this. Note the bits I highlight.
Look familiar? If you've made it through post two, it should! It appears the DTS for the Hopefully this helps. Go forth and explore 🚀 |
Thanks for your reply @twilco. Yes, I noticed that |
Hi, |
Hi @Shiva-prog123! It's hard to say without some more information. Can you please post your updated C program? Also, when you say "output", do you mean you're running your program under GDB and trying to print the results of additional operations (e.g. multiplication as you mentioned), but are unable to? |
Hi, |
Thanks for posting your code snippet! You may already know this, but Github supports Markdown formatting, so you can make your code look a bit nicer if you surround it in triple backticks (and optionally include the language of the snippet after the first triplet): ```c I included backslashes to prevent the rendering, but without them it looks like: int main()
{
int a=20,b=17,c,d,e,f;
c=a+b;
d=a*b;
e=a-b;
f=a/b;
return 0;
}
When the compiler sees this, it allocates memory for these local variables on the stack by decrementing (or sometimes incrementing) the stack pointer register by So I'm not sure exactly what you mean when you say you're only able to get the first result, but I think you may be heading the wrong direction looking at the linker script and CRT (unless something much larger is going wrong here). In the end of this post, we run our C program with GDB and set a breakpoint. I'd recommend you do the same here if you'd like to examine the results of these calculations (e.g. using GDBs Throughout this series of posts we talk about how the stack works, but this video also explains it super well. |
Thanks for the reply! how we can increase the stack size? |
In our current setup, the stack will grow unbounded until we run out of physical memory. Concretely, this means we'll keep decrementing the So, in order to increase stack size, increase the amount of physical memory available and then set It sounds like you might be interested in the Implementing a function prologue section of post 4. It's a big skip forwards, but reading it through might illuminate some of the concepts you're exploring. |
Thank you! I will check it out... |
Thanks for great explanation of such tricky concepts! Why does such crucial info, as memory map of qemu's machines, is not explicitly represented in it's docs, like in all MCUs docs? The only way to get it, is to read dtb or to dig in virt's source code. |
Any help with this issue: The following two regions overlap (in the memory address space): Any suggestions?? |
Just add |
It's very helpful to me, thanks. However I have a problem. There are different size of instructions in my disassembled code like this. 80000018: 1101 addi sp,sp,-32 8000001a: ce22 sw s0,28(sp) 8000001c: 1000 addi s0,sp,32 8000001e: 4791 li a5,4 80000020: fef42623 sw a5,-20(s0) 80000024: 47b1 li a5,12 80000026: fef42423 sw a5,-24(s0) 8000002a: fec42703 lw a4,-20(s0) 8000002e: fe842783 lw a5,-24(s0) 80000032: 97ba add a5,a5,a4 80000034: fef42223 sw a5,-28(s0) 80000038: bfcd j 8000002a <main+0x12> how can i fix the size of instructions?? |
hi every one can some one help me please |
for me i have the same problem , how can i fix this ?? -VirtualBox: |
Hi @twilco |
I ran into the same |
RISC-V from scratch 2: Hardware layouts, linker scripts, and C runtimes
A post describing how C programs get to the main function. Devicetree layouts, linker scripts, minimal C runtimes, GDB and QEMU, basic RISC-V assembly, and other topics are reviewed along the way.
https://twilco.github.io/riscv-from-scratch/2019/04/27/riscv-from-scratch-2.html
The text was updated successfully, but these errors were encountered: