All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <v.narang@samsung.com>
Cc: AJEET YADAV <ajeet.y@samsung.com>,
	"yocto@yoctoproject.org" <yocto@yoctoproject.org>,
	doha Hwang <doha.hwang@samsung.com>,
	Hak-Bong Lee <hakbong5.lee@samsung.com>,
	Maninder Singh <maninder1.s@samsung.com>,
	Manjeet Pawar <manjeet.p@samsung.com>,
	PANKAJ MISHRA <pankaj.m@samsung.com>
Subject: Re: [PATCH 1/1] Fix AARCH64_TLSDESC relocation conflict
Date: Fri, 6 Nov 2015 08:26:39 -0600	[thread overview]
Message-ID: <563CB89F.50000@windriver.com> (raw)
In-Reply-To: <1527190987.610301446793765000.JavaMail.weblogic@ep2mlwas08d>

On 11/6/15 1:09 AM, Vaneet Narang wrote:
> Hi Mark, 
> 
>> I have done the same implementation for AARCH64.  Loader handles AARCH64_TLSDESC conflict as below.
>> case R_AARCH64_TLSDESC:
>> ....
>>            if (! sym)
>>              {
>>                td->arg = (void*)reloc->r_addend;
>>                td->entry = _dl_tlsdesc_undefweak;
>>              }
> 
> we have shared one patch in libc to handle AARCH64_TLS conflict on AARCH64. 
> https://sourceware.org/ml/libc-alpha/2015-11/msg00106.html
>  
> Since we are using cross prelink we don't run testsuite. we compile all test cases 
> from test suite manually as mentioned in tls.sh file and run on target. 
> 
> LD_DEBUG=libs LD_LIBRARY_PATH=. ./tls1
>        
>  1828:     prelink checking: ok
> 
> ....
> No segfault or abort() is observed hence i assume testcase is running properly.  

I will look into this further.  But you should start building the test cases on
the target and running them.

Some of the failures are segfault/aborts.  But many of them have to do with
prelink functionality.  For example, many failures are related to the inability
to 'unprelink' the binaries.

Something is changing the binary in a way that can not be reverted, and this is
a failure case.  The system must be able to be unprelinked for validation
purposes -- and also to permit being re-prelinked.

I will look into merging these patches later today and will also work on adding
the necessary patches to poky/oe-core and putting them into a contrib branch so
we're working on the same set of data.

--Mark

>          
> Thanks 
> Vaneet Narang
> 



  reply	other threads:[~2015-11-06 15:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06  7:09 [PATCH 1/1] Fix AARCH64_TLSDESC relocation conflict Vaneet Narang
2015-11-06 14:26 ` Mark Hatle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-11-04  5:58 Vaneet Narang
2015-11-03 11:44 Manjeet Pawar
2015-11-03 21:10 ` Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563CB89F.50000@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=ajeet.y@samsung.com \
    --cc=doha.hwang@samsung.com \
    --cc=hakbong5.lee@samsung.com \
    --cc=maninder1.s@samsung.com \
    --cc=manjeet.p@samsung.com \
    --cc=pankaj.m@samsung.com \
    --cc=v.narang@samsung.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.