Anyone used tcc?
Anyone used tcc?
Hello. I try to replace gcc with TinyCC, but when i try compile one of my file(which fine compiled in gcc) i get error:
libc.c:36: incompatible types for redefinition of 'puthex'
My puthex:
void puthex(unsigned char byte)
{
unsigned char lb, rb;
lb=byte >> 4;
rb=byte & 0x0F;
puthexd(lb);
puthexd(rb);
}
Anyone know how to resolve this?
libc.c:36: incompatible types for redefinition of 'puthex'
My puthex:
void puthex(unsigned char byte)
{
unsigned char lb, rb;
lb=byte >> 4;
rb=byte & 0x0F;
puthexd(lb);
puthexd(rb);
}
Anyone know how to resolve this?
Re:Anyone used tcc?
How do you declare puthex (in an .h file)? Perhaps the .h file defines it differently from the .c file.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Anyone used tcc?
haven't used TinyCC either, but yes, it seems reasonable to think that you'll have to declare
first if you intent to use it as a recursive function. For some reason, the prototype of the definition [tt]void puthex(...) {...}[/tt] seems to be ignored as long as the block isn't completely processed.
Code: Select all
void puthex(unsigned char byte);
Re:Anyone used tcc?
Thanks! Yes, TCC need declared functions, instead of gcc that AFAIK don't need this always
Re:Anyone used tcc?
GCC usually isn't pedantic. Try gcc -std=c99 -pedantic -pedantic-errors and try againLinuxMan wrote: Thanks! Yes, TCC need declared functions, instead of gcc that AFAIK don't need this always
Re:Anyone used tcc?
Thx candy, now i know. Btw, i still have some problems with kernel. Kernel compiles without error but when i try to load they with grub system is reloaded . Linker script i use from http://www.mega-tokyo.com/osfaq/HigherHalfBareBones. Objdump -h of kernel:
I see that Align of .text is 2**5 instead of 2**4 in GCC variant. Anyone known how to fix this?
Code: Select all
kernel.bin: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00001879 c0100000 00100000 00001000 2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00001488 c0102000 00102000 00003000 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00004840 c01034a0 001034a0 00004488 2**5
ALLOC
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Anyone used tcc?
that sounds more like a Triple Fault than something due to misalignment or whatever (actually, GRUB should be happy with whatever alignment constraints you'd place on it).
I suggest you run that in Bochs with a breakpoint at 1MB and see what suddenly goes wrong with your boot sequence (i assume it worked fine when compiled with GCC, right?) ... maybe some structure padding that happens differently on the two platforms ?
I suggest you run that in Bochs with a breakpoint at 1MB and see what suddenly goes wrong with your boot sequence (i assume it worked fine when compiled with GCC, right?) ... maybe some structure padding that happens differently on the two platforms ?
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Anyone used tcc?
1. make sure you have the internal debugger enabled in your bochs (./configure --enable-debugger)
2. run that bochs (bxdebug.exe for wusers, iirc), it should show a black screen and an invite such as
4. continue execution with "c"
Or you might prefer to let GRUB initialize and only debugging once your kernel is loaded, which "pb 0x100000" then "c" should do nicely.
(erhm. if your code starts at 0x1000000 and not at some offset in the image like Clicker, of course.)
Note that the "p" in "pb" is for "physical". There's also "b <seg> <offset>" that can set e.g. a break point at logical address 0x8:0xC00000DE ...
2. run that bochs (bxdebug.exe for wusers, iirc), it should show a black screen and an invite such as
3. enter your breakpoint with e.g. "pb 0x7c00" or "pb 0x100000"Next at t=0
(0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b ; ea5be000f0
<bochs:1>
4. continue execution with "c"
now the BIOS initialization is completed, you can start debugging your bootloader with step-by-step execution "s" or "step-over" execution "n" (to avoid entering BIOS functions again).(0) Breakpoint 1, 0x7c00 in ?? ()
Next at t=2491287
(0) [0x00007c00] 0000:7c00 (unk. ctxt): jmp .+0x7c4a ; eb48
<bochs:3>
Or you might prefer to let GRUB initialize and only debugging once your kernel is loaded, which "pb 0x100000" then "c" should do nicely.
(erhm. if your code starts at 0x1000000 and not at some offset in the image like Clicker, of course.)
Note that the "p" in "pb" is for "physical". There's also "b <seg> <offset>" that can set e.g. a break point at logical address 0x8:0xC00000DE ...
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Anyone used tcc?
and a last-minute-trick: using a second terminal showing "objdump -drS your_elf_kernel.o | less" will definitely help in understanding the output of nasm disassembler
Re:Anyone used tcc?
Code: Select all
(0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b ; ea5be000f0
<bochs:1> pb 0xC0100000
<bochs:2> c
00000003740i[BIOS ] $Revision: 1.166 $ $Date: 2006/08/11 17:34:12 $
00000317560i[KBD ] reset-disable command received
00000318690i[PIDE ] new BM-DMA address: 0xc000
00007100210i[BIOS ] int13_harddisk: function 41, unmapped device for ELDL=80
00007104970i[BIOS ] int13_harddisk: function 08, unmapped device for ELDL=80
00007109615i[BIOS ] *** int 15h function AX=00C0, BX=0000 not yet supported!
00195304420i[CPU0 ] protected mode
00195304420i[CPU0 ] CS.d_b = 32 bit
00195304420i[CPU0 ] SS.d_b = 32 bit
00195304420i[CPU0 ] EFER = 0x00000000
00195304420i[CPU0 ] | RAX=0000000000000010 RBX=000000000002c480
00195304420i[CPU0 ] | RCX=00000000c01034c1 RDX=00000000000000cf
00195304420i[CPU0 ] | RSP=00000000c0107cb0 RBP=00000000c0107cb4
00195304420i[CPU0 ] | RSI=00000000000530fe RDI=0000000000000000
00195304420i[CPU0 ] | R8=0000000000000000 R9=0000000000000000
00195304420i[CPU0 ] | R10=0000000000000000 R11=0000000000000000
00195304420i[CPU0 ] | R12=0000000000000000 R13=0000000000000000
00195304420i[CPU0 ] | R14=0000000000000000 R15=0000000000000000
00195304420i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00195304420i[CPU0 ] | SEG selector base limit G D
00195304420i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00195304420i[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00195304420i[CPU0 ] | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00195304420i[CPU0 ] | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00195304420i[CPU0 ] | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1
00195304420i[CPU0 ] | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00195304420i[CPU0 ] | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00195304420i[CPU0 ] | MSR_FS_BASE:0000000000000000
00195304420i[CPU0 ] | MSR_GS_BASE:0000000000000000
00195304420i[CPU0 ] | RIP=00000000c010006b (00000000c010006b)
00195304420i[CPU0 ] | CR0=0x80000011 CR1=0x0 CR2=0x0000000000000040
00195304420i[CPU0 ] | CR3=0x00102000 CR4=0x00000010
00195304420i[CPU0 ] >> mov ds, ax : 8ED8
00195304420e[CPU0 ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting
00195304420i[SYS ] bx_pc_system_c::Reset(SOFTWARE) called
00195304420i[APIC0] local apic in CPU 0 initializing
00195304420i[CPU0 ] CPU[0] is the bootstrap processor
00195304420e[CPU0 ] CPU_LOOP bx_guard.interrupt_requested=1
Next at t=195304421
bx_dbg_read_linear: physical memory read error (phy=0xc010006b, lin=0x00000000c010006b
Re:Anyone used tcc?
"pb x" means "breakpoint at PHYSICAL address x"
what you need to do is either "lb 0xC0100000" (break at LINEAR address) or "pb 0x00100000", because GRUB loads you at physical 1 MiB, what you can page to whatever you want (linear address), but the physical address is the same
what you need to do is either "lb 0xC0100000" (break at LINEAR address) or "pb 0x00100000", because GRUB loads you at physical 1 MiB, what you can page to whatever you want (linear address), but the physical address is the same
Re:Anyone used tcc?
No matter! I can don't set any breakpoints - s still have
bx_dbg_read_linear: physical memory read error (phy=0xc010006b, lin=0x00000000c010006b
bx_dbg_read_linear: physical memory read error (phy=0xc010006b, lin=0x00000000c010006b
Re:Anyone used tcc?
Set a linear breakpoint at the boot location (7c00) and step through your boot code (or, if you use GRUB, set the linear BP to your ASM entry point)