Skip to contentSkip to conversation

Question on import symbols generated by BCC

DISCUSSION MFLD 2 participants 5 messages Mar 27, 2015 – Apr 9, 2015 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

MFLD

author
#1 lore raw

Hello,

Quoted 77 lines

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

author
#2 lore raw

Hello,

No reply to this one... should I submit that case to another mailing list ?

Regards,

MFLD

Quoted 78 lines · MFLD

Hello,

Quoted 77 lines

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

#3 lore raw

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.

Quoted 108 lines · MFLD

Hello,

No reply to this one... should I submit that case to another mailing list ?

Regards,

MFLD

Quoted 6 lines · MFLD

Hello,

Quoted 5 lines

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

Quoted 72 lines
Quoted 72 lines

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

Quoted 1 line
Quoted 1 line

This time, in the symbol table, the public & import symbol _entry

has

Quoted 11 lines
Quoted 11 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
#4 lore raw

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 <[email protected]>:

Quoted 118 lines

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.

Quoted 101 lines · MFLD

Hello,

No reply to this one... should I submit that case to another mailing list ?

Regards,

MFLD

Quoted 6 lines · MFLD

Hello,

Quoted 5 lines

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

Quoted 72 lines
Quoted 72 lines

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

Quoted 1 line
Quoted 1 line

This time, in the symbol table, the public & import symbol _entry

has

Quoted 9 lines
Quoted 9 lines

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,

Quoted 7 lines
Quoted 1 line
Quoted 1 line

could I name it "boot86" :-) ?

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw
Quoted 5 lines · 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 ?

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html