Difficulties Declaring Functions in a Header

[mark3094]

Hi,

I've been working on my physical memory manager, which contains three functions, which are entirely in main.c
Now that I have tested them properly, I wish to move them into another c file, and move the declarations into a header.

I started by moving one function declaration, int init_memory (int location, int size), into a header, pmemory.h

I then compile and link (Using Visual Studio Express on Windows), and get no errors. I start up my Virtual Machine (VMWARE Workstation) and get this error:
A Fault has occuredcausing a virtual CPU to enter the shutdown state.

If I move the declaration back to main.c, it works correctly.


Any ideas?

[thepowersgang]

Yes.

• Use bochs/qemu (something with debugger support)
• Learn to use your language correctly, from your description it seems that you have not written C programs spread among multiple source files.
• Ensure that all code is correctly linked. Check the disassembly to confirm this.

[mark3094]

Learn to use your language correctly, from your description it seems that you have not written C programs spread among multiple source files.

This is definitely not the case.

I have used multiple source files. Until now my project has consisted of libraries that are linked by the 'main' project. The majority of my code has been specific to hardware (I'm developing for x86 and RPi), so it uses libraries. This is the first time I have implemented code that can be reusable across platforms, which is why it is in the 'main' project (whic does not yet have code spread across multiple files, like the libraries do).

I have just confirmed that this problem does not happen on the Raspberry Pi (using GCC/Yagarto toolchain on Windows), only on x86 with Visual Studio, so it's not a simple problem with the usage of the language. I suspect that there's something wrong in the compiler somewhere, but I'm not really sure where to look.

[Love4Boobies]

I have just confirmed that this problem does not happen on the Raspberry Pi (using GCC/Yagarto toolchain on Windows), only on x86 with Visual Studio, so it's not a simple problem with the usage of the language. I suspect that there's something wrong in the compiler somewhere, but I'm not really sure where to look.

It's common that people instinctively blame their tools when they can't figure out what they did wrong. You have in fact not excluded the possibility of misusing C, as a program could act differently under different circumstances due to unspecified, undefined, implementation-defined, locale-specific, and/or underspecified behavior. To be sure, prepare a test case (i.e., a minimal program exhibiting the same symptoms), together with build instructions, and show it to us. That way, we'll have something to work with.

[bwat]

So you've got something like the following:

Code: Select all

/* pmemory.h */

int init_memory (int location, int size);

and

Code: Select all

/* main.c */

#include "pmemory.h"

void main (void)
{
  /* stuff deleted */
  ecode = init_memory(start, length);
  /* stuff deleted */
}

int init_memory (int location, int size)
{
  return -1;
}

And it crashes on one platform but works on another?
Also, if you copy the one line from pmemory.h into the top of main.c the crash disappears?
Do you not have some form of debugger where you can step through the call to init_memory with both versions and compare the machine state? The number of people suggesting this should be taken as a heavy hint.
Have you looked at the assembly code output of the two different compilations with Visual Studio and diffed the results?

[mark3094]

And it crashes on one platform but works on another?
Also, if you copy the one line from pmemory.h into the top of main.c the crash disappears?

That's it exactly!

Do you not have some form of debugger where you can step through the call to init_memory with both versions and compare the machine state? The number of people suggesting this should be taken as a heavy hint.
Have you looked at the assembly code output of the two different compilations with Visual Studio and diffed the results?

I'm working through this now. This will take me some time (other commitments and such).

I have noticed that the order of the functions change in kernel.map.
This is (part) of the one that works:

Code: Select all

 0000:00000000       ___safe_se_handler_count   00000000     <absolute>
 0000:00000000       ___safe_se_handler_table   00000000     <absolute>
 0001:00000000       _main                      00100400 f   main.obj
 0001:00000030       _mem_bitset                00100430 f   main.obj
 0001:000000f0       _mem_alloc                 001004f0 f   main.obj
 0001:00000230       _init_memory               00100630 f   main.obj

And this one is broken:

Code: Select all

 0000:00000000       ___safe_se_handler_count   00000000     <absolute>
 0000:00000000       ___safe_se_handler_table   00000000     <absolute>
 0001:00000000       _init_memory               00100400 f   main.obj
 0001:000000f0       _main                      001004f0 f   main.obj
 0001:00000120       _mem_bitset                00100520 f   main.obj
 0001:000001e0       _mem_alloc                 001005e0 f   main.obj

I use start as my entry function (in an ASM object) which calls main, so I don't think it's an entry point problem.

I will post some disassembly as soon as I can.


Thanks

[mark3094]

I have attached the working and broken ASM and MAP files.

The difference between the two is:
1. I have removed the init_memory declaration from main.c
2. I have added the declaration to memory.h

This function is declared as:

Code: Select all

int init_memory (int location, int size);

I'm going to look deeper, and see what else I can find.

[mark3094]

I have found part of the answer. In the project properties, the Platform Toolset is set to v110 by default (in VS 2012). I changed it to v100, and now it works!

The next task is to figure out what's changed in the new version to cause this problem.

I realise that many of you don't use Visual Studio, but if anyone has come across this or something similar, I'd really appreciate your input.


Thanks again

[Combuster]

My crystal ball says someone's not even bothering to check the entry point.

[mark3094]

My crystal ball says someone's not even bothering to check the entry point.

Crystal Ball's off this time. Entry point is _start, which is defined in crt0.asm, and can be seen in the map file.
This then passes control to the main function.

If anything, I thought it would have something to do with the way I'm linking libraries, which I'm investigating now. However, changing the platform toolset back a version seems to fix the issue. I now have my functions running in separate .c files, and they're declared in a header.


Map file (for interest sake):

Code: Select all

 0000:00000000       ___safe_se_handler_count   00000000     <absolute>
 0000:00000000       ___safe_se_handler_table   00000000     <absolute>
 0001:00000000       _init_memory               00100400 f   init_memory.obj
 0001:000000e0       _main                      001004e0 f   main.obj
 0001:00000110       _mem_bitset                00100510 f   mem_bitset.obj
 0001:000001e0       _hal_init                  001005e0 f   hal:hal.obj
 0001:00000260       _kprintf                   00100660 f   hal:kprintf.obj
 0001:00000420       _write_char                00100820 f   hal:write_char.obj
 0001:00000550       _linewrap                  00100950 f   hal:write_char.obj
 0001:00000630       _init_hardware             00100a30 f   hal:init_hardware.obj
 0001:00000b20       _copystring                00100f20 f   hal:init_hardware.obj
 0001:00000b60       _compare                   00100f60 f   hal:init_hardware.obj
 0001:00000be0       _itoa                      00100fe0 f   hal:intconv.obj
 0001:00000c70       _uitoa                     00101070 f   hal:intconv.obj
 0001:00000cd0       _itoh                      001010d0 f   hal:intconv.obj
 0001:00000e80       _reverse                   00101280 f   hal:intconv.obj
 0001:00000ef0       _strlen                    001012f0 f   hal:strlen.obj
 0002:00000000       _setcursor                 00101400     hal:cursor.obj
 0003:00000000       ??_C@_0BJ@GMIDNCHB@x86?532?9bit?5Architecture?6?$AA@ 00101600     main.obj
 0004:00000000       _start                     00101800     crt0.obj
 0004:00000460       _itoastr                   00101c60     <common>
 0004:00000480       _hw_brandstr               00101c80     <common>
 0004:000004c0       _MemMap                    00101cc0     <common>
 0004:00000640       _mem_bitmap                00101e40     <common>
 0004:00000644       _cursor                    00101e44     <common>
 0004:00000648       _mem_bitmapsize            00101e48     <common>
 0004:00000650       _HwFeatures                00101e50     <common>
 0004:00000658       _memory_total              00101e58     <common>
 0004:0000065c       _hw_brandid                00101e5c     <common>
 0004:00000660       _hw_vendor                 00101e60     <common>
 0004:00000670       _mem_blocks                00101e70     <common>
 0004:00000674       _mem_entries               00101e74     <common>

[bwat]

Am I stupid or did init_memory just lose 16 bytes of code?

[Love4Boobies]

I have an inkling it's a misuse of C linkage and that the RPi port works accidentally. Could you show us the C code instead, as I originally asked, so we don't have to go through the assembly listings and potentially guess what you did wrong in your C code?

[mark3094]

Thanks for your help everyone. It's working perfectly now.
I don't think the problem was the code or the compiler in the end, as now I've put the version back to v110, and I have the code working in separate .c files.

As embarrasing as it is, the problem is with my PC. In the end, the solution that worked, was (seriously) turning it off and on, then deleting the .c files I was using and recreating them.
I've thought it was time to replace this box for a while now, and I guess this is just more evidence that I have to do it soon.


Sorry to waste yout time, and thankyou for your willingness to help with the issue (even though it's a frustrating one).

[Love4Boobies]

As I've said before, just because it seems to work (on your system, for now) doesn't mean you've fixed it. This is one of the reasons there is so much crap code in the world: people hack it together. Any engineer can tell you that.

[bwat]

Wahey! Another magical solution.

As embarrasing as it is, the problem is with my PC. In the end, the solution that worked, was (seriously) turning it off and on, then deleting the .c files I was using and recreating them.

C'mon, do you honestly think the machine was at fault?

I've thought it was time to replace this box for a while now, and I guess this is just more evidence that I have to do it soon.

Sounds a bit like you're trying to justify the conclusion with weak evidence, either that or it's a case of abductive reasoning

Sorry to waste yout time, and thankyou for your willingness to help with the issue (even though it's a frustrating one).

Personally, I don't consider my time to be wasted so no need to apologise. I'm more worried about your reasoning. You sound like an intelligent guy who is, unfortunately, behaving like a typical newbie that is seen, sadly, all to often on this board. My money is on you seeing the same problem again on your travels because you haven't made an effort to modify your behaviour. If you're lucky, buying a new computer or restarting your project from scratch will solve the problem the next time it pops up.