On Fri, Apr 08, 2016 at 03:11:17PM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 22:50, wrote:
> > On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
> >> >>> On 08.04.16 at 21:23, wrote:
> >> > @@ -57,10 +60,19 @@ SECTIONS
> >> > *(.lockprofile.data)
> >> > __lock_prof
>>> On 08.04.16 at 22:50, wrote:
> On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
>> >>> On 08.04.16 at 21:23, wrote:
>> > @@ -57,10 +60,19 @@ SECTIONS
>> > *(.lockprofile.data)
>> > __lock_profile_end = .;
>> > #endif
>> > -
>> > -_erodata = .; /*
On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 21:23, wrote:
> > On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote:
> >> >>> On 08.04.16 at 19:06, wrote:
> >> > So that when xen.efi is linked with this build_id.o (in v5, now called
> >> > notes.o in v
>>> On 08.04.16 at 21:23, wrote:
> On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote:
>> >>> On 08.04.16 at 19:06, wrote:
>> > So that when xen.efi is linked with this build_id.o (in v5, now called
>> > notes.o in v6)
>> > it can encapsulate __note_gnu_build_id_start and __note_gnu_bui
>>> On 08.04.16 at 20:47, wrote:
> On Fri, Apr 08, 2016 at 04:49:00PM +0100, Ross Lagerwall wrote:
>> On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote:
>> >On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
>> >On 24.03.16 at 21:00, wrote:
>> >>>The version of ld that first imple
> diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
> index 5099430..a6dae4c 100644
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -6,7 +6,7 @@ create = test -e $(1) || touch -t 19990101 $(1)
>
> efi := y$(shell rm -f disabled)
> efi := $(if $(efi)
On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 19:06, wrote:
> > "Since you put the notes into .rodata anyway, why name the section .note"
> >
> > Perhaps you mean - why name the section .note.gnu_build-id ?
>
> Sure - .note or .note.*.
>
> > So that when xen.
> Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
> symbol offsets don't changes (which means we have multiple binary
> ids - except that the last one is the final one). Without this change,
> the symbol table embedded in Xen are incorrect - some of the value
On Fri, Apr 08, 2016 at 04:49:00PM +0100, Ross Lagerwall wrote:
> On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote:
> >On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
> >On 24.03.16 at 21:00, wrote:
> >>>The version of ld that first implemented --build-id is v2.18.
> >>>Hence w
>>> On 08.04.16 at 19:06, wrote:
> "Since you put the notes into .rodata anyway, why name the section .note"
>
> Perhaps you mean - why name the section .note.gnu_build-id ?
Sure - .note or .note.*.
> So that when xen.efi is linked with this build_id.o (in v5, now called
> notes.o in v6)
> it
On Fri, Apr 08, 2016 at 09:27:00AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 03:52, wrote:
> > On Thu, Apr 07, 2016 at 08:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
> >> >
> >> > > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> >> > > + --rename-section=.data=.n
On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote:
On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
On 24.03.16 at 21:00, wrote:
The version of ld that first implemented --build-id is v2.18.
Hence we check for that or later version - if older version
found we do not build the hyp
>>> On 08.04.16 at 03:52, wrote:
> On Thu, Apr 07, 2016 at 08:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
>> >
>> > > +$(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
>> > > +--rename-section=.data=.note.gnu.build-id -S $@.bin $@
>> >
>> > Since you put the notes in
>>> On 08.04.16 at 02:18, wrote:
>> > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
>> > + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
>>
>> Since you put the notes into .rodata anyway, why name the
>> section .note.*? Just name it .rodata.*, avoiding to mislead
>>
On Thu, Apr 07, 2016 at 08:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
> > > +build_id.o: $(TARGET)-syms
> > > + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
> >
> > Considering your xen.lds.S changes, won't this potentially copy quite
> > a bit more than just the build ID
> > +build_id.o: $(TARGET)-syms
> > + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
>
> Considering your xen.lds.S changes, won't this potentially copy quite
> a bit more than just the build ID (i.e. all notes)? This may be okay, and
> may be even intended, but then the ge
On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, wrote:
> > The version of ld that first implemented --build-id is v2.18.
> > Hence we check for that or later version - if older version
> > found we do not build the hypervisor with the build-id
> > (and the
>>> On 24.03.16 at 21:00, wrote:
> The version of ld that first implemented --build-id is v2.18.
> Hence we check for that or later version - if older version
> found we do not build the hypervisor with the build-id
> (and the return code is -ENODATA for xen_build_id() call).
This appears to be s
This patch enables the Elf to be built with the build-id
and provide in the Xen hypervisor the code to extract it.
One can also retrieve the value of the build-id by doing
'readelf -n xen-syms'.
For EFI builds we re-use the same build-id that the xen-syms
was built with.
The version of ld that f
19 matches
Mail list logo
