Summary: | Failed compilation at bfin-parse.c | ||
---|---|---|---|
Product: | binutils | Reporter: | Liran Nuna <LiraNuna> |
Component: | gas | Assignee: | unassigned |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | bug-binutils, vapier |
Priority: | P2 | ||
Version: | 2.19 | ||
Target Milestone: | --- | ||
Host: | x86_64-unknown-linux-gnu | Target: | bfin-unknown-elf |
Build: | x86_64-unknown-linux-gnu | Last reconfirmed: |
Subject: Bug 10143 CVSROOT: /cvs/src Module name: src Changes by: nickc@sourceware.org 2009-05-26 15:35:37 Modified files: gas : ChangeLog gas/config : bfin-parse.y Log message: PR 10143 * config/bfin-parse.y (error): Use "%s" as format string for error message. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src&r1=1.3814&r2=1.3815 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/config/bfin-parse.y.diff?cvsroot=src&r1=1.20&r2=1.21 Hi Liran, Thanks for reporting this problem. The change you suggest is slightly wrong in that it fixes the generated file bfin-parse.c which is built from the source file gas/config/bfin-parse.y, but apart from that it works. So I have applied your patch to the bfin-parse.y file and checked it in with this changelog entry. Cheers Nick gas/ChangeLog PR 10143 * config/bfin-parse.y (error): Use "%s" as format string for error message. was there a reason for also changing the error buffer from the stack to static ? adding the printf string "%s" makes sense, but it doesnt seem like it needs a static keyword added ... Hi Mike,
> was there a reason for also changing the error buffer from the stack to static ?
>
> adding the printf string "%s" makes sense, but it doesnt seem like it needs a
> static keyword added ...
It is an old habit from my embedded programming days. Creating a large local
buffer uses up a lot of stack space and it can even prevent the program from
working if stack space is very tight. Making the buffer static does not affect
the execution of the program (apart from increasing its data space requirement)
and it can allow the program to continue working.
In this particular case however I agree that is very unlikely that this change
is going to make any real difference. If you really want I will revert it.
Cheers
Nick
if the assembler ran on the embedded target, this may make sense, but i doubt these limitations are ever going to crop up on todays desktop systems (where the assembler is running). i'd bet there are plenty of places in binutils where much larger buffers are on the stack. i wouldnt go through the effort of reverting it since it isnt a big deal (increases .bss a bit) ... i just wanted to know the logic behind the change. The master branch has been updated by Michael Frysinger <vapier@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=43fa85d9a8d7aac7a70c72220abd09d39703208a commit 43fa85d9a8d7aac7a70c72220abd09d39703208a Author: Mike Frysinger <vapier@gentoo.org> Date: Sun Mar 8 23:53:48 2015 -0400 sim: bfin: fix up linux-fixed-code.h generation [PR sim/10143] The use of $< ends up picking the wrong object out of the depend list. Specify the input name directly to avoid fragility. On BSD systems, we need to make sure all options come before the non-options (i.e. the files). Reported-by: Chris Johns <chrisj@rtems.org> URL: https://sourceware.org/bugzilla/show_bug.cgi?id=13160 |
binutils will fail to compile for triplet bfin-unknown-elf (or just bfin-elf for short) because gas is compiled with -Werror and a warning in the code. A diff to fix the problem: (file ./binutils-2.19.51/gas/bfin-parse.c) 565c565 < as_bad (buffer); --- > as_bad ("%s", buffer);