[Bug ld/30354] Debug info is lost for functions only called from functions marked with cmse_nonsecure_entry

2023-05-03 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30354

--- Comment #6 from Hans-Peter Nilsson  ---
(In reply to Torbjörn SVENSSON from comment #5)
> I don't know if there has been any other cleanup lately in ld, but it looks
> like the elf size is much smaller with ld from master than
> 5c0b4ee406035917d0e50aa138194fab57ae6bf8 that was used in the Arm GCC
> 11.3.rel1 release. Is it expected that the elf size for the demo application
> would drop from ~203kB to ~31kB? Note that the size of text and data
> sections are still the same.

Perhaps it's 1a26a53a0dee.  You're welcome. :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages

2023-01-23 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30033

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC|hp at bitrange dot com |

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/30033] binutils-2.40 broke arm-linux-gnueabi libraries on arm64 kernel with >4KB pages

2023-01-23 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=30033

--- Comment #2 from Hans-Peter Nilsson  ---
An "armhf" userspace on a "arm64" kernel with non-4KiB pagesize is an odd
beast, odd enough that it's hidden behind EXPERT settings when building the
kernel and warnings about having to rebuild tools.

Quoting linux/arch/arm64/Kconfig as of c8451c141e07:

menuconfig COMPAT
bool "Kernel support for 32-bit EL0"
depends on ARM64_4K_PAGES || EXPERT
select HAVE_UID16
select OLD_SIGSUSPEND3
select COMPAT_OLD_SIGACTION
help
  This option enables support for a 32-bit EL0 running under a 64-bit
  kernel at EL1. AArch32-specific components such as system calls,
  the user helper functions, VFP support and the ptrace interface are
  handled appropriately by the kernel.

  If you use a page size other than 4KB (i.e, 16KB or 64KB), please be
aware
  that you will only be able to execute AArch32 binaries that were
compiled
  with page size aligned segments.

  If you want to execute 32-bit userspace applications, say Y.


Is this non-4KiB page-size + armhf userspace part of an easily accessible
distribution?  Please tell more.

It's a judgement call; you can't have it all with the default build.  I
mentioned that this setup would break, but my argument was and is also, that
such a setup is odd enough, that people with it have to build tools specially,
or use special options like ld -z max-page-size=0x1, rather than bloating
for everyone else.  See the mailing list discussion at the time.

Are there reasons to reconsider this setup any more common than as portrayed;
an odd corner-case where users are developers ready to patch and build tools
themselves?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/28824] relro security issues

2023-01-21 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=28824

--- Comment #16 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #15)
> that may be the most pragmatic solution for aarch64.

Correction: for *all* architectures that need to support large-enough
page-sizes.
Perhaps a per-target hook, that returns whether to add another program header,
or do it by padding.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/28824] relro security issues

2023-01-21 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=28824

--- Comment #15 from Hans-Peter Nilsson  ---
(In reply to Rui Ueyama from comment #12)
> In the mold linker, we are dealing with the issue by mapping the page that
> is at the boundary of relro and non-relro twice as the last relro page and
> the first non-relro page.

IOW, an additional LOAD program-header.  I too have thought of that.  That that
may be the most pragmatic solution for aarch64.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/29956] mn10300 linker always triggers LOAD segment with RWX permissions test by default

2023-01-03 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=29956

--- Comment #4 from Hans-Peter Nilsson  ---
A maintainer can make the call to add such targets to the clause at
ld/configure.tgt line 48.  Just don't forget to add the bare-metal specifier
(e.g. *-elf) there, for targets where a variant also has with
HW-protection-support, so not to match e.g. *-linux.  To wit, don't follow the
bad pattern of target-*-* there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/15869] nm --size-sort test fails for alpha-unknown-linux-gnuecoff

2022-11-24 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=15869

--- Comment #2 from Hans-Peter Nilsson  ---
(In reply to Alan Modra from comment #1)
> nm --size-sort works here.

The other nm.exp tests mentioned in the report still fail at f9e2163a3e48
though:

Running /x/src/binutils/testsuite/binutils-all/nm.exp ...
Version /x/b/binutils/nm-new 2.39.50.20221124
FAIL: nm (no arguments)
FAIL: nm -P

But, since I only mentioned --size-sort in the title, I guess closing is fair
enough.  ...I see from git history around the time (2013) that this was indeed
my focus.  Leaving the updated observation here for posterity.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/29263] /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack

2022-06-20 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=29263

--- Comment #5 from Hans-Peter Nilsson  ---
But I should add: I'd suggest to inspect whatever goes on with the linker
script; a "hosted" target reasonably shouldn't get data and code segments
mixed.  Maybe there's something to adjust there to make the warning go away for
the "right" reason.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/29263] /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack

2022-06-20 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=29263

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to dave.anglin from comment #3)

> dave@mx3210:~/shmat$ gcc main.c -Wl,--no-warn-execstack
> /usr/bin/ld: warning: a.out has a LOAD segment with RWX permissions

That's a different warning altogether, unfortunately easy to conflate with the
executable-stack thing.  See commit 45beb34c7dcf
for the simplest way to disable it for your target.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gprofng/29113] Build error for x86_64-w64-mingw32 host since CLOCK_MONOTONIC does not exist

2022-05-03 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=29113

--- Comment #6 from Hans-Peter Nilsson  ---
(In reply to Vladimir Mezentsev from comment #2)
>  How do you configure your build ?
> 
> gprofng should not be built for x86_64-w64-mingw32.
> Only these platforms are supported:
> 
> % cat gprofng/configure.ac
> ...
>   case "${target}" in
> x86_64-*-linux*)
>   build_src=true
>   build_collector=true
>   ;;
> i?86-*-linux*)
>   build_collector=true
>   build_collector=true
>   ;;
> aarch64-*-linux*)
>   build_src=true
>   build_collector=true
>   ;;
>   esac

Surely unrelated, but what's the effect of the apparent typo in the
"i?86-*-linux*)" case?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28602] binutils/testsuite/lib/binutils-common.exp: Support free-form shell commands and check patterns

2021-11-18 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=28602

--- Comment #2 from Hans-Peter Nilsson  ---
(In reply to Fangrui Song from comment #0)
> 3) Can we allow free-form shell commands instead of specialized directives?
> 
> It is mythical what can and what can't be used in `#foo:`.
> OK, a user can figure out this with trial and error.

"Users" are here programmers, which are expected to be able to find the "myth"
in binutils-common.exp and read the head comment, maybe find a flaw or extend
it.  The method to accomplish this isn't really different to most other
programming-related problems.  The difference is mostly that the testsuite for
the tools isn't as documented as the tools themselves, just as can be expected.

> If we allow free-form shell commands and use line prefixes to differentiate
> the two output streams (objdump -d output and ld -Map output):
> 
>## Test local ifunc are dumped in the link map.
>#RUN: ld: -shared -Map tmpdir/ifunc-1-x86.map --hash-style=sysv %s -o %t
>#RUN: objdump -dw %t | check  # by default, CHECK is the prefix
>#RUN: cat tmpdir/ifunc-1-x86.map | check MAP
> 
>#CHECK: [ \t0-9a-f]+:[ \t0-9a-f]+call[
> \t0-9a-fq]+<\*ABS\*(\+0x[0-9a-f]+|)@plt>
>#CHECK-N: if there is a next line
>#CHECK-N: likewise.
>#CHECK:   skip arbitrary lines
>#CHECK-N: if there is a next line
> 
>#MAP: Local IFUNC function ...

Maybe this suggestion can fit run_dump_test but with the splitting-thing it
evolves into a whole different kind of beast.  That sounds like this should be
a different "proc" (with a different suffix).

Something reading from a descriptive file in a manner *similar* to
run_dump_test may be useful.  I just don't believe bolting stuff onto
run_dump_test is the preferred method.

People needing new features for new tests not simply matched by run_dump_test,
or need to run random shell commands, usually write inline dejagnu-tcl in an
existing or new .exp, usually for the purpose of a single test or array of
similar tests.  There's no myth or magic here - at least not of a form
different to the kind of programming performed on the actual tools!

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/27845] readelf crashes: heap-buffer-overflow

2021-05-11 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=27845

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to cvs-com...@gcc.gnu.org from comment #1)
> commit f2f9554bf0d15a5b93289ebfef7e04d0aeb51a60


If this is backported to any branch, please also backport d30182b51edd0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26589] ld segfaulting building uClibc-ng 1.0.35 for crisv32-linux

2020-12-03 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26589

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Target Milestone|2.36|2.35.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26589] ld segfaulting building uClibc-ng 1.0.35 for crisv32-linux

2020-09-14 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26589

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Hans-Peter Nilsson  ---
Regarding the milestone set for 2.36 while the patch is on the 2.35 branch, it
looks like we don't have a milestone label for 2.35.1, but from recent traffic
it seems likely that there will be one.

Anyhow, thanks for your perseverance; the bug is now fixed.  It'd be nice to
know if your build completes and is not hampered by other bugs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26589] ld segfaulting building uClibc-ng 1.0.35 for crisv32-linux

2020-09-14 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26589

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |hp at sourceware dot org
 Target|crisv32-linux   |crisv32-linux, cris-linux
   Target Milestone|--- |2.36

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26589] ld segfaulting building uClibc-ng 1.0.35 for crisv32-linux

2020-09-10 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26589

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to wbx from comment #3)
> Created attachment 12828 [details]
> gcc -v

Thanks, I'll have a look in a day or two.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26589] ld segfaulting building uClibc-ng 1.0.35 for crisv32-linux

2020-09-08 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26589

--- Comment #2 from Hans-Peter Nilsson  ---
(In reply to wbx from comment #0)
>  /home/wbx/openadk/toolchain_qemu-cris_uclibc-ng_crisv32/usr/bin/crisv32-
> openadk-linux-uclibc-gcc  -Wl,-EL -Wl,-mcrislinux -shared -Wl,--warn-common
> -Wl,--warn-once -Wl,-z,combreloc -Wl,-O2 -Wl,-z,defs
> -L/home/wbx/openadk/target_qemu-cris_uclibc-ng_crisv32/lib
> -L/home/wbx/openadk/target_qemu-cris_uclibc-ng_crisv32/usr/lib -Wl,-O1
> -Wl,-rpath -Wl,/usr/lib -Wl,-rpath-link
> -Wl,/home/wbx/openadk/target_qemu-cris_uclibc-ng_crisv32/usr/lib -mcpu=v32
> -Wl,-e,_start -Wl,-z,now -Wl,-Bsymbolic -Wl,--export-dynamic
> -Wl,--sort-common -Wl,--no-undefined -Wl,--discard-locals -Wl,--discard-all 
> -Wl,-soname=ld-uClibc.so.1 -nostdlib -nostartfiles -o
> lib/ld-uClibc-1.0.35.so  -Wl,--whole-archive ldso/ldso/ld-uClibc_so.a
> -Wl,--no-whole-archive 
> /home/wbx/openadk/toolchain_qemu-cris_uclibc-ng_crisv32/usr/lib/gcc/crisv32-
> openadk-linux-uclibc/8.4.0/libgcc.a
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
> compilation terminated.

Thanks.  I see the *gcc* command-line.  Can you please add the option "-v" to
that command-line, run it and paste the output here?  That option will make gcc
output the *linker* command line.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25331] mmix-gas fails to assemble newlib-3.1.0: internal error: fixup not contained within frag

2020-06-29 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25331

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Target Milestone|--- |2.35
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Hans-Peter Nilsson  ---
Now (after a bugzilla restart), with actions to match that previous comment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25331] mmix-gas fails to assemble newlib-3.1.0: internal error: fixup not contained within frag

2020-06-28 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25331

--- Comment #6 from Hans-Peter Nilsson  ---
Fixed for the upcoming binutils-2.35.
Thanks for the report and sorry for the delay.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug ld/26083] cris linker generate zero sized PLTRELSZ

2020-06-07 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26083

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Hans-Peter Nilsson  ---
(In reply to H.J. Lu from comment #0)
...
>  0x0002 (PLTRELSZ)   0 (bytes)  Is it really needed?
>  0x0014 (PLTREL) RELA
>  0x0017 (JMPREL) 0x194
...

I'd say yes, according to the 2001 gABI draft I see at
.
 While DT_PLTRELSZ is listed as optional in the table named "Figure 5-10:
Dynamic Array Tags, d_tag", there's also a description in the section after
that, which says "If an entry of type DT_JMPREL is present, a DT_PLTRELSZ must
accompany it".

Pragmatically, I see the consensus of the rest of the world is that it's
actually optional and its absence is to be treated as the value 0, in
particular since your 2017 commit to glibc to that effect. :)

I don't mind to have it that way, but I'm not sure it's as easy to remove as
just an extra if-clause in elf_cris_finish_dynamic_sections, as room has to be
allocated for it in elf_cris_finish_dynamic_sections, when it's value is
unknown.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/25876] Demangling support for "spaceship operator"

2020-04-27 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25876

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Resolution|INVALID |MOVED
URL||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94797

--- Comment #3 from Hans-Peter Nilsson  ---
Ackchyually, the correct designation is "moved", not "invalid", as I remember
it.
JFTR: the bug is reported over at gcc (by Matt) and already fixed.
Time for an import?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25331] mmix-gas fails to assemble newlib-3.1.0: internal error: fixup not contained within frag

2020-01-01 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25331

Hans-Peter Nilsson  changed:

   What|Removed |Added

Summary|mmix-gas fals to assemble   |mmix-gas fails to assemble
   |newlib-3.1.0|newlib-3.1.0: internal
   |(-fstack-protector-strong   |error: fixup not contained
   |-ffunction-sections):   |within frag
   |internal error: fixup not   |
   |contained within frag   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25331] mmix-gas fals to assemble newlib-3.1.0 (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag

2020-01-01 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25331

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-02
   Assignee|unassigned at sourceware dot org   |hp at sourceware dot org
 Ever confirmed|0   |1

--- Comment #2 from Hans-Peter Nilsson  ---
JFTR, gas needs the option "-x" to assemble this (as usually passed by gcc), or
other errors also appear.  Last time I looked into this I found that I need to
check md_convert_frag (and also to remove the TC_FX_SIZE_SLACK definition) so
that's where this stands for the moment.  The test-case is very helpful; I had
one  10 times larger.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25331] mmix-gas fals to assemble newlib-3.1.0 (-fstack-protector-strong -ffunction-sections): internal error: fixup not contained within frag

2020-01-01 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25331

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC|hp at bitrange dot com |hp at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gprof/2587] Failed to build gprof under gmake patched by Apple.

2019-11-14 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=2587

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #12 from Hans-Peter Nilsson  ---
(In reply to Nick Clifton from comment #10)
> (In reply to parakleta from comment #8)
> > I think just changing the 'SUFFIXES = .m' to 'SUFFIXES = .c .m' and
> > rebuilding the "makefile.in" should do it.
> 
> OK, done.  Plus this time I actually rebuilt Makefile.in, which I forgot
> last time.  Doh.
> 
> I have also REOPENED this PR, so that it will remain active until you
> can confirm that the changes are working.
> 
> Cheers
>   Nick

My autotester for mmix-knuth-mmixware cris-axis-linux-gnu cris-axis-elf
running on Debian 9 x86_64 (GNU make 4.1) screams at 63442f6:
...
Setting warning flags = -W -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wshadow -Wstack-usage=262144 -Werror
configure: updating cache ./config.cache
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating po/Makefile.in
config.status: creating gconfig.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
make[2]: *** No rule to make target 'flat_bl.c', needed by 'all'.  Stop.
make[2]: Entering directory '/tmp/hpautotest-binutils/cris-axis-elf/gprof'
make[2]: Leaving directory '/tmp/hpautotest-binutils/cris-axis-elf/gprof'
make[1]: *** [all-gprof] Error 2
Makefile:6185: recipe for target 'all-gprof' failed
make[1]: Leaving directory '/tmp/hpautotest-binutils/cris-axis-elf'
make: *** [all] Error 2
Makefile:850: recipe for target 'all' failed

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/23070] mipsel-linux-gnu ld testsuite failure for "DT_TEXTREL map file warning"

2018-04-16 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=23070

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Keywords||testsuite

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/23071] New: gas and binutils testsuite errors for mipsisa32r2el-linux-gnu apparently due to defaulted architecture

2018-04-16 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=23071

Bug ID: 23071
   Summary: gas and binutils testsuite errors for
mipsisa32r2el-linux-gnu apparently due to defaulted
architecture
   Product: binutils
   Version: 2.31 (HEAD)
Status: NEW
  Keywords: testsuite
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: hp at sourceware dot org
  Target Milestone: ---
  Host: x86_64-linux
Target: mipsisa32r2el-linux-gnu

(Sorry, doesn't seem worthwhile to split into separate binutils and gas
reports.)

At master c77852c (HEAD as of this writing), binutils configured with
--target=mipsisa32r2el-linux-gnu with no other tools in $PATH (e.g. no
target-gcc), gets these errors in the gas and binutils test-suites with "make
check", respectively:

gas:
Running /xx/src/gas/testsuite/gas/mips/mips.exp ...
FAIL: MIPS MIPS64 MIPS-3D ASE instructions (-mips3d flag)
FAIL: MIPS MIPS64 MDMX ASE instructions (-mdmx flag)
FAIL: mips module-defer-warn2

binutils:
Running /xx/src/binutils/testsuite/binutils-all/mips/mips.exp ...
FAIL: MIPS XPA and Virtualization ASE instruction disassembly 1
FAIL: MIPS XPA and Virtualization ASE instruction disassembly 2
FAIL: MIPS XPA and Virtualization ASE instruction disassembly 3

There are error messages in gas/testsuite/gas.log apparently due to
the level defaulted by the "mipsisa32r2el" in the configure-tuple.  In
biutils/binutils.log, disassembly is different compared to the
test-suite template.  Maybe best to force a certain architecture in
the assembly options and disassembly options, as applicable.

Not seen if configured with --target=mipsel-linux-gnu.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/23070] New: mipsel-linux-gnu ld testsuite failure for "DT_TEXTREL map file warning"

2018-04-16 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=23070

Bug ID: 23070
   Summary: mipsel-linux-gnu ld testsuite failure for "DT_TEXTREL
map file warning"
   Product: binutils
   Version: 2.31 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: hp at sourceware dot org
  Target Milestone: ---
  Host: x86_64-linux
Target: mipsel-linux-gnu

At master c77852c (HEAD as of this writing), binutils configured with
--target=mipsel-linux-gnu with no other tools in $PATH (e.g. no target-gcc),
gets this error in the ld test-suite with "make check":

Running /xx/src/ld/testsuite/ld-elf/shared.exp ...
FAIL: DT_TEXTREL map file warning

In ld/ld.log:
...
extra regexps in /xx/src/ld/testsuite/ld-elf/textrel.map starting with
"^.*dynamic relocation .* read-only section.*$"
EOF from tmpdir/ld.messages
FAIL: DT_TEXTREL map file warning

Also seen if configured with --target=mipsisa32r2el-linux-gnu.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22335] Gas expression solver can cause wrong code for 32-bit BFD builds.

2017-10-22 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22335

--- Comment #1 from Hans-Peter Nilsson  ---
A randomly picked 32-bit target where this fails *for a 32-bit BFD build* is
avr-elf.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22335] New: Gas expression solver can cause wrong code for 32-bit BFD builds.

2017-10-22 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22335

Bug ID: 22335
   Summary: Gas expression solver can cause wrong code for 32-bit
BFD builds.
   Product: binutils
   Version: 2.30 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: hp at sourceware dot org
  Target Milestone: ---

Created attachment 10550
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10550=edit
test-case in the form of a patch

You'll typically observe, for a LE target, instead of the intended result, the
following in gas.log:

regexp_diff match failure
regexp "^[ ]+0+[ ]+(286fff0b|0bff6f28)[ ]+.*$"
line   "  386f7f0b 8o.."
FAIL: gas/all/shexpr

The test-case is from the CRIS test-suite (shexpr-1) where the issue was fixed
by forcing a 64-bit BFD.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22304] XPASS tests in gas

2017-10-22 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22304

Hans-Peter Nilsson  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=22335

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22304] XPASS tests in gas

2017-10-22 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22304

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Hans-Peter Nilsson  ---
Now actually fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22304] XPASS tests in gas

2017-10-21 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22304

--- Comment #7 from Hans-Peter Nilsson  ---
(In reply to H.J. Lu from comment #0)
> On x86-64, cross binutils to cris-linux gave
> 
> XPASS: gas/cris/shexpr-1
> XPASS: gas/cris/range-err-1.s  (test for errors, line 29)
> XPASS: gas/cris/range-err-1.s  (test for errors, line 38)
> XPASS: gas/cris/range-err-1.s  (test for errors, line 50)

(with an LP64 host or --enable-64-bit-bfd)

> These should be removed.  Similar check can be used to detect 64-bit AS:
> 
> commit 978c05401b0f0ac7a94cca7db19b1dec0c5bd698
> Author: H.J. Lu 
> Date:   Wed Aug 9 15:04:05 2017 -0700
> 
> Run PR ld/17618 test only with 64-bit ELF linker
> 
> PR ld/17618 test requires 64-bit linker to run.  Set LD_CLASS to "64bit"
> for 64-bit ELF linker and run PR ld/17618 test only if $LD_CLASS is
> "64bit".  More checks can be added to support 64-bit linkers in non-ELF
> format.

No, that method has a bug: you're confusing host with target there, though it's
fixable.  Details on the main mailing list.  Also, not usable as-is with a
suffix-driven run_dump_test and also not applicable as it's a bfd-size issue,
not a elf-class issue.

I'll do something else.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22304] XPASS tests in gas

2017-10-19 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22304

Hans-Peter Nilsson  changed:

   What|Removed |Added

Summary|XPASS tests in gas and  |XPASS tests in gas
   |unknown successes in ld |

--- Comment #6 from Hans-Peter Nilsson  ---
(In reply to Nick Clifton from comment #5)
> Hi Hans-Peter,
> 
> > Um, these tests now fail for my -m32 autotester setup.
> 
> They do ?  I did test with this option enabled and I did not see any
> unexpected failures...  Was this on a 32-bit host ?  I must admit that I did
> not check that particular combination.
> 
> Cheers
>   Nick

They have been consistent since they were added, the difference being whether
the bfd_address (I presume) is 32 (xfailing) or 64 bits (xpassing).
Anyway, repeatable with CC='gcc -O2 -m32' on a x86_64-linux host,
--target=cris-axis-elf alternatively --target=cris-axis-linux-gnu.  I see there
are no failing ld tests, so I guess that that part is fixed thus I'm adjusting
the title.  More later.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22304] XPASS tests in gas and unknown successes in ld

2017-10-18 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22304

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC|hp at bitrange dot com |

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22304] XPASS tests in gas and unknown successes in ld

2017-10-18 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22304

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #3)
> (In reply to Nick Clifton from comment #2)
> Um, these tests now fail for my -m32 autotester setup.

FAOD, referring to the gas tests, I haven't looked into the ld tests yet.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/22304] XPASS tests in gas and unknown successes in ld

2017-10-18 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=22304

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||hp at sourceware dot org
 Resolution|FIXED   |---
   Assignee|unassigned at sourceware dot org   |hp at sourceware dot org

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to Nick Clifton from comment #2)
> Hi H.J.
> 
>   Agreed - these tests should be expected to pass.  I have updated the
>   testsuite accordingly.
> 
> Cheers
>   Nick

Um, these tests now fail for my -m32 autotester setup.  I'm reopening this and
assigning it to me for the purpose of adding or using a 32-bit-host xfail
mechanism, which did not exist at the time of addition of these tests.  Please
be patient and wait a few days, ok?  Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/20125] mmix: C++ code fails to link

2017-09-13 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20125

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Target Milestone|2.30|2.29.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/20125] mmix: C++ code fails to link

2017-08-20 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20125

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.30

--- Comment #2 from Hans-Peter Nilsson  ---
Finally fixed, for 2.30.  Thank you for the report and for your patience.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/21233] Internal error, /usr/bin/ld: BFD (GNU Binutils for Debian) 2.28 assertion fail ../../bfd/elfxx-mips.c:3861

2017-04-04 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=21233

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-28 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Target Milestone|--- |2.29

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-28 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Hans-Peter Nilsson  ---
(In reply to wbx from comment #16)
> works great. Thanks.

Great.  Thanks again for your patience.

> Might be a candidate for 2.28 stable branch :)

Agreed and that request was indeed made in the message to the mailing list,
with CC to the release manager, whose acceptance I believe is required
post-release.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-28 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

--- Comment #15 from Hans-Peter Nilsson  ---
A link to the commit is available above and the reporter CC:ed on the message
to the mailing list.

Reporter, while I have no doubt that the issue s fully fixed, I await your
confirmation before closing the issue.

Observation: readelf says the DSO after the patch is identical to that of just
deleting the annoying assert. :)  The test-case I added is not known to make a
difference in that regard; I just followed the observations from following the
original case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-13 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #13 from Hans-Peter Nilsson  ---
Repeated, thanks.  Fix forthcoming.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-13 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

--- Comment #12 from Hans-Peter Nilsson  ---
Created attachment 9899
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9899=edit
uclibc_nonshared.a

Reports should not rely on the contents of external sites, so I've extracted
the relevant test-case information. Assuming these files were correctly
uploaded despite the attachment-types mishap, they're the preferred means to
repeat the bug together with the command-line parameters (to e.g. ld-new):

--eh-frame-hdr -mcrislinux -shared -o libuClibc-1.0.22.so -mcrislinux
--warn-common --warn-once -z combreloc -O2 -z defs -O1 --version-script
libc.map -init __uClibc_init -soname=libc.so.1 --whole-archive libc_so.a
--no-whole-archive interp.os ld-uClibc.so.1 uclibc_nonshared.a
libpthread_nonshared.a libgcc.a

And yes, I could have tarred them together.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-12 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

--- Comment #10 from Hans-Peter Nilsson  ---
Created attachment 9897
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9897=edit
libgcc.a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-12 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

--- Comment #9 from Hans-Peter Nilsson  ---
Created attachment 9896
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9896=edit
libc_so.a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-12 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

--- Comment #8 from Hans-Peter Nilsson  ---
Created attachment 9895
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9895=edit
libc.map

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-12 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

--- Comment #7 from Hans-Peter Nilsson  ---
Created attachment 9894
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9894=edit
ld-uClibc.so.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-11 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |WAITING

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-11 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to wbx from comment #1) 
> Is the assertion to strict/wrong for crisv10?

The short answer is "no".  The longer answer includes "Other things happen for
CRIS v10 than for CRIS v32 for architectural reasons, like PLTGOT to GOT
optimization."

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16044] BFD (GNU Binutils) 2.23.2 assertion fail elf32-cris.c:2732

2017-03-11 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16044

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at sourceware dot org
   Assignee|unassigned at sourceware dot org   |hp at sourceware dot org

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to wbx from comment #2)
> Here is the build log from the toolchain, all libs involved in the final
> link and the last command output with -Wl,-M.
> 
> https://debug.openadk.org/crisv10/
> 
> It happens when the final libc.so is created.

Thanks for the report.  Some information is missing though.
Please also attach here the *linker* invocation line
(to avoid incorrect guessing from the *gcc* command line in make.log).
To find it:
Add "-v" to the gcc command line and you'll find it in the stderr output on the
last line confusingly called (not "ld" but) "collect2".  (To the peanut
gallery: I know, but this is the short version for someone to whom all this is
new.)

>From the map output at the link above (see the LOAD lines) and from the gcc
command line, I'm missing at least the files
 libc_so.a
 libc.map
in order to proceed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/20125] mmix: C++ code fails to link

2016-05-20 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=20125

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||hp at sourceware dot org
   Assignee|unassigned at sourceware dot org   |hp at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/19935] [SH] --enable-initfini-array causes failures in GCC testsuite

2016-04-14 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=19935

--- Comment #10 from Hans-Peter Nilsson  ---
(In reply to H.J. Lu from comment #9)
> There is no excuse not to support .init_array, .fini_array and
> .preinit_array.  I will go one step further to say that we should
> deprecate any ELF targets without support for .init_array,
> .fini_array and .preinit_array in binutils 2.27.

What's with the hyperbole?  It's not like the binutils project is affected by
there being no support in *libgloss*.  You effectively want to deprecate lots
of, if not most, newlib targets; I don't know what the binutils project would
win.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/19935] [SH] --enable-initfini-array causes failures in GCC testsuite

2016-04-14 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=19935

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Target|sh*-*-* cris|sh*-*-* cris*-*-elf

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/19935] [SH] --enable-initfini-array causes failures in GCC testsuite

2016-04-14 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=19935

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Target|sh*-*-* |sh*-*-* cris

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/19935] [SH] --enable-initfini-array causes failures in GCC testsuite

2016-04-14 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=19935

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #8 from Hans-Peter Nilsson  ---
I see this for cris-elf too, sorry I've been silent.  I'm on the fence whether
to add the support to libgloss or disable in binutils for cris-elf.  Had no
time to do neither.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/16698] BFD (GNU Binutils) 2.24 assertion fail elf32-arm.c:12387

2014-06-13 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16698

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC|hp at sourceware dot org   |

--- Comment #5 from Hans-Peter Nilsson hp at sourceware dot org ---
Please don't add random maintainers to CC.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16963] SEARCH_DIR missing for some targets without sysroot since genscript.sh cleanup (0f70b6b)

2014-06-06 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16963

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Hans-Peter Nilsson hp at sourceware dot org ---
Fix along the posted lines (follow links) committed, but I forgot to annotate
with the magic changelog annotation so not automatically noted here and forgot
to close this. Back-porters, note the patch has a flaw fixed up in a later
commit by Alan.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16963] New: SEARCH_DIR missing for some targets without sysroot since genscript.sh cleanup (0f70b6b)

2014-05-19 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16963

Bug ID: 16963
   Summary: SEARCH_DIR missing for some targets without sysroot
since genscript.sh cleanup (0f70b6b)
   Product: binutils
   Version: 2.25 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: hp at sourceware dot org

Commit 0f70b6b was not intended to change the tdir for targets without
sysroot.  However, it removed the default setting when passed as empty to
genscript.sh.  Unfortunately, many genscript.sh invocations in ld/Makefile
accidentally were using a typo'd or plainly wrong tdir-variable (e.g.
$(tdir_cris) instead of $(tdir_crislinux) for the crislinux emulation or
$(tdir_armelf_linux_abi) instead of $(tdir_armelf_linux_eabi), for the
armelf_linux_eabi emulation), causing it to be passed as empty.  For
configurations without --with-sysroot, after commit 0f70b6b this means the
corresponding SEARCH_DIR in the linker-script is gone.  That this effect was
unintended can be seen in the conversation at
http://sourceware.org/ml/binutils/2013-09/msg9.html.  One effect for
targets with dynamic linking and libraries in the intended directory, depending
solely on the now missing SEARCH_DIR (no --rpath-link or other pointers to that
directory) is that linking with libraries depending on DSOs in this directory
causes linker errors.
This is a regression since the binutils 2.24 release.

For example, for a glibc-based toolchain installation with binutils after
commit 0f70b6b, make prog shows this error when requiring dynamic linking
against the rt library in that directory:

