Question on import symbols generated by BCC
MFLD <[email protected]> Fri, 27 Mar 2015 18:55:48 +0100
| Newsgroups | org.kernel.vger.linux-8086 |
|---|---|
| Message-ID | <[email protected]> |
Hello,
>
> While compiling a boot code for my embedded device that will load ELKS
> from the Flash, I get some trouble while linking several object files
> together, some of them are .S compiled with AS86, others are .C
> compiled with BCC. Let me explain with a unit test to insulate the
> problem:
>
> Here is the first source file "test1.s":
>
> .extern _main
> .define _entry
> .text
> _entry: br _main
> end
>
> Here is the second souce file "test2.c":
>
> extern void entry ();
> void main () { entry (); }
>
> These simple sources make 2 cross references with 2 exports and 2
> imports in each object files.
>
> Here is the object file generated by "as86 -o test1.o test1.s"
> (objdump86 test1.o):
>
> OBJECTFILE 'test1.o'
> MODULE 'test1'
> BYTEPOS 00000038
> BINLEN 00000003
> STRINGS 0025 +0013
> VERSION 0.0
> SEG0 00000003
>
> SYMS 2
> SYM 0 00000000 ...IT _main
> SYM 1 00000000 ..E.T _entry
>
> text data bss dec hex filename
> 3 0 0 3 3 test1.o
>
> BYTECODE
> SEG 0
> : e9 .
> RELSZ 2
> DW _main-PC
>
> In the symbol table, we can see both the public import & text, and the
> public export & text. That looks correct.
>
> Now here is the object file generated by "bcc -ansi -c -o test2.o
> test2.c" (objdump86 test2.o):
>
> OBJECTFILE 'test2.o'
> MODULE 'test2'
> BYTEPOS 00000038
> BINLEN 0000000c
> STRINGS 0025 +0013
> VERSION 0.0
> SEG0 0000000c
>
> SYMS 2
> SYM 0 00000000 ..E.T _main
> SYM 1 00000000 ...IU _entry
>
> text data bss dec hex filename
> 12 0 0 12 c test2.o
>
> BYTECODE
> SEG 0
> : 55 89 e5 57 56 e8 U..WV.
> RELSZ 2
> DW _entry-PC
> : 5e 5f 5d c3 ^_].
> SEG 3
>
> This time, in the symbol table, the public & import symbol _entry has
> the 'U' flag, not the 'T' as expected.
>
> Should not it be flagged 'T' instead ?
>
> Thanks for your support,
>
> MFLD
>
> PS : the "boot code" I am writting is a kind of "coreboot" for 8086,
> could I name it "boot86" :-) ?