public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Stephen Casner <casner@acm.org>
To: binutils@sourceware.org
Subject: References to linker script symbols become undefined
Date: Sun, 12 Apr 2020 16:34:07 -0700 (PDT)	[thread overview]
Message-ID: <alpine.OSX.2.21.9999.2004121556020.80412@auge.attlocal.net> (raw)

I'd appreciate some pointers from any ld/bfd experts reading this
list.  I'm would like to fix the several unexpected failures that
occur when running ld testsuite for the pdp11-aout target.  I have
learned that these unexpected failures have been unattended for a long
time.

Some of the test failures can be fixed easily, but there are several
caused by a problem that appears to be a real bug for the pdp11-aout
target: when an assembler source file references a symbol defined in a
linker script, that symbol is marked as undefined in the output file.
This is true for both absolute symbols and symbols relocated to any of
the text, data or bss output sections.

For example, the default linker script ld/ldscripts/pdp11.x defines
several symbols including _etext, _edata, _end.  Those symbols are
listed in the symbol table with their correct values.  However, if the
source file references any of them they become undefined while any
that are not referenced are still defined as before.

I don't know my way around the ld/bfd source well enough to know where
the resolution of these symbols should be done, so I'd appreciate some
pointers.  I'd be happy to RTFM if there is one (an internals doc like
the one for gcc?) or to UTSL if you can help narrow down the set of
files.  Suggestions for debugging techniques (debug or trace options?)
would also be helpful.  Thanks.

                                                        -- Steve

             reply	other threads:[~2020-04-12 23:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-12 23:34 Stephen Casner [this message]
2020-04-15  6:48 ` Stephen Casner

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=alpine.OSX.2.21.9999.2004121556020.80412@auge.attlocal.net \
    --to=casner@acm.org \
    --cc=binutils@sourceware.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).