Bug 41533 - ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: c++
4.4.1
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-01 08:01 UTC by Kirill A. Shutemov
Modified: 2009-10-05 19:34 UTC (History)
2 users (show)

See Also:
Host: arm-none-linux-gnueabi
Target: arm-none-linux-gnueabi
Build: arm-none-linux-gnueabi
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Implement ASM_PREFERRED_EH_DATA_FORMAT macros for ARM (693 bytes, patch)
2009-10-01 08:02 UTC, Kirill A. Shutemov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill A. Shutemov 2009-10-01 08:01:17 UTC
This macro chooses the encoding of pointers embedded in the exception handling sections.
    
It needed to generate correct .cfi_personality derective. Without it we always have TEXTREL in C++ shared libraries and PIE, if it compiled with exceptions.
Comment 1 Kirill A. Shutemov 2009-10-01 08:02:42 UTC
Created attachment 18686 [details]
Implement ASM_PREFERRED_EH_DATA_FORMAT macros for ARM

This macro chooses the encoding of pointers embedded in the exception
handling sections.

It needed to generate correct .cfi_personality derective. Without it we
always have TEXTREL in C++ shared libraries and PIE, if it compiled
with exceptions.

Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Comment 2 Uroš Bizjak 2009-10-01 08:21:25 UTC
Patches should be posted to gcc-patches mailing list.

BTW: Where is the bug in your PR submission?
Comment 3 Jakub Jelinek 2009-10-01 08:37:29 UTC
AFAIK arm*-*-linux*eabi uses its own unwinding format, so it shouldn't be using .cfi_* directives at all.  It should force -fno-dwarf2-cfi-asm...
Comment 4 Ramana Radhakrishnan 2009-10-01 09:02:09 UTC
Is it correct to generate .eh_frame for the arm-linux-gnueabi target ? Shouldn't this rather be the ARM EABI exception handling tables instead ? 

-fno-dwarf2-cfi-asm might be a workaround. I've seen a couple of bug reports where this was the problem.

cheers
Ramana


Comment 5 Kirill A. Shutemov 2009-10-01 10:07:24 UTC
Ok. If .eh_frame should not be generated on ARM, we should to modify dwarf2out_do_cfi_asm() to always return false on ARM. Right?
Comment 6 Ramana Radhakrishnan 2009-10-01 10:54:24 UTC
(In reply to comment #5)
> Ok. If .eh_frame should not be generated on ARM, we should to modify
> dwarf2out_do_cfi_asm() to always return false on ARM. Right?
> 

Look at this patch submitted here. Can you try this to see if it works for you ? http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00022.html
Comment 7 Kirill A. Shutemov 2009-10-01 11:08:53 UTC
Looks ok for me.

I'll test it, but it takes some time. I'll report results tomorrow.

This patch also fixes #40521, I guess.
Comment 8 Kirill A. Shutemov 2009-10-02 07:34:33 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Ok. If .eh_frame should not be generated on ARM, we should to modify
> > dwarf2out_do_cfi_asm() to always return false on ARM. Right?
> > 
> 
> Look at this patch submitted here. Can you try this to see if it works for you
> ? http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00022.html
> 

No, it doesn't help.

$ cat 1.cc
void m(){}
$ gcc-4.4  -S 1.cc 
$ cat 1.s
        .cpu arm9tdmi
        .fpu softvfp
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
        .eabi_attribute 24, 1
        .eabi_attribute 25, 1
        .eabi_attribute 26, 2
        .eabi_attribute 30, 6
        .eabi_attribute 18, 4
        .file   "1.cc"
        .text
        .align  2
        .global _Z1mv
        .type   _Z1mv, %function
_Z1mv:
        .fnstart
.LFB0:
        .cfi_startproc
        .cfi_personality 0x0,__gxx_personality_v0
        @ Function supports interworking.
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        @ link register save eliminated.
        str     fp, [sp, #-4]!
        .cfi_def_cfa_offset 4
        add     fp, sp, #0
        .cfi_offset 11, -4
        .cfi_def_cfa_register 11
        add     sp, fp, #0
        ldmfd   sp!, {fp}
        bx      lr
        .cfi_endproc
.LFE0:
        .cantunwind
        .fnend
        .size   _Z1mv, .-_Z1mv
        .ident  "GCC: (GNU) 4.4.1 20090725 (ALT Linux 4.4.1-alt1)"
        .section        .note.GNU-stack,"",%progbits
Comment 9 Ramana Radhakrishnan 2009-10-02 08:26:17 UTC
(In reply to comment #8)

Are you testing the correct compiler  ? After building my 4.4 tree (though a cross compiler ) I see the code generated as below.  

The only reason why this might not work is if you are trying to build an arm-linux and not an arm-linux-gnueabi toolchain but your bug report indicates otherwise.

As you can see there are no .cfi_* directives. 

        .cpu arm10tdmi
        .fpu softvfp
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
        .eabi_attribute 24, 1
        .eabi_attribute 25, 1
        .eabi_attribute 26, 2
        .eabi_attribute 30, 2
        .eabi_attribute 18, 4
        .file   "1.cc"
        .text
        .align  2
        .global main
        .type   main, %function
main:
        .fnstart
.LFB0:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        mov     r0, #0
        bx      lr
.LFE0:
        .cantunwind
        .fnend
        .size   main, .-main
        .ident  "GCC: (GNU) 4.4.2 20091002 (prerelease) [trunk revision 152368]"
        .section        .note.GNU-stack,"",%progbits
Comment 10 Kirill A. Shutemov 2009-10-02 09:06:56 UTC
(In reply to comment #9)
> (In reply to comment #8)
> 
> Are you testing the correct compiler  ?

Yes.

> After building my 4.4 tree (though a
> cross compiler ) I see the code generated as below.  
> 
> The only reason why this might not work is if you are trying to build an
> arm-linux and not an arm-linux-gnueabi toolchain but your bug report indicates
> otherwise.

$ gcc-4.4 -dumpmachine
arm-alt-linux-gnueabi

> As you can see there are no .cfi_* directives. 

Do you use c++ compiler with enabled exception handling?
Do you have TEXTRELs in libstdc++ from this compiler?
Comment 11 Ramana Radhakrishnan 2009-10-05 09:28:23 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > 
> > Are you testing the correct compiler  ?
> 
> Yes.
> 
> > After building my 4.4 tree (though a
> > cross compiler ) I see the code generated as below.  
> > 
> > The only reason why this might not work is if you are trying to build an
> > arm-linux and not an arm-linux-gnueabi toolchain but your bug report indicates
> > otherwise.
> 
> $ gcc-4.4 -dumpmachine
> arm-alt-linux-gnueabi
> 
> > As you can see there are no .cfi_* directives. 
> 
> Do you use c++ compiler with enabled exception handling?
> Do you have TEXTRELs in libstdc++ from this compiler?
> 

Ouch - I just realized I'd committed and sent the wrong patch out. I've committed a follow up patch now on trunk 

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00260.html

cheers
Ramana
Comment 12 Kirill A. Shutemov 2009-10-05 19:34:14 UTC
Yes, it works.

Thanks.