Re: [Lldb-commits] [PATCH] D19114: [test] Relax stderr expectations on targets with chatty output

[Stephen Hines via lldb-commits]

srhines added inline comments.


Comment at: packages/Python/lldbsuite/test/lldbplatformutil.py:142
@@ +141,3 @@
+def hasChattyStderr(test_case):
+"""Some targets produce garbage on the standard error output. This utility 
function
+determines whether the tests can be strict about the expected stderr 
contents."""

I know it isn't ideal, but the stderr output isn't actually "garbage". It is 
just not a warning that lldb cares about, but it is perfectly valid to notify 
developers of an incorrect linking behavior.


http://reviews.llvm.org/D19114



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291

[Stephen Hines via lldb-commits]

srhines added a comment.

In http://reviews.llvm.org/D19480#410641, @rengolin wrote:

> In http://reviews.llvm.org/D19480#410620, @tberghammer wrote:
>
> > Both executables and shared libraries are containing ARM Attributes what 
> > contains the information about soft-float vs hard-float. I am not sure how 
> > accurate it is as in theory you can link together an object file compiled 
> > with soft float with a one compiled with hard float but most likely we can 
> > trust it to be good enough.
>
>
> That's only true if one doesn't depend on the other, and only if you can 
> guarantee that hard-float library functions will only be called using 
> AAPCS_VFP and soft-float library functions will only be called with AAPCS.
>
> This is not the kind of guarantee one can do easily. Nor it is recommended 
> that one does so. If Android applications can guarantee that by having two 
> different ABIs for Android specific and user specific, this could work in 
> theory.
>
> > The problem is that currently this information is not stored in the 
> > llvm::Triple so if the Environment part of the Triple is set to Android 
> > then the information is lost. I can try to recover the data from the 
> > architecture flags but I am not convinced that it is always possible and 
> > considering that the same executable can contain soft-float and hard-float 
> > code on Android we have to treat them as compatible architectures at some 
> > point.
>
>
> The information is not lost, because "Android EABI" is always soft-float, and 
> by definition, you should not be linking hard-float objects with soft-float 
> ones.
>
> Can you elaborate which case you can reach that improbably scenario?


This happens because there is a broken mode (supported by an older NDK) that 
allowed for Hard FP calling conventions to be mixed with Soft FP in a hybrid 
mode. Everything in the user's application would get to use Hard FP, while any 
calls to bionic (libc/libm), or platform native libraries would use Soft FP. 
This wasn't really well tested, nor is it something that I think we should be 
promoting. Does this patch only affect debugging? Could we hold off on this 
until a long term decision is made about supporting mixed hard/soft FP calling 
conventions simultaneously?

> cheers,

> --renato





http://reviews.llvm.org/D19480



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291

[Stephen Hines via lldb-commits]

srhines added a comment.

In http://reviews.llvm.org/D19480#410664, @tberghammer wrote:

> This patch only effects debugging (all modified file is part of LLDB).
>
> I want to get the Android <-> EABI part fixed ASAP as a recent LLDB change 
> completely broke Android ARM debugging with adding ARM.Attributes support 
> (causing Environment mismatch between EABI and Android when the executable 
> contains an ".note.android.ident" while the shared library isn't).
>
> I can change the patch to check only for the Android <-> EABI case and we can 
> wait with the hard-float part as almost nobody using hard-float if you think 
> that is a better idea.


I would prefer that this patch not address any of the Hard/Soft FP mismatch 
problem. If you can make it just fix the Android/EABI case you are looking at, 
that would be the best option.


http://reviews.llvm.org/D19480



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits