public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Subject: [PATCH 5/6] gas: avoid bignum related errors when processing .linefile
Date: Fri, 6 May 2022 08:08:02 +0200	[thread overview]
Message-ID: <84dddbf5-abcc-6e02-d64b-ad641a6ee300@suse.com> (raw)
In-Reply-To: <e96f677b-acf7-e5a9-e99e-48ae61a20da8@suse.com>

Any construct which to the scrubber looks like a C preprocessor
line/file "directive" is converted to .linefile, but the amount of
checking the scrubber does is minimal (albeit it does let through only
decimal digits for the line part of the contruct). Since the scrubber
conversion is further tied to # being a line comment character, anything
which upon closer inspection turns out not to be a line/file "directive"
is supposed to be treated as a comment, i.e. ignored. Therefore we
cannot use get_absolute_expression(), as this may raise errors. Open-
code the function instead, treating everything not resulting in
O_constant as a comment as well.

Furthermore also bounds-check the parsed value. This bounds check tries
to avoid implementation defined behavior (which may be the raising of an
implementation defined signal), but for now makes the assumption that
int has less than 64 bits. The way bfd_signed_vma (which is what offsetT
aliases) is defined in bfd.h for the BFD64 case I cannot really see a
clean way of avoiding this assumption. Omitting the #ifdef, otoh, would
risk "condition is always false" warnings by compilers.

Convert get_linefile_number() to return bool at this occasion as well.

--- a/gas/read.c
+++ b/gas/read.c
@@ -2037,17 +2037,28 @@ s_file (int ignore ATTRIBUTE_UNUSED)
     }
 }
 
-static int
+static bool
 get_linefile_number (int *flag)
 {
+  expressionS exp;
+
   SKIP_WHITESPACE ();
 
   if (*input_line_pointer < '0' || *input_line_pointer > '9')
-    return 0;
+    return false;
 
-  *flag = get_absolute_expression ();
+  expression_and_evaluate (&exp);
+  if (exp.X_op != O_constant)
+    return false;
 
-  return 1;
+#if defined (BFD64) || LONG_MAX > INT_MAX
+  if (exp.X_add_number < INT_MIN || exp.X_add_number > INT_MAX)
+    return false;
+#endif
+
+  *flag = exp.X_add_number;
+
+  return true;
 }
 
 /* Handle the .linefile pseudo-op.  This is automatically generated by
--- a/gas/testsuite/gas/all/gas.exp
+++ b/gas/testsuite/gas/all/gas.exp
@@ -465,6 +465,8 @@ run_dump_test quoted-sym-names
 # "# <line> <file>" into .linefile (PR gas/29120).
 setup_xfail "tic30-*-*"
 run_list_test cond-2 "-al"
+setup_xfail "tic30-*-*"
+run_list_test linefile ""
 
 run_list_test macro "-alm"
 
--- /dev/null
+++ b/gas/testsuite/gas/all/linefile.l
@@ -0,0 +1,5 @@
+# This should match the output of gas linefile.s.
+.*linefile\.s: Assembler messages:
+.*linefile\.s:2: Warning: line 2
+.*linefile\.s:5: Warning: line 5
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/all/linefile.s
@@ -0,0 +1,5 @@
+# 12345678900 "LineFile.s"
+	.warning "line 2"
+
+# 123456789123456789123456789 "LINEfile.s"
+	.warning "line 5"


  parent reply	other threads:[~2022-05-06  6:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06  6:04 [PATCH 0/6] gas: (mostly) further file/line handling adjustments Jan Beulich
2022-05-06  6:05 ` [PATCH 1/6] gas: tweak .irp and alike file/line handling for M68K/MRI Jan Beulich
2022-05-06  6:06 ` [PATCH 2/6] gas: simplify ignore_input() Jan Beulich
2022-05-06  6:06 ` [PATCH 3/6] gas: don't ignore .linefile inside false conditionals Jan Beulich
2022-05-06  6:07 ` [PATCH 4/6] gas: fold do_repeat{,_with_expander}() Jan Beulich
2022-05-06  6:08 ` Jan Beulich [this message]
2022-05-06  6:08 ` [PATCH 6/6] gas: avoid octal numbers being accepted when processing .linefile 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=84dddbf5-abcc-6e02-d64b-ad641a6ee300@suse.com \
    --to=jbeulich@suse.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).