foliagecanine wrote:If you could supply your code (i.e. on GitHub) for us to look at, that would be helpful for diagnosing the problem.
Specifically, if you are willing, please post the linker script and the file in which this code is running.
It may be other code around it or the linker causing the problem, since compiling
Code: Select all
#include <stdio.h>
#include <stdint.h>
int main() {
uint32_t *test = (uint32_t *)0xC010000;
printf("Address: 0x%X.\n",(uint32_t)(intptr_t)test);
return 0;
}
with a C compiler and run it, it outputs "Address: 0xC010000."
Make sure you aren't modifying the value of test anywhere else as well.
I wish I could post the link, but it's on a private repo for a reason... It's privileged code only for my company Psionix Softworks, despite the fact that I work "alone" on it. I can provide snippets here and there, but most things are renamed to protect actual source base. I have created a function called "test_code" for the purposes of testing before implementation. So no, it isn't used elsewhere. Here's my linker (temporary, with unimportant things left out/omitted):
Code: Select all
...
. = 1M;
.text BLOCK(4K) : ALIGN(4K)
{
*(.multiboot)
*(.text)
}
.data BLOCK(4K) : ALIGN(4K)
{
*(.data)
}
.rodata BLOCK(4K) : ALIGN(4K)
{
*(.rodata)
}
.bss BLOCK(4K) : ALIGN(4K)
{
*(COMMON)
*(.bss)
}
kernel_end = .;
...
As for the code that the address value is assigned, it's literally after the initialization of the other modules with my memory module and paging code commented off as to not interfere.
Paraphrased in my main module:
Code: Select all
<kernel-type> kmain(void)
{
...
test_code();
}
static inline void test_code(void)
{
uint32_t *test = (uint32_t *)0xC0100000;
printf("Address: 0x%X.\n", test); // Also tried "&test"
}
Literal Output:
...
Address: 0x3FF00000. // Without '&'
And:
...
Address: 0x10DC4C. // With '&'
Nothing too special really. This code was tested with minimal modules to avoid conflicts.
Also I noticed tou missed a zero. It's a uint32_t, as such, it should have 8 digits in the hex value: 0xC010 0000.
Edit:
I feel that I should also mention that this is in an attempt to replace my current (working) heap. I borrowed it from elsewhere and now want to replace it with my own code. As such, I am in the process of building my heap from the ground up. So this location in memory should not be influenced by other code since it is most definitely independent. And in Visual Studio 2017 I got the same result as you foliagecanine. I just can't understand why all of a sudden the addresses are all so far off. Let me try something else...
Edit2:
No luck. I thought that if I pulled the address of an array index it would work. Yesterday I was using smaller values like 0x4000 and it was working. Now it seems to not work. I can't remember if it was because I removed the old heap or left it in, but for some reason it doesn't seem to want to work right...
Okay so I tested with just 0xC010, could it be a "number too large" case? I feel like that's what it is. test[0] = 0xC010, test[1] = C014, which makes sense if it's aligned by 4 bytes. How would I fix that if that's what it is?
Edit3:
Okay so here's something interesting. I decided to test a different way...
Code: Select all
if (&test[0] == 0xC0100000)
printf("&test = 0xC0100000");
At which point it printed:
&test = 0xC0100000
Perhaps it's the way large numbers are being represented in hexadecimal. Maybe indeed...
I just tried something:
And it prints: -1...
Hmm. That can't be normal...
Figured it out actually... It wasn't that the address was misplaced, it was how I printed hex values to the screen in my print function. Now it prints the correct address. However, without the array index it still prints a 6 digit hex value starting at 10XXXX. Is that normal?
Also, would it be a bad idea to consider starting at 0x7FFFFFFF?