Question on import symbols generated by BCC

Question on import symbols generated by BCC

[MFLD]

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" :-) ?

Re: Question on import symbols generated by BCC

[MFLD]

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" :-) ?

Re: Question on import symbols generated by BCC

[Jody Bruchon]

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@gmail.com> 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@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Question on import symbols generated by BCC

[Marc-François LUCCA-DANIAU]

OK, thanks for your advice. Just one more question before forwarding
to Robert de Bath : I see that Lubomir Rintel (alias lkundrak)
archived DEV86 on GitHub before you made a clone. Is this archive a
"save willy", or should I contact also this guy in case he is a
maintainer ?

Thanks,

MFLD

2015-04-08 18:45 GMT+02:00 Jody Bruchon <jody@jodybruchon.com>:
> 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@gmail.com> 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@vger.kernel.org
>>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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question on import symbols generated by BCC

[Jody Bruchon]

On 4/9/2015 4:31 AM, Marc-François LUCCA-DANIAU wrote:
> OK, thanks for your advice. Just one more question before forwarding
> to Robert de Bath : I see that Lubomir Rintel (alias lkundrak)
> archived DEV86 on GitHub before you made a clone. Is this archive a
> "save willy", or should I contact also this guy in case he is a
> maintainer ?

My understanding is that lkundrak is the maintainer; however, 
considering no changes to dev86 were made since 2013 and RDB updated the 
code with some degree of regularity prior to that maintainer change, I 
assume that he is a better person to ask about issues with bcc 
internals. Feel free to ask either or both; I don't imagine they will 
object to a question in any case. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question on import symbols generated by BCC

[MFLD]

-------- Message transféré --------
Sujet : 	Re: Fwd: Question on import symbols generated by BCC
Date : 	Sat, 11 Apr 2015 18:19:35 +0200
De : 	MFLD <mfld.fr@gmail.com>
Pour : 	Robert de Bath <"robert$"@debath.co.uk>
Copie à : 	lkundrak@v3.sk, Jody Bruchon <jody@jodybruchon.com>


Hello,

Thank you for your quick response, so that it is a bit more clear in my
mind.

But I am afraid I still don't fully understand the sentence: "But in
general it's unlikely to catch many errors because the compiler will
give a type error or a redefinition error.", and I feel unconfortable
with it (no clear understanding = predictable failure in coding :-)).

In the case of BCC adding a "extern _entry" in its output file when it
scans an extern function declaration, could you explain me deeper why
the compiler would generate an error ?

Regards,

MFLD


Le 10/04/2015 23:49, Robert de Bath a écrit :
Hello, Marc-François,



First some examples...



> SYM 0    00000000 ...IT _main
#               ^------------- This is an import
#                ^------------ We know it's in the TEXT segment

> SYM 1    00000000 ..E.T _entry
#              ^-------------- External label definition.
#                       ^------------ It is in Text segment

< SYM 2    0000000c ....T _test
#              ^^------------- 'Object internal' (or 'static') label
#                       ^------------ It is in Text segment

< SYM 3    00000000 ...ID __end
#               ^------------- This is an import
#                ^------------ We know it's in the DATA segment

> SYM 0    00000000 ..E.T _main
#              ^-------------- External label definition.
#                       ^------------ It is in Text segment

> SYM 1    00000000 ...IU _entry
#               ^------------- This is an import
#                ^------------ The segment is not known.

If the label is in a known segment and is different between two objects
the linker will generate a warning. For tiny model (CS=DS=SS) this isn't
significant, but if CS!=DS it will be a problem.

It would probably be reasonable for BCC to generate the directives to put
external labels into the correct segment. But in general it's unlikely
to catch many errors because the compiler will give a type error or a
redefinition error. So it was never implemented.

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.debath.co.uk/>

On Thu, 9 Apr 2015, Marc-François LUCCA-DANIAU wrote:

Hello,

I'm Marc-François, a french guy playing with ELKS and a SBC based on
the IBM-PC XT architecture (yes it still exists in production ,
that's an Advantech device :
http://www2.advantech.com/products/1-2JKP2Y/SNMP-1000-B/mod_B01ABE8D-C8AA-4530-8E3C-9FCD2623D9D6.aspx). 


I got a problem with DEV86 that I initially submitted to the ELKS
mailing list, but Jody Bruchon redirected to you, as the latest deep
contributors to DEV86.

Would you be so kind to give a piece of advice to the question below
(if it is a real problem or not) and suggest where to dig to fix that
problem ?

Thanks in advance,

Regards,

MFLD
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html