.ARM.exidx RO data section is incorrectly mapped to data #12

RomainNaour · 2019-10-17T19:43:00Z

Hi,

Starting with Binutils 2.33.1, elf2flt segfault while building busybox:
"ld (ld-elf2flt):
/builds/kubu93/toolchains-builder/build/opt/armv7m--uclibc--bleeding-edge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt

This was reported to the Binutils mailing list and it's seems an elf2flt issue with .ARM.exidx RO data section as explained by :
https://sourceware.org/ml/binutils/2019-10/msg00132.html

Can you have a look ?

Best regards,
Romain

gregungerer · 2019-10-30T07:02:30Z

Hi Romain,

On 18/10/19 5:43 am, Romain Naour wrote: Starting with Binutils 2.33.1, elf2flt segfault while building busybox: "ld (ld-elf2flt): /builds/kubu93/toolchains-builder/build/opt/armv7m--uclibc--bleeding-edge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt This was reported to the Binutils mailing list and it's seems an elf2flt issue with .ARM.exidx RO data section as explained by : https://sourceware.org/ml/binutils/2019-10/msg00132.html Can you have a look ?

Ok, sure looks like a problem. I can reproduce it with binutils-2.33.1. Attached is a proposed fix. I have tested and confirmed it fixes the problem for arm targets. I still need to do further testing on other architecture targets though. Regards Greg

RomainNaour · 2019-11-03T22:12:03Z

Hi Greg,

Thanks for your reply.
But I didn't received your patch, can you send it again ?

Best regards,
Romain

gregungerer · 2019-11-04T12:48:59Z

Hi Romain,

On 4/11/19 8:12 am, Romain Naour wrote: Hi Greg, Thanks for your reply. But I didn't received your patch, can you send it again ?

I guess gitbub dropped the attachment. Here it is inline - hopefully not too white-space mangled. Regards Greg From 73325b7 Mon Sep 17 00:00:00 2001 From: Greg Ungerer <gerg@kernel.org> Date: Wed, 30 Oct 2019 16:08:19 +1000 Subject: [PATCH] elf2flt: fix relocations for read-only data Readonly data sections are mapped into the "text" section in the elf2flt.ld linker script. The relocation generation code is not handling that case properly though, and is actually mapping any data section type into the "data" section of the target binary. This problem case has been detected with elf2flt core dumping when used with binutils-2.33.1 (on ARM architecture targets). See thread at: https://sourceware.org/ml/binutils/2019-10/msg00132.html Signed-off-by: Greg Ungerer <gerg@kernel.org> --- elf2flt.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/elf2flt.c b/elf2flt.c index 67f720a..8973cef 100644 --- a/elf2flt.c +++ b/elf2flt.c @@ -418,10 +418,12 @@ output_relocs ( // continue; /* - * Only relocate things in the data sections if we are PIC/GOT. - * otherwise do text as well + * Only relocate things in the writable data sections if we are PIC/GOT. + * Otherwise do text (and read only data) as well. */ - if ((!pic_with_got || ALWAYS_RELOC_TEXT) && (a->flags & SEC_CODE)) + if ((!pic_with_got || ALWAYS_RELOC_TEXT) && + ((a->flags & SEC_CODE) || + ((a->flags & (SEC_DATA | SEC_READONLY)) == (SEC_DATA | SEC_READONLY)))) sectionp = text + (a->vma - text_vma); else if (a->flags & SEC_DATA) sectionp = data + (a->vma - data_vma); -- 2.17.1

cpriouzeau · 2019-11-06T14:42:39Z

Hi,
I just perform the test to use the patch for a build configured for ARM Cortex-M4
Test realised with:

binutils 2.33.1
buildroot 2019.11-rc1
patch on top of elf2flt (patch available on this thread)
configuration: stm32f469-disco with initramfs configuration on buildroot

Result:
Build: OK, all the binaries are generated
Runtime test on stm32f469-disco: OK

Best regards,
Christophe