/path/to/r101/lib/gcc/crisv32-axis-linux-gnu/4.7.2/../../../../crisv32-axis-linux-gnu/bin/ld:
warning: librt.so.1, needed by ./libnsec.so, not found (try using -rpath or
-rpath-link)
./libnsec.so: undefined reference to `clock_gettime@GLIBC_2.2'
collect2: error: ld returned 1 exit status
make: *** [prog] Error 1

using this code:

prog.c:
#include stdio.h
extern int nsec(void);
int main(void)
{
  printf (Time runs: %d\n, nsec());
}

lib.c:
#include time.h
#include unistd.h
#if !(defined CLOCK_MONOTONIC  defined _POSIX_MONOTONIC_CLOCK)
#error Sorry, wrong system
#endif
int nsec (void)
{
  struct timespec ts;
  if (clock_gettime (CLOCK_MONOTONIC, ts) != 0)
return -1;
  return ts.tv_nsec;
}

Makefile:
all: prog libnsec.so

prog: prog.c libnsec.so
$(CC) -o prog prog.c -lnsec -L.

libnsec.so: lib.c
$(CC) -fPIC -shared -o libnsec.so lib.c -lrt

clean:
-rm *.o *.so prog

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16963] SEARCH_DIR missing for some targets without sysroot since genscript.sh cleanup (0f70b6b)

2014-05-19 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16963

--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org ---
Patch at http://sourceware.org/ml/binutils/2014-05/msg00164.html.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16963] SEARCH_DIR missing for some targets without sysroot since genscript.sh cleanup (0f70b6b)

2014-05-19 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16963

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |hp at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16792] $tooldir/lib is sysrooted when built --with-sysroot

2014-05-19 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16792

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org ---
I believe the sysroot general equivalent should be =/lib.
(Adjustable by target emulparams script to e.g. =/lib32, =/lib64 etc.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16792] $tooldir/lib is sysrooted when built --with-sysroot

2014-05-19 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16792

--- Comment #3 from Hans-Peter Nilsson hp at sourceware dot org ---
(In reply to Cygwin/X maintainer from comment #2)
 When a sysroot is in use, libraries usually end up in =/lib and =/usr/lib
 (or =/mingw/lib for *-*-mingw*), but $exec_prefix/$target_alias/lib has
 still been scanned.  Not only is that not happening at the moment, but
 sysrooting that directory really doesn't make sense.

I'm not sure whether you agree or disagree. :)

To wit, I'm saying 'don't scan $exec_prefix/$target_alias/lib, scan the
target-adjusted equivalent of =/lib; i.e. =/mingw/lib for *-*-mingw*'. 
...maybe also =/usr/lib where that isn't a capital offence, e.g. *-*-gnu...

IIUC (I'm certainly not sure) sysroot targets don't have (*should* not have)
anything in $exec_prefix/$target_alias/lib but everything in =/lib or
=/usr/lib so  $exec_prefix/$target_alias/lib should not be scanned at all (as
such, that is).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16744] '-z noexecstack' does not add .note.GNU-stack for relocatables

2014-03-24 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16744

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org ---
It might be incidental and having no consequence to the intent of this PR (you
haven't mentioned the target), but it's worthwhile to note here that the
semantics (the polarity) of a .note.GNU-stack presence is target-dependent. 
Thus, your observation is actually correct behaviour on some targets.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/16656] New: mipsisa32r2el-unknown-linux-gnu testsuite failures

2014-03-03 Thread hp at sourceware dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=16656

Bug ID: 16656
   Summary: mipsisa32r2el-unknown-linux-gnu testsuite failures
   Product: binutils
   Version: 2.25 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: hp at sourceware dot org

Observed with f97a10f.

Target is mipsisa32r2el-unknown-linux-gnu
Host   is x86_64-unknown-linux-gnu

=== ld tests ===

Schedule of variations:
unix

...
Running /tmp/hpautotest-binutils/bsrc/src/ld/testsuite/ld-elf/binutils.exp ...
FAIL: objcopy -shared -z relro (tbss1)
FAIL: objcopy -shared -z relro (tbss2)
FAIL: objcopy -shared -z relro (tbss3)
...
Running /tmp/hpautotest-binutils/bsrc/src/ld/testsuite/ld-scripts/rgn-at.exp
...
FAIL: ld-scripts/rgn-at11

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/16288] New: Specifying an ISA in a .set directive causes a warning if lower than set from command-line

2013-12-02 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=16288

Bug ID: 16288
   Summary: Specifying an ISA in a .set directive causes a warning
if lower than set from command-line
   Product: binutils
   Version: 2.25 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: hp at sourceware dot org
Target: mips*-*

Seen with recent master of binutils, for example 310bf259c3524c2954; from
code-inspection likely to be present for 2.24 as well.

The following construct is common with in-lined code (seen in alsa-lib and
userspace-rcu), but gets a warning if the setting is lower than one specified
on the command-line.

For a mips-elf target and a file s.s, with the contents:

 .set push
 .set mips2
 nop
 .set pop

Observe:
$ gas/as-new s.s
$ gas/as-new -march=34kc s.s
s.s: Assembler messages:
s.s:2: Warning: the `dsp' extension requires MIPS32 revision 2 or greater
s.s:2: Warning: the `mt' extension requires MIPS32 revision 2 or greater

Note that the warning comes from the .set mips2 directive, regardless of
whether it's followed by code; the test-case can actually be reduced to that
single line.  The -march option comes from gcc when specifying the same option
or from the configuration.

The warning is bogus; the .set implementation seems to miss clearing
command-line-specified ASEs when specifying an ISA.  I believe that is how it's
intuitively should work; this warning is a regression from, like, 8 months ago.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/15126] [REGRESSION] 2.23.51.0.9 fails to link cairo with libstdc++ (could not read symbols: Invalid operation)

2013-12-01 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=15126

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14768] Checklist: Binutils Migration To Git

2013-09-19 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14768

--- Comment #20 from Hans-Peter Nilsson hp at sourceware dot org ---
(In reply to Tom Tromey from comment #19)
 (In reply to Hans-Peter Nilsson from comment #18)
 
  Sorry, there was an ambiguity here.  By work-flow I meant
  git-migration-unrelated usual work-flow, of checking out and building and
  committing changes to files affected by the migration changes, not
  specifically work-flow of git migration - though that makes sense too on
  its own.
 
 I don't follow this.
 Could you give an example?

The work-flow changes unrelated to the act of moving to git but affected by the
combined (and separated) repository.  The simplest example would be the extra
options needed to configure for configuring *only* binutils (*without* gdb and
*without* sim)
in the path/configure  make  make check work-flow (alternatively the
release-tarball method, but that's more involved than I expected).  For
separated projects, e.g. cgen, you would also need a separate tree when testing
your cgen changes or changes to files in src/cpu/* instead of just checking out
cgen along with your sim or binutils tree.

So, the bullet-point being to test these changes in development work-flow works
(that the binutils configure option above works and that the cgen separation
works - patch needed there), post them to the respective lists.  For newlib, I
guess there wouldn't be much change in work-flow (needs gcc too, so also has
overcome any tree-separation anxiety with gdb and binutils).

And now that you've read this far, how about that src-release patch for sim?
I'll add a pointer in my next comment.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14768] Checklist: Binutils Migration To Git

2013-09-19 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14768

--- Comment #21 from Hans-Peter Nilsson hp at sourceware dot org ---
(In reply to Hans-Peter Nilsson from comment #16)
 * Add remaining partial checkout methods as mentioned in
 CVSROOT/modules to src-release, for related migrating projects (well, at
 least sim).

There seemed to be only sim.  Patch is awaiting approval at
http://sourceware.org/ml/gdb-patches/2013-09/msg00257.html.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14768] Checklist: Binutils Migration To Git

2013-08-30 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14768

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #16 from Hans-Peter Nilsson hp at sourceware dot org ---
A few more to-do items:

* Git migrations and work-flow offered for remaining projects
(like newlib and cgen).

* (related:) Do not set in stone this git repo as binutils+gdb
in any documentation changes and names assuming we agree that other projects
may be added.

* Add remaining partial checkout methods as mentioned in
CVSROOT/modules to src-release, for related migrating projects (well, at
least sim).  Mention this as a (the only?) supported way to
generate the project-specific tree.

See http://sourceware.org/ml/binutils/2013-08/msg00281.html for reasons.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14768] Checklist: Binutils Migration To Git

2013-08-30 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14768

--- Comment #18 from Hans-Peter Nilsson hp at sourceware dot org ---
(In reply to jos...@codesourcery.com from comment #17)
 On Fri, 30 Aug 2013, hp at sourceware dot org wrote:
 
  * Git migrations and work-flow offered for remaining projects
  (like newlib and cgen).

Sorry, there was an ambiguity here.  By work-flow I meant
git-migration-unrelated usual work-flow, of checking out and building and
committing changes to files affected by the migration changes, not
specifically work-flow of git migration - though that makes sense too on its
own.

 That should be in the form: document in detail how the migration worked, 
 so that if the newlib community chooses to move to git, it has the benefit 
 of documentation of the process when replicating it to move to its own git 
 repository.

Not sure if your reply was affected by the ambiguity of my suggestion, but
anyway your suggestion makes sense.

  * (related:) Do not set in stone this git repo as binutils+gdb
  in any documentation changes and names assuming we agree that other projects
  may be added.
 
 Rather, I say the repository should be exactly 6(b) from 
 http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html

If the src CVS is to be able to continue on its own then there's one or two
missing TODO items last:

* Undo the read-only marking of the subset of converted directories that are
shared with non-migrated projects.

(For example: config/) and

* Alert all non-migrated projects affected by converted directories.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/15869] New: nm --size-sort test fails for alpha-unknown-linux-gnuecoff

2013-08-20 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=15869

Bug ID: 15869
   Summary: nm --size-sort test fails for
alpha-unknown-linux-gnuecoff
   Product: binutils
   Version: 2.24 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: hp at sourceware dot org
  Host: i686-pc-linux-gnu
Target: alpha-unknown-linux-gnuecoff

Build HEAD for alpha-unknown-linux-gnuecoff (*not* alpha-linux-ecoff); just an
ECOFF (or non-ELF) target. make check-binutils shows lots of failures,
including:

Running
/home/hp/binutils/fixmmix0820/src/binutils/testsuite/binutils-all/nm.exp ...
Version /home/hp/binutils/fixmmix0820/obE/binutils/nm-new 2.23.52.20130820
FAIL: nm (no arguments)
FAIL: nm -P
FAIL: nm --size-sort

The log for the --size-sort change shows:
/home/hp/binutils/fixmmix0820/obE/binutils/nm-new  --size-sort tmpdir/nm-1.o
Executing on host: /home/hp/binutils/fixmmix0820/obE/binutils/nm-new 
--size-sort tmpdir/nm-1.o   (timeout = 300)
0008 T text_symbol2

000c T text_symbol1

000c T text_symbol3

0008 T text_symbol2
000c T text_symbol1
000c T text_symbol3

FAIL: nm --size-sort

Note the unexpected symbol values; a plain ./nm-new tmpdir/nm-1.o shows:
 T text_symbol1
000c T text_symbol2
0014 T text_symbol3

A guess is that the symbol values are fouled up in the generic nm size-sort
handler.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/15602] .word L2-L1 fails to diagnose offsets larger than 16 bits, resulting in broken jump tables on m68k

2013-06-12 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=15602

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #6 from Hans-Peter Nilsson hp at sourceware dot org ---
(In reply to Mikael Pettersson from comment #5)

  tc_m68k_check_adjusted_broken_word (addressT new_offset, struct broken_word

 -  if (new_offset  0x)
 +  if (new_offset  0x7fff)

 since, as Andreas wrote, the offsets are signed and must fit in [0,32K-1].

I'd humbly suggest copy-pasting the definition from the CRIS port to get it
right
(using offsetT and explicit limit checking, not relying on addressT being
unsigned).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/15217] branch-to-arm-from-thumb for typeless symbol is missing a stub

2013-05-07 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=15217

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX

--- Comment #3 from Hans-Peter Nilsson hp at sourceware dot org 2013-05-07 
21:13:59 UTC ---
The patch is at http://sourceware.org/ml/binutils/2013-03/msg00020.html and
the message upon closing this PR is at
http://sourceware.org/ml/binutils/2013-05/msg00088.html.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/15217] branch-to-arm-from-thumb for typeless symbol is missing a stub

2013-03-03 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=15217

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at sourceware|hp at sourceware dot org
   |dot org |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/15217] New: branch-to-arm-from-thumb for typeless symbol is missing a stub

2013-02-28 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=15217

 Bug #: 15217
   Summary: branch-to-arm-from-thumb for typeless symbol is
missing a stub
   Product: binutils
   Version: 2.24 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: h...@sourceware.org
Classification: Unclassified
Target: arm-unknown-linux-gnueabi


Created attachment 6908
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6908
test-case

See the run_dump_test test-case patch in the attachment.  Note that the
type-specifiers for the symbol types are commented out; the code is derived
from mixed-lib.s but with function names swapped, calling arm from thumb and
thumb from arm.  The call from app_tfunc (in thumb mode) to lib_func2 (in arm
mode) doesn't get a stub with todays sources.  The expected test-case output
is observed by adding back the type specifiers causing a proper thumb-to-arm
stub being generated with the test passing.

The real-world code is somewhat sloppy hand-written assembly-code; no symbol
decorations, just .global where necessary, but which worked with a toolchain
using pre-2.19 binutils.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/15151] archive support is broken

2013-02-15 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=15151

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org 2013-02-15 
17:18:36 UTC ---
Hey!  I was just about to email Nick about the fallout; cris-linux and cris-elf
have the following regressions, which I believe fit in this PR:

Running
/tmp/hpautotest-binutils/bsrc/src/binutils/testsuite/binutils-all/ar.exp ...
FAIL: ar symbol table
FAIL: ar thin archive (bfdtest1)
FAIL: ar thin archive with nested archive (bfdtest1)
FAIL: ar deterministic archive
FAIL: ar deleting an element
FAIL: ar moving an element
FAIL: ar unique symbol in archive
Running
/tmp/hpautotest-binutils/bsrc/src/binutils/testsuite/binutils-all/arm/objdump.exp
...
Running
/tmp/hpautotest-binutils/bsrc/src/binutils/testsuite/binutils-all/bfin/objdump.exp
...
Running
/tmp/hpautotest-binutils/bsrc/src/binutils/testsuite/binutils-all/compress.exp
...
FAIL: objcopy (objcopy decompress debug sections in archive)
FAIL: objcopy (objcopy compress debug sections in archive)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14481] bfd leaks archive member hash table

2012-11-26 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14481

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #6 from Hans-Peter Nilsson hp at sourceware dot org 2012-11-26 
19:31:28 UTC ---
(In reply to comment #5)
 Changes by:h...@sourceware.org2012-11-07 05:51:37
 
 Modified files:
 bfd: ChangeLog aout-target.h 

Please note that this was a fix only for *most* *a.out* targets.  To wit, it
does not fix all targets and not all a.out targets.  See
http://sourceware.org/ml/binutils/2012-11/msg00078.html.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14720] FAIL: ar long file names (bfdtest1)

2012-10-15 Thread hp at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=14720



Hans-Peter Nilsson hp at sourceware dot org changed:



   What|Removed |Added



 CC||hp at sourceware dot org



--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org 2012-10-16 
03:55:29 UTC ---

Most of this is a duplicate of PR14481.  The exception being that I don't see

the FAIL: ar thin archive with nested archive (bfdtest1) for e.g. cris-elf

(has targ_defvec=cris_aout_vec for hysterical raisins).



-- 

Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email

--- You are receiving this mail because: ---

You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/14521] segv with '.section .text,axG,@progbits,.foo,comdat'

2012-09-03 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14521

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Hans-Peter Nilsson hp at sourceware dot org 2012-09-03 
23:47:10 UTC ---
Fixed for HEAD (which isn't 2.23 BTW, the bugzilla choices need to be updated).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/14521] segv with '.section .text,axG,@progbits,.foo,comdat'

2012-09-03 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14521

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

Version|2.23 (HEAD) |unspecified

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/14521] segv with '.section .text,axG,@progbits,.foo,comdat'

2012-09-03 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14521

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

Version|unspecified |2.24 (HEAD)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug gas/14521] New: segv with '.section .text,axG,@progbits,.foo,comdat'

2012-08-26 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14521

 Bug #: 14521
   Summary: segv with '.section .text,axG,@progbits,.foo,comdat'
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
AssignedTo: unassig...@sourceware.org
ReportedBy: h...@sourceware.org
Classification: Unclassified
Target: mmix-knuth-mmixware


See the summary.  There's a gcc configury test (checking assembler for COMDAT
group support (GNU as)) that fails due to the SEGV from the single line:

.section .text,axG,@progbits,.foo,comdat

(with as well as without the correct syntax, i.e. a leading space)

It might or might not be correct to assemble this without errors, but a SEGV is
not among the acceptable failure modes of the assembler.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/14385] testSummary

2012-07-22 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14385

--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org 2012-07-22 
14:49:51 UTC ---
Without *any* description as to what is wrong with this file and how it was
created by binutils or how a binutils tool misinterprets it, I'm inclined to
scream VIRUS ALERT!  See also bug 14384.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14072] Incorrect handling of config.h and/or sysdep.h causing problems

2012-05-17 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14072

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 CC||hp at sourceware dot org

--- Comment #5 from Hans-Peter Nilsson hp at sourceware dot org 2012-05-17 
17:27:15 UTC ---
(In reply to comment #4)
 Hi Daniel,
 
   OK, you have persuaded me.  I have applied your patch to my local sources,
 fixed up all the places where it found problems with the order of header file
 inclusion and then checked in the resulting (rather large) patch.

Looks like this patch caused breakage all over.  Please build crosses to e.g.
arm-eabi and cris-elf.  A make check will show weird ERRORs for missing
tools.  Looks like e.g. as-new isn't linked anymore.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/14072] Incorrect handling of config.h and/or sysdep.h causing problems

2012-05-17 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=14072

--- Comment #6 from Hans-Peter Nilsson hp at sourceware dot org 2012-05-17 
18:15:38 UTC ---
Created attachment 6408
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6408
example libtool, this one for arm-eabi gas; objdir/gas/libtool

Looks like libtool for some programs (like gas) is now broken; truncated just
before the code for func_dirname_and_basename (the head comment is there, the
function not).  Nothing suspicious in the log around building it

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/3809] ld failures for mips-elf on HEAD

2012-05-16 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=3809

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org 2012-05-16 
23:33:00 UTC ---
The bugs seen as test-suite errors are now fixed.  See
http://sourceware.org/ml/binutils/2012-05/msg00169.html for the last one.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/6742] Ungraceful build error if bison or yacc is not available when building ld from CVS

2012-05-12 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=6742

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||hp at sourceware dot org
Summary|Ld can not be build for |Ungraceful build error if
   |target cygwin if yacc is|bison or yacc is not
   |not available   |available when building ld
   ||from CVS

--- Comment #2 from Hans-Peter Nilsson hp at sourceware dot org 2012-05-12 
09:52:03 UTC ---
Apparently a misdiagnosed generic error (not cygwin-specific), as was reported
*with a quote from the build log* in
http://sourceware.org/ml/binutils/2012-05/msg00151.html.  It took us a long
time to diagnose this because this bug report only was something like main is
duplicated and provided no information of the log. :]
The error now (first) happening for a different file is likely due to changes
since 2008.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13990] ld/ld-new: BFD assertion fail, elf32-arm.c:12259 with --gc-sections and --shared, GCing a PLT reference to a local symbol

2012-04-24 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=13990

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Hans-Peter Nilsson hp at sourceware dot org 2012-04-24 
16:18:27 UTC ---
fixed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13990] New: ld/ld-new: BFD assertion fail, elf32-arm.c:12259 with --gc-sections and --shared, GCing a PLT reference to a local symbol

2012-04-18 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=13990

 Bug #: 13990
   Summary: ld/ld-new: BFD assertion fail, elf32-arm.c:12259 with
--gc-sections and --shared, GCing a PLT reference to a
local symbol
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: h...@sourceware.org
Classification: Unclassified
Target: arm-linux-gnueabi


Building libstdc++.so.6 from the gcc-4.7 branch with current binutils will
yield the following assertions, but the linker will create what seems like a
correct DSO.

/tmp/somewhere/o/ld/ld-new: BFD (GNU Binutils) 2.22.52.20120416 assertion fail
/tmp/somewhere/src/bfd/elf32-arm.c:12259
/tmp/somewhere/o/ld/ld-new: BFD (GNU Binutils) 2.22.52.20120416 assertion fail
/tmp/somewhere/src/bfd/elf32-arm.c:12259
/tmp/somewhere/o/ld/ld-new: BFD (GNU Binutils) 2.22.52.20120416 assertion fail
/tmp/somewhere/src/bfd/elf32-arm.c:12259
/tmp/somewhere/o/ld/ld-new: BFD (GNU Binutils) 2.22.52.20120416 assertion fail
/tmp/somewhere/src/bfd/elf32-arm.c:12259

Again, you may notice this only by inspecting the build log.
Patch in progress; will send it and reduced test-case to the list.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13990] ld/ld-new: BFD assertion fail, elf32-arm.c:12259 with --gc-sections and --shared, GCing a PLT reference to a local symbol

2012-04-18 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=13990

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://sourceware.org/ml/bi
   ||nutils/2012-04/msg00228.htm
   ||l
 AssignedTo|unassigned at sourceware|hp at sourceware dot org
   |dot org |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13900] linking helloaout.c in cris testsuite causes the linker to segfault

2012-03-24 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=13900

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||hp at sourceware dot org
 AssignedTo|unassigned at sourceware|hp at sourceware dot org
   |dot org |

--- Comment #1 from Hans-Peter Nilsson hp at sourceware dot org 2012-03-24 
21:12:03 UTC ---
Not repeated yet, but I'll take it.  Support for a.out is uninteresting but the
sim test-suite shouldn't suffer.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13813] ld-mips-elf/comm-data.exp failures for mipsisa32r2el-unknown-linux-gnu

2012-03-21 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=13813

--- Comment #2 from Hans-Peter Nilsson hp at sourceware dot org 2012-03-21 
19:16:49 UTC ---
fixed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/3807] binutils-all/objcopy.exp test-suite failure for mipsisa32r2el-elf

2012-03-12 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=3807

--- Comment #6 from Hans-Peter Nilsson hp at sourceware dot org 2012-03-13 
00:45:09 UTC ---
And now with more correct xfails.  Not closing it, though; IMHO the underlying
issue is fixable, see the URL.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13813] New: ld-mips-elf/comm-data.exp failures for mipsisa32r2el-unknown-linux-gnu

2012-03-06 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=13813

 Bug #: 13813
   Summary: ld-mips-elf/comm-data.exp failures for
mipsisa32r2el-unknown-linux-gnu
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: h...@sourceware.org
Classification: Unclassified
Target: mipsisa32r2el-unknown-linux-gnu


The n32 and n64 variants in ld-mips-elf/comm-data.exp fail assembly:
Running /home/hp/binutils/src/ld/testsuite/ld-mips-elf/comm-data.exp ...
ERROR: -n32 -EB -call_shared
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly
failed
ERROR: -n32 -EB -call_nonpic
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s: assembly
failed
ERROR: -n32 -EB -call_shared
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly
failed
ERROR: -n32 -EB -call_nonpic
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s: assembly
failed
ERROR: -64 -EB -call_shared
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly
failed
ERROR: -64 -EB --defsym ELF64=1 -call_nonpic
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s: assembly
failed
ERROR: -64 -EB -call_shared
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly
failed
ERROR: -64 -EB --defsym ELF64=1 -call_nonpic
/home/hp/binutils/src/ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s: assembly
failed

In ld.log:
Assembler messages:
Error: -march=mips32r2 is not compatible with the selected ABI
Assembler messages:
Error: -march=mips32r2 is not compatible with the selected ABI

Looking at the source, the mipsisa32r2 in the target triple is taken as the
default for the -march option, and 64-bit registers are required.  I verified
a simple fix is adding a proper -march option to the test-cases for the 64-bit
variants.  Patch to be posted.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/3807] binutils-all/objcopy.exp test-suite failure for mips-elf

2012-03-06 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=3807

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

URL||http://sourceware.org/ml/bi
   ||nutils/2012-03/msg00015.htm
   ||l
Summary|binutils failure for|binutils-all/objcopy.exp
   |mips-elf on HEAD|test-suite failure for
   ||mips-elf

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug binutils/3807] binutils-all/objcopy.exp test-suite failure for mipsisa32r2el-elf

2012-03-06 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=3807

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Target|mips-elf|mipsisa32r2el-elf
Summary|binutils-all/objcopy.exp|binutils-all/objcopy.exp
   |test-suite failure for  |test-suite failure for
   |mips-elf|mipsisa32r2el-elf

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/3809] ld failures for mips-elf on HEAD

2012-03-06 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=3809

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

URL||http://sourceware.org/ml/bi
   ||nutils/2012-03/msg00040.htm
   ||l

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13803] ld test-cases failing: arm-elf.exp erratum 760522 fix

2012-03-05 Thread hp at sourceware dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=13803

Hans-Peter Nilsson hp at sourceware dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Hans-Peter Nilsson hp at sourceware dot org 2012-03-05 
22:40:10 UTC ---
fixed

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


  1   2   >