From: Mark Harmstone <mark@harmstone.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] ld: Fix segfault in populate_publics_stream
Date: Mon, 28 Nov 2022 17:53:15 +0000 [thread overview]
Message-ID: <09f9d8ae-4dee-e056-6f7b-e70542097ffd@harmstone.com> (raw)
In-Reply-To: <992f7462-5544-39fd-507c-bfeabf708db8@suse.com>
> Out of curiosity - which tree was this diff generated against? The
> line number here looks to be off by several hundred from what I
> see in the repo right now.
This is inteded to be applied with the other patches in the series, the ones
beginning with "[PATCH v2] ld: Generate PDB string table" at
https://sourceware.org/pipermail/binutils/2022-November/thread.html.
Sorry, this probably wasn't obvious from a mail client. I've not numbered
them as I'm not sure how many more there'll be, and if I wait for the previous
patches to be accepted before submitting the next, I'll almost certainly miss
the cut-off for the code freeze.
> Why / when would in->outsymbols be NULL but in->symcount be non-zero?
Try running the test in the DEBUG_S_LINES patch without this one - it'll fail
because ld segfaults. outsymbols doesn't get set from within generate_reloc
for the second object file, as it only has one non-loadable section. The
"symbols" come from the .equs I'm using like #defines.
> And if that was possible, why would it not also be possible that the
> array is smaller than in->symcount?
bfd_generic_link_read_symbols is called for each loadable section, and
allocates the outsymbols array once. It was my mistake when I submitted my
original patch for populate_publics_stream, in not realizing that it would
break for object files without any loadable sections.
Mark
next prev parent reply other threads:[~2022-11-28 17:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-25 2:53 [PATCH v2] ld: Generate PDB string table Mark Harmstone
2022-11-25 2:54 ` [PATCH] ld: Write DEBUG_S_FILECHKSMS entries in PDBs Mark Harmstone
2022-11-27 2:38 ` [PATCH] ld: Fix segfault in populate_publics_stream Mark Harmstone
2022-11-27 2:38 ` [PATCH] ld: Write DEBUG_S_LINES entries in PDB file Mark Harmstone
2022-11-29 0:10 ` [PATCH] ld: Write types into TPI stream of PDB Mark Harmstone
2022-11-29 0:10 ` [PATCH] ld: Write types into IPI " Mark Harmstone
2022-11-29 0:10 ` [PATCH] ld: Parse LF_UDT_SRC_LINE records when creating PDB file Mark Harmstone
2022-12-05 1:53 ` [PATCH] ld: Write globals stream in PDB Mark Harmstone
2022-12-05 1:53 ` [PATCH] ld: Copy other symbols into PDB file Mark Harmstone
2022-12-05 1:53 ` [PATCH] ld: Write linker symbols in PDB Mark Harmstone
2022-12-06 17:07 ` [PATCH] ld: Write globals stream " Nick Clifton
2022-12-06 17:52 ` Mark Harmstone
2022-12-08 11:00 ` Nick Clifton
2022-12-09 1:11 ` Mark Harmstone
2022-11-28 14:54 ` [PATCH] ld: Fix segfault in populate_publics_stream Jan Beulich
2022-11-28 17:53 ` Mark Harmstone [this message]
2022-11-29 9:00 ` Jan Beulich
2022-11-29 17:47 ` Mark Harmstone
2022-11-30 7:00 ` Jan Beulich
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=09f9d8ae-4dee-e056-6f7b-e70542097ffd@harmstone.com \
--to=mark@harmstone.com \
--cc=binutils@sourceware.org \
--cc=jbeulich@suse.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).