Re: [Xen-devel] [PATCH v8.1 14/27] xsplice, symbols: Implement symbol name resolution on address.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.04.16 at 02:26, <konrad.wilk@xxxxxxxxxx> 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 worthwhile to shrink the symbol table 
>> to just
>> those, likely speeding up the lookup?
> 
> Ross hopefully answered that to your satisfaction?

Yes. Thinko of mine.

>> >@@ -379,11 +405,129 @@ static int prepare_payload(struct payload *payload,
>>          >for ( j = 0; j < ARRAY_SIZE(f->u.pad); j++ )
>>              >if ( f->u.pad[j] )
>>                  >return -EINVAL;
>> >+
>> >+        /* Lookup function's old address if not already resolved. */
>> >+        if ( !f->old_addr )
>> >+        {
>> >+            f->old_addr = (void *)symbols_lookup_by_name(f->name);
>> >+            if ( !f->old_addr )
>> >+            {
>> >+                f->old_addr = (void 
>> >*)xsplice_symbols_lookup_by_name(f->name);
>> 
>> The two casts make me wonder whether the two functions shouldn't return
>> void *, and then whether struct xsplice_symbol's value field shouldn't then
>> perhaps be void * too.
> 
> So I did try that and it all worked nicely on x86. However on ARM32:
> 
> arm <konrad@localhost:~/xen/xen> 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]
> 
> 275     uint64_t addr = 0; /* MUST be initialized. */                        
>        
> 
> 286         if ( !strcmp(name, symname) )                                    
>        
> 287             return (void *)addr; 
> 
> Which is rather unfortunate. I think I will have to make it unsigned
> long.

Well, why would any kind of address be uint64_t on ARM32?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel