[Bug binutils/29262] A Potential Memory Leak Bug
https://sourceware.org/bugzilla/show_bug.cgi?id=29262 --- Comment #3 from yuxuan He <1157401338 at qq dot com> --- (In reply to Alan Modra from comment #2) > Fixed. Thank you. -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- (In reply to John David Anglin from comment #0) Hi David, > /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing > .note.GNU-stack section implies executable stack > The first warning seems bogus as crtn.o is not an executable file. But it is an object file which is being linked with others to create an executable file. The logic of the .note.GNU-stack section is that its permissions (read/write/execute) define the permissions needed of the stack segment in the final executable. Permissions from different .note-GNU-stack sections in different input object files are ORed together. In addition, if the section is missing from any of the input object files then the target specific default permissions are assumed. For the HPPA architecture the default permissions are read, write and execute. Hence if the .note.GNU-stack section is missing from *any* input object file the resulting HPPA executable will end up with an executable stack segment. This is of course a potential security issue. > /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a > future version of the linker The point of this message is that we are considering changing the behaviour of the linker so that all targets default to just read/write for their stacks, and that executable stacks have to be explicitly requested via the .note.GNU-stack mechanism. (This would match the behaviour of the lld linker). > On hppa-linux with kernel v5.18 and later, we don't need an executable > stack for signal support but we still need it for gcc nested functions. This is already handled by gcc. If an executable stack is needed in order to support nested functions (or more probably, taking the address of a nested function), then gcc will generate a .note.GNU-stack section with the read, write and execute permissions set. The linker will then obligingly create an executable stack segment. You will still get a warning message however, since the issue of executable stacks is still present, albeit for a different reason. The linker's warnings can be suppressed however, either via a run-time command line option: --no-warn-execstack or a build-time configure option: --enable-warn-execstack=no. Is this sufficient ? We could change the configuration option so that it defaults to disabling the warnings if the target is the HPPA, but I would prefer not to do that, as it means that a potential security vulnerability will be ignored by default. Cheers Nick -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #3 from dave.anglin at bell dot net --- On 2022-06-20 7:13 a.m., nickc at redhat dot com wrote: >> On hppa-linux with kernel v5.18 and later, we don't need an executable >> stack for signal support but we still need it for gcc nested functions. > This is already handled by gcc. If an executable stack is needed in order to > support nested functions (or more probably, taking the address of a nested > function), then gcc will generate a .note.GNU-stack section with the read, > write and execute permissions set. The linker will then obligingly create an > executable stack segment. You will still get a warning message however, since > the issue of executable stacks is still present, albeit for a different > reason. Unfortunately, this doesn't happen on hppa-linux because we have: /* It's not possible to enable GNU_stack notes since the kernel needs an executable stack for signal returns and syscall restarts. */ #undef NEED_INDICATE_EXEC_STACK #define NEED_INDICATE_EXEC_STACK 0 I can't just enable the generation of GNU_stack notes since old kernels are still prevalent. > > > The linker's warnings can be suppressed however, either via a run-time command > line option: --no-warn-execstack or a build-time configure option: > --enable-warn-execstack=no. --no-warn-execstack doesn't suppress all the warnings: dave@mx3210:~/shmat$ gcc main.c -Wl,--no-warn-execstack /usr/bin/ld: warning: a.out has a LOAD segment with RWX permissions > > > Is this sufficient ? We could change the configuration option so that it > defaults to disabling the warnings if the target is the HPPA, but I would > prefer not to do that, as it means that a potential security vulnerability > will > be ignored by default. There is no way to fix the issue on hpux. On linux, I believe the warning causes issues with some debian package builds. For example, it looks like a recent build of akonadi failed due to the warning: [ 0%] Linking CXX shared library ../../bin/sqldrivers/libqsqlite3.so cd /<>/obj-hppa-linux-gnu/src/qsqlite && /usr/bin/cmake -E cmake_link_script CMakeFiles/qsqlite3.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Werror=init-self -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -pedantic -Wzero-as-null-pointer-constant -Wmissing-include-dirs -Wnon-virtual-dtor -Wundef -Wcast-align -Wchar-subscripts -Wall -Wextra -Wpointer-arith -Wformat-security -fno-common -pedantic -Wno-deprecated-copy -fexceptions -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags -shared -Wl,-soname,libqsqlite3.so -o ../../bin/sqldrivers/libqsqlite3.so CMakeFiles/qsqlite3.dir/qsqlite3_autogen/mocs_compilation.cpp.o CMakeFiles/qsqlite3.dir/src/sqlite_blocking.cpp.o CMakeFiles/qsqlite3.dir/src/qsql_sqlite.cpp.o CMakeFiles/qsqlite3.dir/src/smain.cpp.o /usr/lib/hppa-linux-gnu/libQt5Sql.so.5.15.4 /usr/lib/hppa-linux-gnu/libsqlite3.so /usr/lib/hppa-linux-gnu/libQt5Core.so.5.15.4 /usr/bin/ld: warning: /usr/lib/gcc/hppa-linux-gnu/11/../../../hppa-linux-gnu/crtn.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: ../../bin/sqldrivers/libqsqlite3.so has a LOAD segment with RWX permissions collect2: error: ld returned 1 exit status make[3]: *** [src/qsqlite/CMakeFiles/qsqlite3.dir/build.make:149: bin/sqldrivers/libqsqlite3.so] Error 1 What is best way to transition without causing a lot of disruption? Regards, Dave -- 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
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 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
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
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #7 from Nick Clifton --- Created attachment 14152 --> https://sourceware.org/bugzilla/attachment.cgi?id=14152&action=edit Proposed Patch -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #6 from Nick Clifton --- (In reply to dave.anglin from comment #3) Hi Dave, > Unfortunately, this doesn't happen on hppa-linux because we have: > > /* It's not possible to enable GNU_stack notes since the kernel needs > an executable stack for signal returns and syscall restarts. */ > > #undef NEED_INDICATE_EXEC_STACK > #define NEED_INDICATE_EXEC_STACK 0 > I can't just enable the generation of GNU_stack notes since old kernels are > still prevalent. OK, so if you need to support older kernels, then is it possible for you to use the configure option --enable-warn-execstack=no instead ? > --no-warn-execstack doesn't suppress all the warnings: > > dave@mx3210:~/shmat$ gcc main.c -Wl,--no-warn-execstack > /usr/bin/ld: warning: a.out has a LOAD segment with RWX permissions That warning can be disabled with --no-warn-rwx-segments and disabled by configuring with --enable-warn-rwx-segments=no > What is best way to transition without causing a lot of disruption? How about a patch like the one I am about to upload ? It sets the defaults for these two warnings to 'ignore' for HPPA targets. (I do not know if it is possible to determine the kernel version from the configuration string, so the patch changes the default for all HPPA variants). -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #8 from dave.anglin at bell dot net --- On 2022-06-20 11:42 a.m., hp at sourceware dot org wrote: > 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. Thanks H.P. for the hint. The problem is the .plt and the implementation of dynamic binding. For that, the PLT needs to be executable. Dave -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #9 from dave.anglin at bell dot net --- On 2022-06-20 12:37 p.m., nickc at redhat dot com wrote: >> What is best way to transition without causing a lot of disruption? > How about a patch like the one I am about to upload ? It sets the defaults > for > these two warnings to 'ignore' for HPPA targets. (I do not know if it is > possible to determine the kernel version from the configuration string, so the > patch changes the default for all HPPA variants). Sounds like the best option for now. Thanks, Dave -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=29263 --- Comment #10 from dave.anglin at bell dot net --- On 2022-06-20 12:38 p.m., nickc at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=29263 > > --- Comment #7 from Nick Clifton --- > Created attachment 14152 >--> https://sourceware.org/bugzilla/attachment.cgi?id=14152&action=edit > Proposed Patch > I believe the RWX warning comes from the second LOAD segment. It needs to be executable because of trampoline at the end of the PLT. Maybe second comment in patch could be adjusted. dave@mx3210:~/shmat$ readelf -a a.out Version: 0x1 Entry point address: 0x10334 Start of program headers: 52 (bytes into file) Start of section headers: 6804 (bytes into file) Flags: 0x210, PA-RISC 1.1 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 7 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 29 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .interp PROGBITS 00010114 000114 0d 00 A 0 0 1 [ 2] .note.gnu.bu[...] NOTE 00010124 000124 24 00 A 0 0 4 [ 3] .note.ABI-tag NOTE 00010148 000148 20 00 A 0 0 4 [ 4] .hash HASH 00010168 000168 2c 04 A 6 0 4 [ 5] .gnu.hash GNU_HASH 00010194 000194 20 04 A 6 0 4 [ 6] .dynsym DYNSYM 000101b4 0001b4 60 10 A 7 1 4 [ 7] .dynstr STRTAB 00010214 000214 82 00 A 0 0 1 [ 8] .gnu.version VERSYM 00010296 000296 0c 02 A 6 0 2 [ 9] .gnu.version_r VERNEED 000102a4 0002a4 20 00 A 7 1 4 [10] .rela.plt RELA 000102c4 0002c4 30 0c AI 6 23 4 [11] .init PROGBITS 000102f4 0002f4 2c 00 AX 0 0 4 [12] .text PROGBITS 00010320 000320 0004e0 00 AX 0 0 4 [13] .fini PROGBITS 00010800 000800 28 00 AX 0 0 4 [14] .rodata PROGBITS 00010828 000828 1c 00 A 0 0 4 [15] .PARISC.unwind PROGBITS 00010844 000844 000100 04 AI 0 12 4 [16] .eh_frame PROGBITS 00010944 000944 04 00 A 0 0 4 [17] .init_array INIT_ARRAY 00011000 001000 04 04 WA 0 0 1 [18] .ctors PROGBITS 00011004 001004 08 00 WA 0 0 4 [19] .dtors PROGBITS 0001100c 00100c 08 00 WA 0 0 4 [20] .data.rel.ro PROGBITS 00011014 001014 04 00 WA 0 0 4 [21] .dynamic DYNAMIC 00011018 001018 c8 08 WA 7 0 4 [22] .data PROGBITS 000110e0 0010e0 08 00 WA 0 0 4 [23] .plt PROGBITS 000110e8 0010e8 5c 00 WAX 0 0 8 [24] .got PROGBITS 00011144 001144 1c 04 WA 0 0 4 [25] .bss NOBITS 00011160 001160 10 00 WA 0 0 4 [26] .comment PROGBITS 001160 1e 01 MS 0 0 1 [27] .symtab SYMTAB 001180 000570 10 28 65 4 [28] .strtab STRTAB 0016f0 0002a1 00 0 0 1 [29] .shstrtab STRTAB 001991 000100 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), R (retain), D (mbind), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x00010034 0x00010034 0x000e0 0x000e0 R 0x4 INTERP 0x000114 0x00010114 0x00010114 0xd 0xd R 0x1 [Requesting program interpreter: /lib/ld.so.1] LOAD 0x00 0x0001 0x0001 0x00948 0x00948 R E 0x1000 LOAD 0x001000 0x00011000 0x00011000 0x00160 0x00170 RWE 0x1000 DYNAMIC 0x001018 0x00011018 0x00011018 0x000c8 0x000c8 RW 0x4 NOTE 0x000124 0x00010124 0x00010124 0x00044 0x00044 R 0x4 GNU_STACK 0x00 0x 0x 0x0 0x0 RWE 0x10 Dave -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29266] New: readelf ..info misreports DW_FORM_strxN
https://sourceware.org/bugzilla/show_bug.cgi?id=29266 Bug ID: 29266 Summary: readelf ..info misreports DW_FORM_strxN Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 14153 --> https://sourceware.org/bugzilla/attachment.cgi?id=14153&action=edit Test binary and sources Consider the debug information in the attached binary. It consists of two compilation units - foo.cpp and bar.cpp. Run "readelf --debug-dump=info foo" with the latest master as of 2022-06-20. It reports the value of DW_AT_name as "foo.cpp" for both compilation units. That can't be right. Internally, it looks as if the logic of resolving DW_FORM_strx, DW_FORM_strx1..4 form attributes looks into the portion of the debug_str_offsets section that pertains to the top CU as opposed to the current CU. Elsewhere, it also causes numerous bogus warnings like "DW_FORM_GNU_str_index offset too big: 0x1350 vs 0xbf0", where the str_offset count in the current CU is greater than that in the top CU. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29268] New: readelf misinterprets register rule inheritance from CIE to FDE
https://sourceware.org/bugzilla/show_bug.cgi?id=29268 Bug ID: 29268 Summary: readelf misinterprets register rule inheritance from CIE to FDE Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 14154 --> https://sourceware.org/bugzilla/attachment.cgi?id=14154&action=edit Test binary Consider the debug info attached binary. The binary's first FDE in .eh_frame has initial_location 0x1060, and the following instructions: DW_CFA_advance_loc 4# Move PC by 4 DW_CFA_undefined 16 # Change the rule for R16 to undefined The linked CIE marks R16 as the return address, and has the following instructions: DW_CFA_def_cfa 7, 8# CFA is at R7+8 DW_CFA_offset 16, 1# Set the rule for R16 to [CFA+1*data_aligment_factor]) The GNU readelf, if executed with --debug-dump=frames-interp, dumps the FDE as follows: 0018 0014 001c FDE cie= pc=1060..1086 LOC CFA ra 1060 rsp+8u 1064 rsp+8u Meanwhile, an alternative parser thinks that at the range [0x1060-0x1064), the rule for RA/R16 should be as inherited from the CIE, and it goes c-8. I've debugged readelf (the latest master, as of 06/01/22), to that point. There are two passes over the FDE instructions: one starting on dwarf.c:9296, the other starting at dwarf.c:9442. On the first pass, when DW_CFA_undefined is encountered, there is the following case statement: READ_ULEB (reg, start, block_end); if (frame_need_space (fc, reg) >= 0) fc->col_type[reg] = DW_CFA_undefined; break; If I understand correctly, the intended purpose of the first pass is to allocate enough memory in the fc->col_type and fc->col_offset arrays, and the logic of this operator's handling was meant to be: if this register was not mentioned before, allocate space for it, and reset its rule to undefined. HOWEVER, if the register WAS mentioned before (e. g. in the CIE), frame_need_space() returns 0, and the if() body executes anyway, and resets the rule for the register to undefined, erasing the initial state as specified by the CIE. I think the if statement should go, instead, "if (frame_need_space (fc, reg) > 0)". Same for other register-rule-type operators on the first pass. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29266] readelf ..info misreports DW_FORM_strxN
https://sourceware.org/bugzilla/show_bug.cgi?id=29266 --- Comment #1 from Vsevolod Alekseyev --- Additional info: when parsing the attribute at offset 0x54, the first strx one in the second CU, and fetch_indexed_string is invoked, the value of the this_set parameter, which I believe is supposed to point at the CU header within debug_str_offsets, is still 0. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 45897 in oss-fuzz: binutils:fuzz_as: Timeout in fuzz_as
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #3 on issue 45897 by sheriffbot: binutils:fuzz_as: Timeout in fuzz_as https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45897#c3 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 46099 in oss-fuzz: binutils:fuzz_as: Unexpected-exit in xexit
Updates: Labels: Deadline-Approaching Comment #2 on issue 46099 by sheriffbot: binutils:fuzz_as: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=46099#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/29267] New: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx
https://sourceware.org/bugzilla/show_bug.cgi?id=29267 Bug ID: 29267 Summary: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- When readelf --debug-dump=info prints attributes of type DW_FORM_loclistx, DW_FORM_rnglistx, it prints what should be the offset of the loclist/rangelist in the respective section. The raw value of this attribute is supposed to be an index into the offsets table in the compilation unit header inside the debug_loclists or debug_rnglists sections, respectively, while the address of the offset table itself should be taken from the DW_AT_loclists_base or DW_AT_rnglists_base, respecively, in the CU's top DIE. But it looks like readelf looks up the offset in the debug_addr section, instead of debug_loclists/debug_rnglists section. This even causes warnings of type "Offset into section .debug_addr too big:", because the offset was never meant to be in .debug_addr. I've got a repro for that from clang++-11, but it's big. I'll try to find a smaller one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29270] New: Signed integer overflow with DW_FORM_udata
https://sourceware.org/bugzilla/show_bug.cgi?id=29270 Bug ID: 29270 Summary: Signed integer overflow with DW_FORM_udata Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sevaa at sprynet dot com Target Milestone: --- Created attachment 14155 --> https://sourceware.org/bugzilla/attachment.cgi?id=14155&action=edit Test binary and source Consider the debug info in the attached binary. If you execute "readelf --debug-dump udata", you'll see the following line: <2f> DW_AT_const_value : -9223372036854775808 The form of that attribute is DW_FORM_udata. It's unsigned and positive, the minus is bogus. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29250] readelf erases CIE initial register state
https://sourceware.org/bugzilla/show_bug.cgi?id=29250 Vsevolod Alekseyev changed: What|Removed |Added CC||sevaa at sprynet dot com --- Comment #5 from Vsevolod Alekseyev --- *** Bug 29268 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29268] readelf misinterprets register rule inheritance from CIE to FDE
https://sourceware.org/bugzilla/show_bug.cgi?id=29268 Vsevolod Alekseyev changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Vsevolod Alekseyev --- Oops, duplicate of 29250, sorry. *** This bug has been marked as a duplicate of bug 29250 *** -- You are receiving this mail because: You are on the CC list for the bug.