…data Starting with Binutils 2.33.1, elf2flt segfault while building busybox: "ld (ld-elf2flt): /opt/armv7m--uclibc--bleeding-edge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt This was reported to the Binutils mailing list and it's seems an elf2flt issue with .ARM.exidx RO data section as explained by: https://sourceware.org/ml/binutils/2019-10/msg00132.html Apply the patch provided by Greg Ungerer [1] and tested by Christophe Priouzeau using stm32f469_disco_defconfig on stm32f469-disco board. Fixes: https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395300 [1] uclinux-dev/elf2flt#12 Signed-off-by: Romain Naour <romain.naour@smile.fr> Cc: Christophe Priouzeau <christophe.priouzeau@st.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

…data Starting with Binutils 2.33.1, elf2flt segfault while building busybox: "ld (ld-elf2flt): /opt/armv7m--uclibc--bleeding-edge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt This was reported to the Binutils mailing list and it's seems an elf2flt issue with .ARM.exidx RO data section as explained by: https://sourceware.org/ml/binutils/2019-10/msg00132.html Apply the patch provided by Greg Ungerer [1] and tested by Christophe Priouzeau using stm32f469_disco_defconfig on stm32f469-disco board. Fixes: https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395300 [1] uclinux-dev/elf2flt#12 Signed-off-by: Romain Naour <romain.naour@smile.fr> Cc: Christophe Priouzeau <christophe.priouzeau@st.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> (cherry picked from commit 2b064f8) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

…data Starting with Binutils 2.33.1, elf2flt segfault while building busybox: "ld (ld-elf2flt): /opt/armv7m--uclibc--bleeding-edge-2/arm-buildroot-uclinux-uclibcgnueabi/bin/elf2flt This was reported to the Binutils mailing list and it's seems an elf2flt issue with .ARM.exidx RO data section as explained by: https://sourceware.org/ml/binutils/2019-10/msg00132.html Apply the patch provided by Greg Ungerer [1] and tested by Christophe Priouzeau using stm32f469_disco_defconfig on stm32f469-disco board. Fixes: https://gitlab.com/kubu93/toolchains-builder/-/jobs/319395300 [1] uclinux-dev/elf2flt#12 Signed-off-by: Romain Naour <romain.naour@smile.fr> Cc: Christophe Priouzeau <christophe.priouzeau@st.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

RomainNaour · 2020-02-21T08:36:09Z

Hi,

It seems this patch introduce some regressions [1]

The toolchain is using gcc 8.3, binutils 2.32, uClibc-ng 1.0.32.

(verbose build while building binutils package)
Invoking: 'output/host/m68k-buildroot-uclinux-uclibc/bin/elf2flt' '-a' '-o' 'readelf' '-r' 'readelf.gdb'
ld (ld-elf2flt): output/host/m68k-buildroot-uclinux-uclibc/bin/elf2flt terminated with signal 11 [Segmentation fault], core dumped
collect2: error: ld returned 1 exit status

By running manually the elf2flt tool from the binutils build directory:

'output/host/m68k-buildroot-uclinux-uclibc/bin/elf2flt' '-a' '-o' 'readelf' '-r' 'readelf.gdb'
[...]
SECTION: .tm_clone_table [0x2185af0]: flags=0x123 vma=0x84384
RELOCS: .tm_clone_table [0x2185af0]: flags=0x123 vma=0x84384
SECTION: .eh_frame [0x2185c20]: flags=0x12f vma=0x84384
RELOCS: .eh_frame [0x2185c20]: flags=0x12f vma=0x84384
Segmentation fault (core dumped)

As far I can tell, the crash occur from elf2flt.c line 1569

If I remove this patch, the build complete correctly.

[1] http://lists.busybox.net/pipermail/buildroot/2020-February/274593.html
[2] https://github.com/uclinux-dev/elf2flt/blob/master/elf2flt.c#L1569

Best regards,
Romain

RomainNaour · 2020-02-22T00:01:49Z

Hello,
I proposed a patch [1] to avoid moving readonly .eh_frame section to "text" section.
Thoughts ?

[1] http://patchwork.ozlabs.org/patch/1242367/

