There is no mailing list I'm aware of for bcc. You may want to contact Robert de Bath directly as he was the last major maintainer I am aware of that worked with the compiler internals directly. We use bcc but we don't directly maintain it.
On April 8, 2015 12:41:29 PM EDT, MFLD <mfld.fr@xxxxxxxxx> wrote:
>Hello,
>
>No reply to this one... should I submit that case to another mailing
>list ?
>
>Regards,
>
>MFLD
>
>On 27/03/2015 18:55, MFLD wrote :
>> 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" :-) ?
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-8086"
>in
>the body of a message to majordomo@xxxxxxxxxxxxxxx
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
