On Saturday, 18 July 2020 at 21:27:42 UTC, David Nadlinger wrote:
> On 18 Jul 2020, at 22:17, Denis Feklushkin via digitalmars-d-ldc wrote:
>> I cant check this because I still not found where is it shoud begenerated for ARM EHABI.
>> I mean this D-specific information
>
> It's generated by LLVM, and not really language-specific.

scanLSDA description contains this text:

 * The dmd Call Site Table is structurally different from other implementations. It
 * is organized as nested ranges, and one ip can map to multiple ranges. The most
 * nested candidate is selected when searched. Other implementations have one candidate
 * per ip.

Is this erroneous comment?


> LDSA contains the information about the different catch/cleanup clauses.

Yes, but for unknown reason not in my case.

On Saturday, 18 July 2020 at 21:37:00 UTC, Denis Feklushkin wrote:
> On Saturday, 18 July 2020 at 21:27:42 UTC, David Nadlinger wrote:
>> On 18 Jul 2020, at 22:17, Denis Feklushkin via digitalmars-d-ldc wrote:
>>> I cant check this because I still not found where is it shoud begenerated for ARM EHABI.
>>> I mean this D-specific information
>>
>> It's generated by LLVM, and not really language-specific.


In other words, it seems strange to me that the LLVM knows such details about Dlang.

> scanLSDA description contains this text:
>
>  * The dmd Call Site Table is structurally different from other implementations. It
>  * is organized as nested ranges, and one ip can map to multiple ranges. The most
>  * nested candidate is selected when searched. Other implementations have one candidate
>  * per ip.
>
> Is this erroneous comment?

On Saturday, 18 July 2020 at 21:27:42 UTC, David Nadlinger wrote:
> On 18 Jul 2020, at 22:17, Denis Feklushkin via digitalmars-d-ldc wrote:
>> I cant check this because I still not found where is it shoud begenerated for ARM EHABI.
>> I mean this D-specific information
>
> It's generated by LLVM, and not really language-specific. LDSA contains the information about the different catch/cleanup clauses. — David

Ah, probably, understand: LSDA is just bad name for this thing

Please tell me ways to debug lsda generation in ldc/llvm?
How to understand why zero is wrotten into TType?

On 18 Jul 2020, at 22:49, Denis Feklushkin via digitalmars-d-ldc wrote:
> Ah, probably, understand: LSDA is just bad name for this thing
>
> Please tell me ways to debug lsda generation in ldc/llvm?
> How to understand why zero is wrotten into TType?

Either llvm-readelf or llvm-objdump decodes the LSDA, I think.

I'd really suggest compiling your application for ARM/Linux first and verifying whether things work there, though. They likely will, and you'll at least have a basis for comparison.

 — David

On Saturday, 18 July 2020 at 21:49:43 UTC, Denis Feklushkin wrote:
> How to understand why zero is wrotten into TType?

I've already pointed you to a Linux specificum:
https://github.com/ldc-developers/druntime/blob/19731a92a97dbe4d7f7a4e15ceaff8444a1f879a/src/rt/dwarfeh.d#L926-L930

where TType is overridden for 32-bit ARM. Try getting rid of `version (linux)` there.

On Sunday, 19 July 2020 at 08:56:59 UTC, kinke wrote:
> On Saturday, 18 July 2020 at 21:49:43 UTC, Denis Feklushkin wrote:
>> How to understand why zero is wrotten into TType?
>
> I've already pointed you to a Linux specificum:
> https://github.com/ldc-developers/druntime/blob/19731a92a97dbe4d7f7a4e15ceaff8444a1f879a/src/rt/dwarfeh.d#L926-L930
>
> where TType is overridden for 32-bit ARM. Try getting rid of `version (linux)` there.

Hoho! It works! Great!

I seen your proposal about `version (linux)` there weeks ago, probably tried and it isn't helped. Most likely, I just confused different source trees on my side.

Thanks, Martin and David!