public inbox for
 help / color / mirror / Atom feed
From: Tom Tromey <>
To: Simon Marchi <>
Cc: Tom Tromey <>,
Subject: Re: [PATCH 2/6] Set section indices when symbols are made
Date: Wed, 18 Jan 2023 15:00:07 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Simon Marchi's message of "Wed, 18 Jan 2023 16:43:24 -0500")

>>>>> "Simon" == Simon Marchi <> writes:

Simon> On 1/18/23 10:30, Tom Tromey via Gdb-patches wrote:
>> Most places in gdb that create a new symbol will apply a section
>> offset to the address.  It seems to me that the choice of offset here
>> is also an implicit choice of the section.  This is particularly true
>> if you examine fixup_section, which notes that it must be called
>> before such offsets are applied -- meaning that if any such call has
>> an effect, it's purely by accident.
>> This patch cleans up this area by tracking the section index and
>> applying it to a symbol when the address is set.  This is done for
>> nearly every case -- the remaining cases will be handled in later
>> patches.

Simon> So, if I rephrase it to make sure I understand: it's not logical to
Simon> apply the relocation to the symbol's address, without also setting the
Simon> symbol's section index, because the symbol's relocation value comes from
Simon> the section.  Does that sound right?

Yes, that's right.

Hypothetically, if you had a runtime linker that applied different
offsets to different sections (like, text gets +0x1000, data gets
+0x2000, bss gets +0x3000), then the code that applies these offsets
could sometimes be wrong.  But, since it's been this way a long time
and, AFAIK, there aren't problems with it, then IMO it follows that
setting the section from these choices is fine.

One other oddity I found here is that I don't think any code uses
anything other than SECT_OFF_TEXT for functions.  So maybe the code to
deal with the section index in a compunit symtab is not actually needed.


  reply	other threads:[~2023-01-18 22:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18 15:30 [PATCH 0/6] Change how symbol section indices are set Tom Tromey
2023-01-18 15:30 ` [PATCH 1/6] Use default section indexes in fixup_symbol_section Tom Tromey
2023-01-18 17:19   ` Simon Marchi
2023-01-18 19:13     ` Tom Tromey
2023-01-18 15:30 ` [PATCH 2/6] Set section indices when symbols are made Tom Tromey
2023-01-18 21:43   ` Simon Marchi
2023-01-18 22:00     ` Tom Tromey [this message]
2023-01-18 15:30 ` [PATCH 3/6] Pass section index to start_compunit_symtab Tom Tromey
2023-01-18 21:55   ` Simon Marchi
2023-01-18 22:02     ` Tom Tromey
2023-01-18 22:06       ` Simon Marchi
2023-01-19 13:36         ` Tom Tromey
2023-02-08 16:28           ` Tom Tromey
2023-01-18 15:30 ` [PATCH 4/6] Set section index when setting a symbol's block Tom Tromey
2023-01-18 15:30 ` [PATCH 5/6] Remove most calls to fixup_symbol_section Tom Tromey
2023-01-18 15:30 ` [PATCH 6/6] Merge fixup_section and fixup_symbol_section Tom Tromey
2023-02-08 16:28 ` [PATCH 0/6] Change how symbol section indices are set Tom Tromey

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:

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

  git send-email \ \ \ \ \

* 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).