public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: binutils@sourceware.org
Subject: Re: [Bug] DWARF-5 section names in PE/PEP and weak symbols
Date: Mon, 20 Dec 2021 20:45:04 +0100	[thread overview]
Message-ID: <8735mn5adb.fsf@Rainer.invalid> (raw)
In-Reply-To: <b51431d6-eaf3-552c-3ceb-e8ee3fe1540f@redhat.com> (Nick Clifton via Binutils's message of "Wed, 15 Dec 2021 13:12:32 +0000")

Nick Clifton via Binutils writes:
>   Please could you file a bug report for this problem here:

https://sourceware.org/bugzilla/show_bug.cgi?id=28719

> So you are saying that because the linker script now includes specific
> references to DWARF-5 debug sections, the fputs symbol is being pulled
> in to the link from the cygwin1.dll and hence it is no longer undefined ?
> That seems to be most strange.

It is much more strange: looking at the working and non-working version
(going from 2.36 to 2.37) with objdump, everything but the debug section
(differently named and now at the beginning of the object file instead
of the end), there is absolutely no other difference in the other
sections that I've been able to find.

> Hmm, I suppose that the location lists will refer to real locations in
> the code space, and so including the debug information could also pull
> in the code itself.  But really you would only want to have the debug
> information for code that is already part of the final link.  So maybe
> the underlying problem is that the debug information has not been pruned
> to match discarded code.

I have no idea where and what to look for.

> Quick question - if instead of deleting the references to the .debug_loclists
> section you move them into the /DISCARD/ section earlier in the pe.se file,
> does this also solve the problem.  (The point being that if the script
> explitcitly discards this information we also have room to add a comment
> explaining why.  Plus it will prevent future changes to the pe.sc file
> from adding the section back in).  (Also the change would be needed in
> the pep.sc file as well, obviously.  Plus the .zdebug_loclists section
> would need similar treatment).

How do I do that (and no, I'll not be able to check until the beginning
of next year).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

  reply	other threads:[~2021-12-20 19:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08 18:27 Achim Gratz
2021-12-15 13:12 ` Nick Clifton
2021-12-20 19:45   ` Achim Gratz [this message]
2022-01-23  8:10     ` Achim Gratz
2022-01-29  7:57   ` Achim Gratz
2022-02-13 20:17   ` Achim Gratz
2022-02-14 11:02     ` ASSI
2022-02-15 17:58       ` Achim Gratz
2022-02-15 19:08         ` Achim Gratz
2022-02-15 20:19         ` Achim Gratz

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=8735mn5adb.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --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).