>>> On 25.04.16 at 08:41, wrote:
> On 04/22/2016 10:10 PM, Konrad Rzeszutek Wilk wrote:
>>> As per my earlier reply to Konrad, there must be more to this. I.e.
>>> "normal" local symbols won't get dropped together with relocations
>>> referencing them getting resolved.
>>> On 24.04.16 at 23:41, wrote:
> I spoke over the weekend with Dan Jacobowitz (who in the past worked
> on binutils) who mentioned that ELF visibility is what one should
> pay attention to. And that we shouldn't need to look at LOCAL symbols
> at all if we are resolving
On 04/22/2016 10:10 PM, Konrad Rzeszutek Wilk wrote:
As per my earlier reply to Konrad, there must be more to this. I.e.
"normal" local symbols won't get dropped together with relocations
referencing them getting resolved.
Correct. These .LCx symbols only cover .rodata.* sections. Any other
On Fri, Apr 22, 2016 at 05:18:16AM -0600, Jan Beulich wrote:
> >>> On 22.04.16 at 13:08, wrote:
> > On Fri, Apr 22, 2016 at 04:50:34AM -0600, Jan Beulich wrote:
> >> >>> On 22.04.16 at 12:28, wrote:
> >> > On Fri, Apr 22, 2016 at 04:08:10AM -0600,
> As per my earlier reply to Konrad, there must be more to this. I.e.
> "normal" local symbols won't get dropped together with relocations
> referencing them getting resolved.
Correct. These .LCx symbols only cover .rodata.* sections. Any other
local symbols:
[konrad@x230 x86]$ readelf --symbols
On Fri, Apr 22, 2016 at 12:13:02PM +0100, Ross Lagerwall wrote:
> On 04/22/2016 11:08 AM, Jan Beulich wrote:
> On 22.04.16 at 10:45, wrote:
> >>On 04/22/2016 08:51 AM, Jan Beulich wrote:
> >>On 22.04.16 at 09:17, wrote:
> On
>>> On 22.04.16 at 13:13, wrote:
> On 04/22/2016 11:08 AM, Jan Beulich wrote:
> On 22.04.16 at 10:45, wrote:
>>> On 04/22/2016 08:51 AM, Jan Beulich wrote:
>>> On 22.04.16 at 09:17, wrote:
> On
>>> On 22.04.16 at 13:08, wrote:
> On Fri, Apr 22, 2016 at 04:50:34AM -0600, Jan Beulich wrote:
>> >>> On 22.04.16 at 12:28, wrote:
>> > On Fri, Apr 22, 2016 at 04:08:10AM -0600, Jan Beulich wrote:
>> >> >>> On 22.04.16 at 10:45,
On 04/22/2016 11:08 AM, Jan Beulich wrote:
On 22.04.16 at 10:45, wrote:
On 04/22/2016 08:51 AM, Jan Beulich wrote:
On 22.04.16 at 09:17, wrote:
On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote: snip
+static bool_t
On Fri, Apr 22, 2016 at 04:50:34AM -0600, Jan Beulich wrote:
> >>> On 22.04.16 at 12:28, wrote:
> > On Fri, Apr 22, 2016 at 04:08:10AM -0600, Jan Beulich wrote:
> >> >>> On 22.04.16 at 10:45, wrote:
> >> > On 04/22/2016 08:51 AM, Jan Beulich
>>> On 22.04.16 at 12:28, wrote:
> On Fri, Apr 22, 2016 at 04:08:10AM -0600, Jan Beulich wrote:
>> >>> On 22.04.16 at 10:45, wrote:
>> > On 04/22/2016 08:51 AM, Jan Beulich wrote:
>> > On 22.04.16 at 09:17, wrote:
On Fri, Apr 22, 2016 at 04:08:10AM -0600, Jan Beulich wrote:
> >>> On 22.04.16 at 10:45, wrote:
> > On 04/22/2016 08:51 AM, Jan Beulich wrote:
> > On 22.04.16 at 09:17, wrote:
> >>> On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote:
>>> On 22.04.16 at 10:45, wrote:
> On 04/22/2016 08:51 AM, Jan Beulich wrote:
> On 22.04.16 at 09:17, wrote:
>>> On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote: snip
>
>> +static bool_t is_payload_symbol(const struct
On 04/22/2016 08:51 AM, Jan Beulich wrote:
On 22.04.16 at 09:17, wrote:
On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote: snip
+static bool_t is_payload_symbol(const struct xsplice_elf
*elf, +const struct
xsplice_elf_sym *sym) +{
>>> On 22.04.16 at 09:17, wrote:
> On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote:
> snip
>>>
+static bool_t is_payload_symbol(const struct xsplice_elf *elf,
+const struct xsplice_elf_sym *sym)
+{
+if (
On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote:
snip
+static bool_t is_payload_symbol(const struct xsplice_elf *elf,
+const struct xsplice_elf_sym *sym)
+{
+if ( sym->sym->st_shndx == SHN_UNDEF ||
+ sym->sym->st_shndx >= elf->hdr->e_shnum )
+
>>> On 21.04.16 at 15:56, wrote:
>> > So I did try that and it all worked nicely on x86. However on ARM32:
>> >
>> > arm make -j8 1>1
>> > symbols.c: In function 'symbols_lookup_by_name':
>> > symbols.c:287:20: error: cast to pointer from integer of
> > So I did try that and it all worked nicely on x86. However on ARM32:
> >
> > arm make -j8 1>1
> > symbols.c: In function 'symbols_lookup_by_name':
> > symbols.c:287:20: error: cast to pointer from integer of different size
> > [-Werror=int-to-pointer-cast]
> >
> >
>>> On 21.04.16 at 02:26, wrote:
>> >+unsigned long xsplice_symbols_lookup_by_name(const char *symname)
>> >+{
>> >+struct payload *data;
>>
>> Do you need symbols other than those marked "new_symbol" past the loading
>> of the module? If not, wouldn't it be
> >+unsigned long xsplice_symbols_lookup_by_name(const char *symname)
> >+{
> >+struct payload *data;
>
> Do you need symbols other than those marked "new_symbol" past the loading
> of the module? If not, wouldn't it be worthwhile to shrink the symbol table
> to just
> those, likely speeding
On 04/19/2016 08:31 PM, Jan Beulich wrote:
snip
+ASSERT(spin_is_locked(_lock));
+list_for_each_entry ( data, _list, list )
+{
+unsigned int i;
+
+for ( i = 0; i < data->nsyms; i++ )
+{
+if ( !data->symtab[i].new_symbol )
+continue;
>>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
>--- a/xen/arch/x86/test/xen_hello_world.c
>+++ b/xen/arch/x86/test/xen_hello_world.c
>@@ -10,11 +10,14 @@
>static char hello_world_patch_this_fnc[] = "xen_extra_version";
>extern const char *xen_hello_world(void);
>
>+/*
From: Ross Lagerwall
If in the payload we do not have the old_addr we can resolve
the virtual address based on the UNDEFined symbols.
We also use an boolean flag: new_symbol to track symbols. The usual
case this is used is by:
* A payload may introduce a new symbol
*
23 matches
Mail list logo