vapier · 2020-02-22T00:59:14Z

just to be clear, buildroot is an unrelated project to elf2flt. patches need to be submitted here to be merged here.

that said, i have no idea about this particular bug with ARM.

The commit [1] moved readonly data sections to "text" section. This was needed to fix a elf2flt segfault on ARM architectures with Binutils >= 2.33.1. After this patch was applied to Buildroot's elf2flt package, new segfault appear while building several packages (acpica, augeas, binutils, cairo, fontconfig, gptfdisk, libopenssl, mimic...) [2]. We can reproduce the issue manually from the binutils build directory: 'output/host/m68k-buildroot-uclinux-uclibc/bin/elf2flt' '-a' '-o' 'readelf' '-r' 'readelf.gdb' While debuging, we can notice the flags value (0x12f) for .eh_frame just before the crash. RELOCS: .eh_frame [0x2185c20]: flags=0x12f vma=0x84384 /* bug case: flags = 0x12f (m68k) * SEC_HAS_CONTENTS 0x100 * SEC_DATA 0x020 * SEC_READONLY 0x008 * SEC_RELOC 0x004 * SEC_LOAD 0x002 * SEC_ALLOC 0x001 */ On ARM cortex-m4, we have the same flags: RELOCS: .ARM.exidx [0x9ac5b0]: flags=0x12f vma=0x4b4ec So due to the new condition introduced by [1] the .eh_frame section located in a readonly data section will be moved to the "text" section. Looking at the gcc code for m68k [3]: "Because .eh_frame refers to both code and data, it follows that .eh_frame must be in the data segment itself. [...] In theory, we could create a read-only .eh_frame [...]. However, gcc currently handles indirect references using a per-TU constant pool. This means that if a function and its eh_frame are removed by the linker, the eh_frame's indirect references to the removed function will not be removed, leading to an unresolved symbol error." Fix this crash by checking the section name and move .eh_frame section even if it is located in readonly data. [1] 73325b7 [2] http://lists.busybox.net/pipermail/buildroot/2020-February/274593.html [3] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/m68k.h;h=fc65e524b139a6d43e528956a788b9110aebaf2e;hb=a0c06cc27d2146b7d86758ffa236516c6143d62c#l785 [4] uclinux-dev#12 Signed-off-by: Romain Naour <romain.naour@smile.fr>

… BR2_BINFMT_FLAT The patch added by [1] to fix a segfault with elf2flt when binutils 2.33.1 is used on ARM, introduce a regression with previous binutils version on m68k and ARM. Theses issues has been reported upstreme [2] [3]. For now, disable binutils >= 2.33.1 for configurations using BR2_BINFMT_FLAT. [1] 2b064f8 [2] uclinux-dev/elf2flt#16 [3] uclinux-dev/elf2flt#12 Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

The patch added by [1] to fix a segfault with elf2flt when binutils 2.33.1 is used on ARM, introduce a regression with previous binutils version on m68k and ARM. Theses issues has been reported upstream [2] [3] but there is no definitive solution. The binutils 2.33.1 has been disabled for configurations using BR2_BINFMT_FLAT by the previous commit, so we can safely remove the patch. Fixes: [acpica-20191018] http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 [augeas-1.12.0] http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 [cairo-1.16.0] http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b [fontconfig-2.13.1] http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b [gptfdisk-1.0.4] http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 [libopenssl-1.1.1d] http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 [mimic-1.1.0] http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad Maybe more... [1] 2b064f8 [2] uclinux-dev/elf2flt#16 [3] uclinux-dev/elf2flt#12 Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

