On Fri, Jun 26, 2015 at 04:44:14PM +0100, Andy Lutomirski wrote:
> On Fri, Jun 26, 2015 at 8:29 AM, Will Deacon wrote:
> > On Fri, Jun 26, 2015 at 04:18:59PM +0100, Andy Lutomirski wrote:
> >> On Fri, Jun 26, 2015 at 7:58 AM, Will Deacon wrote:
> >> > (CC'ing Andy, since the removal of VDSO_PRELI
On Fri, Jun 26, 2015 at 8:29 AM, Will Deacon wrote:
> On Fri, Jun 26, 2015 at 04:18:59PM +0100, Andy Lutomirski wrote:
>> On Fri, Jun 26, 2015 at 7:58 AM, Will Deacon wrote:
>> > (CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)
>>
>> What arch is this? I removed VDSO_PRELINK
On 26/06/2015 5:58 p.m., Will Deacon wrote:
(CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)
On Fri, Jun 26, 2015 at 02:55:29PM +0100, Adrian Hunter wrote:
On 26/06/15 15:23, Will Deacon wrote:
On Thu, Jun 25, 2015 at 02:32:13PM +0100, Adrian Hunter wrote:
On 24/06/15 19:1
On Fri, Jun 26, 2015 at 04:18:59PM +0100, Andy Lutomirski wrote:
> On Fri, Jun 26, 2015 at 7:58 AM, Will Deacon wrote:
> > (CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)
>
> What arch is this? I removed VDSO_PRELINK entirely from x86 a while
> back, and now x86's vdso has
On Fri, Jun 26, 2015 at 7:58 AM, Will Deacon wrote:
> (CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)
What arch is this? I removed VDSO_PRELINK entirely from x86 a while
back, and now x86's vdso has a base address of 0 before relocations,
and everything works just fine.
(E
(CC'ing Andy, since the removal of VDSO_PRELINK is user-visible here)
Hi Adrian,
Thanks for your helpful responses.
On Fri, Jun 26, 2015 at 02:55:29PM +0100, Adrian Hunter wrote:
> On 26/06/15 15:23, Will Deacon wrote:
> > On Thu, Jun 25, 2015 at 02:32:13PM +0100, Adrian Hunter wrote:
> >> On 24
On 26/06/15 15:23, Will Deacon wrote:
> On Thu, Jun 25, 2015 at 02:32:13PM +0100, Adrian Hunter wrote:
>> On 24/06/15 19:17, Will Deacon wrote:
>>> Commit 922d0e4d9f04 ("perf tools: Adjust symbols in VDSO") changed the
>>> ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
>>> E
On Thu, Jun 25, 2015 at 02:32:13PM +0100, Adrian Hunter wrote:
> On 24/06/15 19:17, Will Deacon wrote:
> > Commit 922d0e4d9f04 ("perf tools: Adjust symbols in VDSO") changed the
> > ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
> > ET_REL binaries despite being an ET_DYN.
>
On 24/06/15 19:17, Will Deacon wrote:
> Commit 922d0e4d9f04 ("perf tools: Adjust symbols in VDSO") changed the
> ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
> ET_REL binaries despite being an ET_DYN.
>
> This causes objdump, which expects relative addresses, not to produ
Commit 922d0e4d9f04 ("perf tools: Adjust symbols in VDSO") changed the
ELF symbol parsing so that the vDSO is treated the same as ET_EXEC and
ET_REL binaries despite being an ET_DYN.
This causes objdump, which expects relative addresses, not to produce
any output in conjunction with perf annotate,
10 matches
Mail list logo