public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@gmx.de>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org, nickc@redhat.com
Subject: Re: [PATCH v3 0/2] Fix several mix up between octets and bytes in ELF program headers
Date: Sat, 07 Mar 2020 22:05:23 +0100	[thread overview]
Message-ID: <2565487.qrDekGRkqd@zbook-opensuse.wgnetz.xx> (raw)
In-Reply-To: <20200227083541.GI32593@bubble.grove.modra.org>

Am Donnerstag, 27. Februar 2020, 09:35:41 CET schrieb Alan Modra:
> Symbols are a real problem, not because of some implementation detail,
> but because you don't know the units of st_value.  A symbol defined as
> a label on a line of assembly holds an address, but for example a
> symbol defined by
>   sym = 123
> could be a size in octets, an address, or just a plain number.
Maybe this is not the main problem (at least for SDMA). All "plain" numbers in
assembler are most likely bytes. If somebody requires octets in future, a new
".octet <sym>" directive might help...

> I think that if you decide that symbol values should always be octets,
> then you'll eventually come to the conclusion that addresses in the
> assembler need to be octets too.
I've made a short try to store st_value and .debug_line statements in octets.
For this experiment I simply multiplied st_value by 2 in the swap_in and
swap_out functions. While this worked quite well (as all "octet" symbols had a
value of 0), making this change for debug information ended in finally giving
up. It started harmless with expressions which became fixes. But then some of
them became relocations where it is difficult/impossible to know which ones
have to be shifted and which ones not...

> And then it's just easier to dispense with octets_per_byte.
Tried to translate the outcome from German into English: Hindsight is easier
than foresight.

When I started with SDMA, I already had a presentiment that support for
octets_per_byte might be incomplete for ELF/DWARF. But I liked the possibility
of having correct addresses in assembler code and in objdump output and I
didn't want to use the obsolete coff/stabs format.

I suspect that using octets_per_byte=1 for SDMA would complicate things for
the user and additionally would set back my SDMA port by several months (maybe
that I will be unable to complete it in this case).

> So if you're going to keep octets per byte of 2, I wouldn't be trying
> to convert any symbol values.
As I don't want to add further complexity to this, I would like to keep
st_value, r_addend and r_offset like it is for now.


If you are ok with my latest patches, I would like send the first version of
the SDMA port. After working countless weekends on my first binutils port,
it's time to finish...

Regards
Christian




  reply	other threads:[~2020-03-07 21:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-15 19:37 Christian Eggers
2020-02-16  8:22 ` Christian Eggers
2020-02-16 19:37   ` Christian Eggers
2020-02-20  1:30     ` Alan Modra
2020-02-22 16:32       ` Christian Eggers
2020-02-22 21:08       ` Christian Eggers
2020-02-23  9:07       ` Christian Eggers
2020-02-27  8:35         ` Alan Modra
2020-03-07 21:05           ` Christian Eggers [this message]
2020-02-23 18:35       ` Christian Eggers

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=2565487.qrDekGRkqd@zbook-opensuse.wgnetz.xx \
    --to=ceggers@gmx.de \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    /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).