From: Alan Modra <amodra@gmail.com>
To: binutils@sourceware.org
Subject: setup_archive parameter mismatch
Date: Thu, 19 Mar 2020 13:55:37 +1030 [thread overview]
Message-ID: <20200319032537.GA4583@bubble.grove.modra.org> (raw)
readelf.c and elfedit.c both define BFD64 in order to support
processing of ELFCLASS64 objects. Or at least that's what the comment
says. This means I should not have used bfd_size_type to pass file
size to a function in elfcomm.c which also includes bfd.h but doesn't
define BFD64. When you build and test on a 64-bit host, the parameter
mismatch doesn't show up, but it does if bfd/ is compiled on a 32-bit
host without 64-bit BFD support.
* elfcomm.c (setup_archive): Make file_size an off_t. Comment.
* elfcomm.h (setup_archive): Update prototype.
diff --git a/binutils/elfcomm.c b/binutils/elfcomm.c
index e5c6a32c6d..b0fbf57e1f 100644
--- a/binutils/elfcomm.c
+++ b/binutils/elfcomm.c
@@ -21,6 +21,11 @@
Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
02110-1301, USA. */
+/* Do not use BFD types in this file that differ in size depending on
+ whether BFD64 is defined. Functions in this file are used by
+ readelf.c and elfedit.c which define BFD64, and by objdump.c which
+ doesn't. */
+
#include "sysdep.h"
#include "libiberty.h"
#include "filenames.h"
@@ -607,7 +612,7 @@ process_archive_index_and_symbols (struct archive_info * arch,
int
setup_archive (struct archive_info *arch, const char *file_name,
- FILE *file, bfd_size_type file_size,
+ FILE *file, off_t file_size,
bfd_boolean is_thin_archive, bfd_boolean read_symbols)
{
size_t got;
@@ -671,7 +676,7 @@ setup_archive (struct archive_info *arch, const char *file_name,
return 1;
}
/* PR 17531: file: 639d6a26. */
- if (arch->longnames_size > file_size
+ if ((off_t) arch->longnames_size > file_size
|| (signed long) arch->longnames_size < 0)
{
error (_("%s: long name table is too big, (size = 0x%lx)\n"),
diff --git a/binutils/elfcomm.h b/binutils/elfcomm.h
index 731d3dbd34..8d962f2731 100644
--- a/binutils/elfcomm.h
+++ b/binutils/elfcomm.h
@@ -74,7 +74,7 @@ extern char *adjust_relative_path (const char *, const char *, unsigned long);
/* Read the symbol table and long-name table from an archive. */
extern int setup_archive (struct archive_info *, const char *, FILE *,
- bfd_size_type, bfd_boolean, bfd_boolean);
+ off_t, bfd_boolean, bfd_boolean);
/* Open and setup a nested archive, if not already open. */
extern int setup_nested_archive (struct archive_info *, const char *);
--
Alan Modra
Australia Development Lab, IBM
next reply other threads:[~2020-03-19 3:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 3:25 Alan Modra [this message]
2020-03-19 5:40 ` Alan Modra
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=20200319032537.GA4583@bubble.grove.modra.org \
--to=amodra@gmail.com \
--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).