The patch added by [1] to fix a segfault with elf2flt when binutils 2.33.1 is used on ARM, introduce a regression with previous binutils version on m68k and ARM. Theses issues has been reported upstream [2] [3] but there is no definitive solution. The binutils 2.33.1 has been disabled for configurations using BR2_BINFMT_FLAT by the previous commit, so we can safely remove the patch. Fixes: [acpica-20191018] http://autobuild.buildroot.net/results/81ee33eb606062a62765d95b66a26f130d280c53 [augeas-1.12.0] http://autobuild.buildroot.net/results/4e1f7f335d2c853e2a5e6ad96c14157ba8f003c7 [cairo-1.16.0] http://autobuild.buildroot.net/results/976d99bc9b052f8d9429e666ac7fff7768ffff6b [fontconfig-2.13.1] http://autobuild.buildroot.net/results/4a5a8cb6411d709acb7ea8c83b3c8e45fdc0a10b [gptfdisk-1.0.4] http://autobuild.buildroot.net/results/6db5f9d8663730a54b04c1e624438095598b2573 [libopenssl-1.1.1d] http://autobuild.buildroot.net/results/acf87e81130e85e7fb05edf5f6dedf095f16e226 [mimic-1.1.0] http://autobuild.buildroot.net/results/61f53630ed85ee0d0d6dbf71012db77f4d7986ad Maybe more... [1] 2b064f8 [2] uclinux-dev/elf2flt#16 [3] uclinux-dev/elf2flt#12 Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> (cherry picked from commit aa36227) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

Rebase existing patches. Keep BR2_BINFMT_FLAT disabled for binutils 2.34 since elf2flt issue is not fixed [1] [2]. [1] uclinux-dev/elf2flt#16 [2] uclinux-dev/elf2flt#12 See announce: https://lists.gnu.org/archive/html/info-gnu/2020-02/msg00000.html Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

I believe a bug was introduced in commit [1], which was done to move the .ARM.exidx input section from .data to .text output section. However, in doing so, the dynamic memory allocation for .text [elf2flt.c:~L1907: 'text = xmalloc(text_len);'] was not modified to allow for the additional .ARM.exidx section. The result was that most of the time malloc() allocated enough extra memory [due to page-size or similar allocation boundaries] such that a small additional section went unnoticed. However, in unlucky cases, the memory required for just the .text section fit almost perfectly within an allocation boundary, and the extra .ARM.exidx section exceeded the allocation, and thus produced a segfault when the memory was written. The fix here modifies the calculation of 'text_len' in main() with logic similar to that of the original fix in [1] to output_relocs(), such that the correct amount of memory is allocated. The code is also modified such that 'data_len' is also calculated correctly, and does not over-allocate memory. This is necessary because the logic in main() is not a single grouping of if-elseif... priority logic as in output_relocs(). The change also attempts to be even more specific with input section selections for .text and .data output sections. .text is only selected for input sections flagged as (SEC_CODE || (SEC_DATA && SEC_READONLY && SEC_RELOC)) .data is only selected for input sections flagged as (SEC_DATA && !(SEC_READONLY && SEC_RELOC)) The change appears to work correctly for previously segfault-causing ELF with these processed sections... SEC_FLAGS:0x0000011f SEC_NAME:.text SEC_FLAGS:0x0000012f SEC_NAME:.ARM.exidx SEC_FLAGS:0x00000127 SEC_NAME:.data SEC_FLAGS:0x00000123 SEC_NAME:.tm_clone_table SEC_FLAGS:0x0000012b SEC_NAME:.eh_frame SEC_FLAGS:0x00000001 SEC_NAME:.bss SEC_FLAGS:0x00000100 SEC_NAME:.stack SEC_FLAGS:0x01800108 SEC_NAME:.comment SEC_FLAGS:0x00000108 SEC_NAME:.ARM.attributes SEC_FLAGS:0x0000210c SEC_NAME:.debug_aranges SEC_FLAGS:0x0000210c SEC_NAME:.debug_info SEC_FLAGS:0x00002108 SEC_NAME:.debug_abbrev SEC_FLAGS:0x0000210c SEC_NAME:.debug_line SEC_FLAGS:0x0000210c SEC_NAME:.debug_frame SEC_FLAGS:0x01802108 SEC_NAME:.debug_str SEC_FLAGS:0x0000210c SEC_NAME:.debug_loc SEC_FLAGS:0x00002108 SEC_NAME:.debug_ranges It should also be pointed out that this commit may impact the regression noted in [2] and pull-request [3]. With this code change in place, elf2flt will put section .eh_frame with flags=0x12b in the .data output section. If the flags for an .eh_frame section were 0x12f (same as .ARM.exidx), then it would end up in .text output section. A few cosmetic changes are included as well. [1] uclinux-dev@73325b7 [2] uclinux-dev#12 [3] uclinux-dev#16

I believe a bug was introduced in commit [1], which was done to move the .ARM.exidx input section from .data to .text output section. However, in doing so, the dynamic memory allocation for .text [elf2flt.c:~L1907: 'text = xmalloc(text_len);'] was not modified to allow for the additional .ARM.exidx section. The result was that most of the time malloc() allocated enough extra memory [due to page-size or similar allocation boundaries] such that a small additional section went unnoticed. However, in unlucky cases, the memory required for just the .text section fit almost perfectly within an allocation boundary, and the extra .ARM.exidx section exceeded the allocation, and thus produced a segfault when the memory was written. The fix here modifies the calculation of 'text_len' in main() with logic similar to that of the original fix in [1] to output_relocs(), such that the correct amount of memory is allocated. The code is also modified such that 'data_len' is also calculated correctly, and does not over-allocate memory. This is necessary because the logic in main() is not a single grouping of if-elseif... priority logic as in output_relocs(). The change also attempts to be even more specific with input section selections for .text and .data output sections. .text is only selected for input sections flagged as (SEC_CODE || (SEC_DATA && SEC_READONLY && SEC_RELOC)) .data is only selected for input sections flagged as (SEC_DATA && !(SEC_READONLY && SEC_RELOC)) The change appears to work correctly for previously segfault-causing ELF with these processed sections... SEC_FLAGS:0x0000011f SEC_NAME:.text SEC_FLAGS:0x0000012f SEC_NAME:.ARM.exidx SEC_FLAGS:0x00000127 SEC_NAME:.data SEC_FLAGS:0x00000123 SEC_NAME:.tm_clone_table SEC_FLAGS:0x0000012b SEC_NAME:.eh_frame SEC_FLAGS:0x00000001 SEC_NAME:.bss SEC_FLAGS:0x00000100 SEC_NAME:.stack SEC_FLAGS:0x01800108 SEC_NAME:.comment SEC_FLAGS:0x00000108 SEC_NAME:.ARM.attributes SEC_FLAGS:0x0000210c SEC_NAME:.debug_aranges SEC_FLAGS:0x0000210c SEC_NAME:.debug_info SEC_FLAGS:0x00002108 SEC_NAME:.debug_abbrev SEC_FLAGS:0x0000210c SEC_NAME:.debug_line SEC_FLAGS:0x0000210c SEC_NAME:.debug_frame SEC_FLAGS:0x01802108 SEC_NAME:.debug_str SEC_FLAGS:0x0000210c SEC_NAME:.debug_loc SEC_FLAGS:0x00002108 SEC_NAME:.debug_ranges It should also be pointed out that this commit may impact the regression noted in [2] and pull-request [3]. With this code change in place, elf2flt will put section .eh_frame with flags=0x12b in the .data output section. If the flags for an .eh_frame section were 0x12f (same as .ARM.exidx), then it would end up in .text output section. A few cosmetic changes are included as well. [1] uclinux-dev@73325b7 [2] uclinux-dev#12 [3] uclinux-dev#16 Signed-off-by: Mike Pilawa <Mike.Pilawa@csiro.au>

I believe a bug was introduced in commit [1], which was done to move the .ARM.exidx input section from .data to .text output section. However, in doing so, the dynamic memory allocation for .text [elf2flt.c:~L1907: 'text = xmalloc(text_len);'] was not modified to allow for the additional .ARM.exidx section. The result was that most of the time malloc() allocated enough extra memory [due to page-size or similar allocation boundaries] such that a small additional section went unnoticed. However, in unlucky cases, the memory required for just the .text section fit almost perfectly within an allocation boundary, and the extra .ARM.exidx section exceeded the allocation, and thus produced a segfault when the memory was written. The fix here modifies the calculation of 'text_len' in main() with logic similar to that of the original fix in [1] to output_relocs(), such that the correct amount of memory is allocated. The code is also modified such that 'data_len' is also calculated correctly, and does not over-allocate memory. This is necessary because the logic in main() is not a single grouping of if-elseif... priority logic as in output_relocs(). The change also attempts to be even more specific with input section selections for .text and .data output sections. .text is only selected for input sections flagged as (SEC_CODE || (SEC_DATA && SEC_READONLY && SEC_RELOC)) .data is only selected for input sections flagged as (SEC_DATA && !(SEC_READONLY && SEC_RELOC)) The change appears to work correctly for previously segfault-causing ELF with these processed sections... SEC_FLAGS:0x0000011f SEC_NAME:.text SEC_FLAGS:0x0000012f SEC_NAME:.ARM.exidx SEC_FLAGS:0x00000127 SEC_NAME:.data SEC_FLAGS:0x00000123 SEC_NAME:.tm_clone_table SEC_FLAGS:0x0000012b SEC_NAME:.eh_frame SEC_FLAGS:0x00000001 SEC_NAME:.bss SEC_FLAGS:0x00000100 SEC_NAME:.stack SEC_FLAGS:0x01800108 SEC_NAME:.comment SEC_FLAGS:0x00000108 SEC_NAME:.ARM.attributes SEC_FLAGS:0x0000210c SEC_NAME:.debug_aranges SEC_FLAGS:0x0000210c SEC_NAME:.debug_info SEC_FLAGS:0x00002108 SEC_NAME:.debug_abbrev SEC_FLAGS:0x0000210c SEC_NAME:.debug_line SEC_FLAGS:0x0000210c SEC_NAME:.debug_frame SEC_FLAGS:0x01802108 SEC_NAME:.debug_str SEC_FLAGS:0x0000210c SEC_NAME:.debug_loc SEC_FLAGS:0x00002108 SEC_NAME:.debug_ranges It should also be pointed out that this commit may impact the regression noted in [2] and pull-request [3]. With this code change in place, elf2flt will put section .eh_frame with flags=0x12b in the .data output section. If the flags for an .eh_frame section were 0x12f (same as .ARM.exidx), then it would end up in .text output section. A few cosmetic changes are included as well. [1] 73325b7 [2] #12 [3] #16 Signed-off-by: Mike Pilawa <Mike.Pilawa@csiro.au>

vapier · 2023-04-25T05:23:57Z

i think Greg fixed this now with recent commits

RomainNaour closed this as completed Feb 5, 2020

RomainNaour reopened this Feb 21, 2020

RomainNaour mentioned this issue Feb 22, 2020

elf2flt: fix relocations for read-only .eh_frame section #16

Closed

mpilawa mentioned this issue Nov 8, 2020

elf2flt: fix for segfault on some ARM ELFs #20

Merged

vapier closed this as completed Apr 25, 2023

vapier added the bug label Apr 25, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

.ARM.exidx RO data section is incorrectly mapped to data #12

.ARM.exidx RO data section is incorrectly mapped to data #12

RomainNaour commented Oct 17, 2019

gregungerer commented Oct 30, 2019 via email

RomainNaour commented Nov 3, 2019

gregungerer commented Nov 4, 2019 via email

cpriouzeau commented Nov 6, 2019

RomainNaour commented Feb 21, 2020

RomainNaour commented Feb 22, 2020

vapier commented Feb 22, 2020

vapier commented Apr 25, 2023

.ARM.exidx RO data section is incorrectly mapped to data #12

.ARM.exidx RO data section is incorrectly mapped to data #12

Comments

RomainNaour commented Oct 17, 2019

gregungerer commented Oct 30, 2019 via email

RomainNaour commented Nov 3, 2019

gregungerer commented Nov 4, 2019 via email

cpriouzeau commented Nov 6, 2019

RomainNaour commented Feb 21, 2020

RomainNaour commented Feb 22, 2020

vapier commented Feb 22, 2020

vapier commented Apr 25, 2023