[Bug ld/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452 Andrei Lupas changed: What|Removed |Added CC||andreilupas at yahoo dot com --- Comment #5 from Andrei Lupas --- (In reply to Alan Modra from comment #3) > See https://sourceware.org/ml/binutils/2009-05/msg00330.html for why > lang_check_section_addresses can't check bss. The "relaxed" checks above (suitable for LMA mapping into ROM scenario) means hours of debug for other people (in my case ALLOC .bss section silently overlapped .text section; LMA = VMA = RAM addresses). I don't think LD "can't check .bss" is an acceptable answer; I think LD should check (as before) ALLOC section overlap (by default or optionally). -- 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/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452 Cristian Gavril Olar changed: What|Removed |Added CC||nathan at gcc dot gnu.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/19877] New: crash when using objdump -t -C
https://sourceware.org/bugzilla/show_bug.cgi?id=19877 Bug ID: 19877 Summary: crash when using objdump -t -C Product: binutils Version: 2.26 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: blastrock0 at free dot fr Target Milestone: --- Created attachment 9133 --> https://sourceware.org/bugzilla/attachment.cgi?id=9133&action=edit binary that makes objdump crash When I run objdump -t -C on the attached binary, it always segfaults: ... 004f7f50 wF .text 000e std::remove_reference >&>::type&& std::move >&>(std::shared_ptr >&) 004efb00 wF .text 000e std::remove_reference&>::type&& std::move&>(std::function&) 004f4b10 wF .text 000e std::remove_reference::type&& std::move(std::_Any_data&) [1]14320 segmentation fault (core dumped) objdump -t tconcurrent/test/test_co -C I don't have objdump's debugging symbols, but my debuggers shows a huge stack, seems like an infinite recursion. I run objdump 2.26 on debian unstable (I had the bug also with 2.25). -- 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/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452 Cristian Gavril Olar changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=7038 -- 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/7038] ld doesn't detect overlap with .bss
https://sourceware.org/bugzilla/show_bug.cgi?id=7038 Cristian Gavril Olar changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=18452 -- 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/19877] crash when using objdump -t -C
https://sourceware.org/bugzilla/show_bug.cgi?id=19877 --- Comment #1 from Philippe --- Just got one more clue from gdb, this fails too: c++filt _ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_ [1]19375 segmentation fault (core dumped) c++filt The attached file is probably useless now. -- 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/19878] New: PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 Bug ID: 19878 Summary: PE/COFF regression in base of code and data calculation Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: toni.spets at iki dot fi Target Milestone: --- Commit 32a9d621c3c480aa093a089a36e36c35f68a4010 introduced a very rare regression regarding base of code and base of data RVA calculation. This commit falls between binutils 2.24 and 2.25. If an executable is built with uncommon section names, the linker can't calculate BaseOfCode and BaseOfData NT header fields. The behaviour before the regression was that they stay at zero which technically equals ImageBase. Behaviour after causes an invalid substraction from zero flipping the base addresses to a high value. An example build that has unknown sections before (objdump -x): BaseOfCode BaseOfData And after: BaseOfCode ffc0 BaseOfData ffc0 There's no effective difference when running such executable - the win32 loader ignores these fields. It only affects programs that analyze executables, like debuggers. Notably, OllyDbg fails to analyze an executable that seeminly has the entry point outside code sections. -- 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 Toni Spets changed: What|Removed |Added Component|binutils|ld -- 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 Toni Spets changed: What|Removed |Added CC||toni.spets at iki dot fi --- Comment #1 from Toni Spets --- Created attachment 9134 --> https://sourceware.org/bugzilla/attachment.cgi?id=9134&action=edit Fix PR ld/19878: Properly zero local structure before use Attached is a patch that fixes the issue. Probably by mistake this memset() was removed in the offending commit. Because of that, some fields in the structure are left uninitialized if text_sec, data_sec or bss_sec variables are not set. In any normal build, all fields are set and this regression is not hit. However, it should never leave the structure uninitialized as it's not guaranteed the following code will always set all fields it can hold. -- 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 Toni Spets changed: What|Removed |Added CC||nickc at redhat 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 binutils/19722] [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19722 --- Comment #2 from njholcomb at wi dot rr.com --- Hi, I'm not assembling this instruction, I am disassembling it from raw bytes. I probably should have specified that this instruction is produced as decoder output, not as assembler output. -Nathan -- 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
binutils
I try to build latest binutils 2.26 instead 2.25.1 and fails with errors. 2.25.1 buided without problem with mingw 4.8.1. I run configure in separated folder. Taken from my shell script: export TARGET=arm-none-symbianelf GCCC=gcc-5.3.0 # Installation folder export PREFIX=/usr/local/$GCCC export PATH=$PATH:$PREFIX/bin unset CFLAGS export CFLAGS+="-pipe" ../binutils-2.26/configure --target=$TARGET --prefix=$PREFIX \ --enable-gold --enable-ld --enable-lto --enable-vtable-verify \ --enable-werror --without-headers --disable-nls --disable-shared \ --with-lib-path=$PREFIX/lib --disable-libquadmath --enable-plugins \ --without-mpc --without-mpfr --without-gmp --without-isl # --enable-multilib --enable-interwork make make install-strip Errors: binutils/../include -D__USE_MINGW_FSEEK -DLOCALEDIR="\"/usr/local/gcc-5.3.0/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I../../binutils-2.26/binutils/../zlib -pipe -D__USE_MINGW_ACCESS -MT readelf.o -MD -MP -MF .deps/readelf.Tpo -c -o readelf.o ../../binutils-2.26/binutils/readelf.c ../../binutils-2.26/binutils/readelf.c: In function 'get_data': ../../binutils-2.26/binutils/readelf.c:350:9: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) nmemb, (unsigned long long) size, reason); ^ ../../binutils-2.26/binutils/readelf.c:350:9: error: unknown conversion type character 'l' in format [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:350:9: error: format '%s' expects argument of type 'char *', but argument 2 has type 'bfd_size_type' [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:350:9: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c:359:9: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) nmemb, (unsigned long long) size, reason); ^ ../../binutils-2.26/binutils/readelf.c:359:9: error: unknown conversion type character 'l' in format [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:359:9: error: format '%s' expects argument of type 'char *', but argument 2 has type 'bfd_size_type' [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:359:9: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c:370:9: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) amt, reason); ^ ../../binutils-2.26/binutils/readelf.c:370:9: error: format '%s' expects argument of type 'char *', but argument 2 has type 'bfd_size_type' [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:370:9: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c:394:6: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) amt, reason); ^ ../../binutils-2.26/binutils/readelf.c:394:6: error: format '%s' expects argument of type 'char *', but argument 2 has type 'bfd_size_type' [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:394:6: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c:405:9: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) amt, reason); ^ ../../binutils-2.26/binutils/readelf.c:405:9: error: format '%s' expects argument of type 'char *', but argument 2 has type 'bfd_size_type' [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:405:9: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c: In function 'get_dynamic_data': ../../binutils-2.26/binutils/readelf.c:10355:7: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) number, ent_size); ^ ../../binutils-2.26/binutils/readelf.c:10355:7: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'bfd_size_type' [-Werror=format=] ../../binutils-2.26/binutils/readelf.c:10355:7: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c:10364:7: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) number); ^ ../../binutils-2.26/binutils/readelf.c:10364:7: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c:10372:7: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) number); ^ ../../binutils-2.26/binutils/readelf.c:10372:7: error: too many arguments for format [-Werror=format-extra-args] ../../binutils-2.26/binutils/readelf.c:10379:7: error: unknown conversion type character 'l' in format [-Werror=format=] (unsigned long long) (number * ent_size)); ^ ../..
[Bug ld/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452 Cristian Gavril Olar changed: What|Removed |Added Attachment #9132|0 |1 is obsolete|| --- Comment #6 from Cristian Gavril Olar --- Created attachment 9135 --> https://sourceware.org/bugzilla/attachment.cgi?id=9135&action=edit binutils LD individual section selection patch suggestion I've been thinking a little bit more about this and I realized in the same application one can have both the problem of accidental overlaps but at the same time, in the same application have a need to create overlapped noload sections. A reference to this usecase was hinted I think previously when the text in the endnote of https://sourceware.org/ml/binutils/2009-05/msg00330.html . As a linker script evolves, one may have additions or changes to the linker script(s) used. If at some point one had enabled a general option to not warn anymore, one may still get later in trouble if a new section is accidentally overlapped. As a consequence I'm thinking that the previous suggestion should be changed a little bit to something of this sort: 1) By default LD should just not allow section overlapping of any sort but 2) During the checks, if a section overlapping is detected to be a NOLOAD section then LD, even if not linking, could display a message informing the user that they can consciously allow the overlap if they mark that particular NOLOAD section as possible to be overlapped 3) Provide an option to allow the overlap of a NOLOAD section as per the description at point "2)" Thinking about this problem I had thought of maybe adding an extra flag to the bfd_section structure may be one solution, but the bits in the flagword are pretty expensive I think to burn for this, so instead I thought of keeping a separate list in the bfd alive which holds the names of desired sections to be overlapped. In terms of how to specify which sections are possible to be overlapped, I thought of just overloading the use of "OVERLAY". But then I'm aware that OVERLAY is mostly just meant to be syntactic sugar (ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_22.html), and the way it is implemented it actually forced the sections to have the LOAD flag set. I think changing that may have too great an implication worldwide and I don't think it's worth it. Considering all of these I think the remaining option is to build the list of accepted NOLOAD sections to be overlapped a list of options in as command line arguments. This patch is suggesting one way of doing that. Additionally, if there is interest in this direction, I guess an additional improvement that could be done would be to add a ld script new option called "OVERLAP" or something similar that would allow the sections to be added to the accepted list in this fashion too. -- 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/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452 --- Comment #7 from Alan Modra --- Since there seems to be enough interest in this bug for people to actually write patches, here is what I think would work and be accepted: In lang_size_sections_1, near the comment "A backwards move of dot", set a static global var whenever seeing "dot < last->vma". This should flag all cases where overlays are used without false triggers. Modify lang_check_section_addresses to check for vma overlap when no overlays are detected. - Use IGNORE_SECTION again to choose interesting sections (the attached patch was wrong in treatment of .tbss) - In the existing lma checking loop, ignore !SEC_LOAD sections. Some rewriting might be necessary to elegantly handle the case of the first section being !SEC_LOAD. - Write another loop to check vmas if overlays not present -- 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/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452 --- Comment #8 from Cristian Gavril Olar --- Created attachment 9136 --> https://sourceware.org/bugzilla/attachment.cgi?id=9136&action=edit Additional possible suggestion with keyword in the linker script Another suggestion with similar structure as the one before, but with accepting an (OVERLAP) keyword to specify a section is acceptable to be overlapped via ld script syntax. Choice of the word or method could be changed if this ever gets adopted of course. Mostly here to suggest an idea. -- 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/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452 Cristian Gavril Olar changed: What|Removed |Added Attachment #9136|0 |1 is obsolete|| --- Comment #9 from Cristian Gavril Olar --- Created attachment 9137 --> https://sourceware.org/bugzilla/attachment.cgi?id=9137&action=edit ADDING OVERLAP keyword with IGNORESECTION (In reply to Alan Modra from comment #7) > Since there seems to be enough interest in this bug for people to actually > write patches, here is what I think would work and be accepted: > > In lang_size_sections_1, near the comment "A backwards move of dot", set a > static global var whenever seeing "dot < last->vma". This should flag all > cases where overlays are used without false triggers. > But this would detect all overlays. It still does not resolve the problem that some overlays are intentional and others are not. This depends on user choice. The fact that one section is or isn't !SEC_LOAD does not necessarily mean that that is a good case or a bad case. We'd be in the same situation as before the 2009 patch, would we not? > Modify lang_check_section_addresses to check for vma overlap when no > overlays are detected. > - Use IGNORE_SECTION again to choose interesting sections (the attached > patch was wrong in treatment of .tbss) Point taken. Reattaching last patch with IGNORE_SECTION back in there. Saw the original 2.24 source was still leaving it out so I left it out too, although I had noticed the difference and was a little bit curious why that define is still left in there for apparently no particular reason. > - In the existing lma checking loop, ignore !SEC_LOAD sections. Some > rewriting might be necessary to elegantly handle the case of the first > section being !SEC_LOAD. Not all !SEC_LOAD sections should be ignored either, or else we'd be in the same situation as we are today (well, almost). The problem is specifically marking which sections are intentional overlay vs which ones are not. The OVERLAY keyword is there, yes, but reading through the world knowledge base it has a different meaning right now so I would not recommend hijacking that keyword for this. > - Write another loop to check vmas if overlays not present This assumes that whoever has overlays intends to have his whole application accept all overlays, and only who does not have overlays at all accepts a clean application. I think these suggestions would be OK if the case would be that it is a general flag that is required to be detected, as per the very first patch submitted, but thinking more about things, I do not think that is true. The same application can have valid overlays and invalid ones, I cannot see any way around this other than allowing the user to specifically mark which ones are valid. -- 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/18452] ld allows overlapping sections
https://sourceware.org/bugzilla/show_bug.cgi?id=18452
--- Comment #10 from Cristian Gavril Olar ---
(In reply to Cristian Gavril Olar from comment #9)
> I think these suggestions would be OK if the case would be that it is a
> general flag that is required to be detected, as per the very first patch
> submitted, but thinking more about things, I do not think that is true. The
> same application can have valid overlays and invalid ones, I cannot see any
> way around this other than allowing the user to specifically mark which ones
> are valid.
But that being said, if there would be a way to use the existing ld script
commands to infer somehow an intentional overlap of noload sections that can
clearly show intention and could not happen by mistake in any way, it would
also be my preference to reuse existing syntax/options completely it is just
that I keep thinking about this and I cannot see any way with just the existing
options and syntax.
As far as I've noticed:
- OVERLAY creates SEC_LOAD sections rather than just allocated (and it has too,
in order to perform the function it needs with creation of the extra symbols)
- NOLOAD sections will not increment the LMA: and that is just, because
otherwise it would start eating up load memory in potentially ROM code
(undesirable), so one cannot force increments on NOLOAD sections. I'm
mentioning this particular point because I was initially considering that a
possibility of handling this would be to use the current syntax and specify
something of this sort:
/*Make sure on the data side of CMNlibs NOLOAD is used but addresses for data
sections are virtual*/
.some.bss 0x1C00 (NOLOAD) : AT (0xE000) {
*(S.bss*)
*(.__BSS__sect*)
}
.other.bss 0x1C00 (NOLOAD) : AT ( LOADADDR (.some.bss) + SIZEOF
(.some.bss) ) {
*(.other.S.bss*)
*(.other.__BSS__sect*)
}
In my initial opinion I thought this would be a good way to use the current
syntax to express intention of overlaps, and then just do LMA checks. But the
load address would not increment in this fashion. Initially I did not realize
why but reading this ticket and the links in it I realized it makes sense for
this to not work because NOLOAD sections cannot increment the LMA address, or
else, as the note in https://sourceware.org/ml/binutils/2009-05/msg00330.html
says: "Clearly we don't want an image of the bss section in ROM, and the .bss
section does not cause the advancement of the allocation point (the LMA)."
So it makes sense that LMA does not increase. But I think, at the same time,
this shows why with classic commands this problem of intentional vs accidental
use cannot be resolved without creating some sort of reinterpretation of the
commands which I think is not desirable.
But like I said: if it would help anyone, I'd be interested in trying to
provide patches/suggestions for a resolution to this problem of: detecting
accidental overlaps but allowing intentional ones with classic commands if
there is any way of doing that.
--
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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC||amodra at gmail dot com Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #2 from Alan Modra --- Actually, the memset removal was in 36e9d67. No mention in the changelog, so yes, quite likely removed by accident. I'll apply your patch after running a few tests. -- 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 --- Comment #3 from Toni Spets --- It was removed in this commit which bisect found as well, see the diff here: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=32a9d621c3c480aa093a089a36e36c35f68a4010;hp=022af27274b440186def92cae77c2d4304c3ce9b It didn't look like a merge commit either so was it removed, added back and then removed again? Anyway, the problem is exposed in bfd/peXXigen.c inside _bfd_XXi_swap_aouthdr_out where aouthdr_in->tsize and aouthdr_in->dsize are the uninitialized values left behind and the subtraction is made. -- 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e2b4fc913bad3b6a6e4b00b11c7c75268892150d commit e2b4fc913bad3b6a6e4b00b11c7c75268892150d Author: Toni Spets Date: Tue Mar 29 14:25:23 2016 +1030 PE/COFF regression in base of code and data calculation PR 19878 * coffcode.h (coff_write_object_contents): Revert accidental 2014-11-10 change. -- 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alan Modra --- Fixed, thanks! The commit you found was a backport to binutils-2_25-branch rather than a commit to master. -- 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 --- Comment #6 from Toni Spets --- Ah, that explains it. I bisected between binutils-2_24 and binutils-2_25. Is it possible to get this backported to 2.26? 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/19878] PE/COFF regression in base of code and data calculation
https://sourceware.org/bugzilla/show_bug.cgi?id=19878 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The binutils-2_26-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cf3db3d2451c68875f7a9f5b51e3d5ea3465aaa6 commit cf3db3d2451c68875f7a9f5b51e3d5ea3465aaa6 Author: Toni Spets Date: Tue Mar 29 14:25:23 2016 +1030 PE/COFF regression in base of code and data calculation PR 19878 * coffcode.h (coff_write_object_contents): Revert accidental 2014-11-10 change. -- 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
