* Question on import symbols generated by BCC [not found] <551595A4.7040206@gmail.com> @ 2015-03-27 17:55 ` MFLD 2015-04-08 16:41 ` MFLD 0 siblings, 1 reply; 6+ messages in thread From: MFLD @ 2015-03-27 17:55 UTC (permalink / raw) To: ELKS 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" :-) ? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on import symbols generated by BCC 2015-03-27 17:55 ` Question on import symbols generated by BCC MFLD @ 2015-04-08 16:41 ` MFLD 2015-04-08 16:45 ` Jody Bruchon 0 siblings, 1 reply; 6+ messages in thread From: MFLD @ 2015-04-08 16:41 UTC (permalink / raw) To: ELKS 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" :-) ? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on import symbols generated by BCC 2015-04-08 16:41 ` MFLD @ 2015-04-08 16:45 ` Jody Bruchon 2015-04-09 8:31 ` Marc-François LUCCA-DANIAU 0 siblings, 1 reply; 6+ messages in thread From: Jody Bruchon @ 2015-04-08 16:45 UTC (permalink / raw) To: ELKS 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on import symbols generated by BCC 2015-04-08 16:45 ` Jody Bruchon @ 2015-04-09 8:31 ` Marc-François LUCCA-DANIAU 2015-04-09 10:43 ` Jody Bruchon 0 siblings, 1 reply; 6+ messages in thread From: Marc-François LUCCA-DANIAU @ 2015-04-09 8:31 UTC (permalink / raw) To: Jody Bruchon; +Cc: ELKS 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on import symbols generated by BCC 2015-04-09 8:31 ` Marc-François LUCCA-DANIAU @ 2015-04-09 10:43 ` Jody Bruchon 0 siblings, 0 replies; 6+ messages in thread From: Jody Bruchon @ 2015-04-09 10:43 UTC (permalink / raw) To: ELKS 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <55294997.3090501@gmail.com>]
* Re: Question on import symbols generated by BCC [not found] <55294997.3090501@gmail.com> @ 2015-04-11 19:42 ` MFLD 0 siblings, 0 replies; 6+ messages in thread From: MFLD @ 2015-04-11 19:42 UTC (permalink / raw) To: ELKS -------- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-04-11 19:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <551595A4.7040206@gmail.com>
2015-03-27 17:55 ` Question on import symbols generated by BCC MFLD
2015-04-08 16:41 ` MFLD
2015-04-08 16:45 ` Jody Bruchon
2015-04-09 8:31 ` Marc-François LUCCA-DANIAU
2015-04-09 10:43 ` Jody Bruchon
[not found] <55294997.3090501@gmail.com>
2015-04-11 19:42 ` MFLD
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox