libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] AARCH64 ILP32 support


From: Krishnanjanappa, Jagadeesh
Subject: Re: [Libunwind-devel] AARCH64 ILP32 support
Date: Thu, 26 Sep 2013 06:50:15 +0000

Hi,

I am trying to print the unwind info using local unwinding.

> Does this have to be a determined at runtime or can we fix it at
> compile time the way it's done here:

> include/dwarf_i.h:# define dwarf_addr_size(as) (sizeof (unw_word_t))

If we take up dwarf_addr_size(as) as present in dwarf_i.h, we have value of 
macro as 8 (since "typedef uint64_t unw_word_t") for both AARCH64 and AARCH64 
ILP 32. In that case we will be calling dwarf_readu64 function in 
include/dwarf_i.h  and fde_encoding also differs in src/dwarf/Gfde.c for 
AARCH64 ILP32. I tried to use dwarf_addr_size macro as sizeof(unw_word_t), it 
fails to print unwind info of __start procedure for AARCH64 ILP32, but prints 
unwind info of __start for AARCH64. 

> +#define dwarf_addr_size(addr_space) ((addr_space)->addr_size)
This change is similar to what was done for mips.

> Also, could you try running:
>make check
>and paste the results?

Currently, I am using a simulator to execute libunwind testcase for AARCH64, 
AARCH64 ILP32.
I will try my best to get the results of make check.

Regards,
Jagadeesh
________________________________________
From: address@hidden <address@hidden> on behalf of Arun Sharma <address@hidden>
Sent: Thursday, September 26, 2013 10:35 AM
To: Paul Pluzhnikov
Cc: Krishnanjanappa, Jagadeesh; Pinski, Andrew; address@hidden
Subject: Re: [Libunwind-devel] AARCH64 ILP32 support

On Wed, Sep 25, 2013 at 8:30 PM, Paul Pluzhnikov <address@hidden> wrote:
> On 9/25/13 7:34 AM, Arun Sharma wrote:
>
>> One design involves:
>>
>> libunwind_aarch64.a
>> libunwind_aarch64_ilp32.a
>
>
> AFAICT, GCC aarch64 defaults to little-endian, not big-endian.
>
> Perhaps the library names above should encode endianness?

May be just for the bi-endian architectures, where there is plausible ambiguity.

 -Arun



reply via email to

[Prev in Thread] Current Thread [Next in Thread]