linux-8086.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: MFLD <mfld.fr@gmail.com>
To: ELKS <Linux-8086@Vger.Kernel.Org>
Subject: Re: Question on import symbols generated by BCC
Date: Sat, 11 Apr 2015 21:42:34 +0200	[thread overview]
Message-ID: <5529792A.3070600@gmail.com> (raw)
In-Reply-To: <55294997.3090501@gmail.com>


-------- 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

       reply	other threads:[~2015-04-11 19:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <55294997.3090501@gmail.com>
2015-04-11 19:42 ` MFLD [this message]
     [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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5529792A.3070600@gmail.com \
    --to=mfld.fr@gmail.com \
    --cc=Linux-8086@Vger.Kernel.Org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).