Re: [PATCH v2] perf symbols: Cannot disassemble some routines when debuginfo present

[Jiri Olsa]

On Wed, Nov 28, 2018 at 03:08:32AM -0800, Eric Saint-Etienne wrote:

SNIP

> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index e9c108a..be333a9 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -1569,9 +1569,54 @@ struct map *thread__find_map(struct thread *thread, u8 cpumode, u64 addr,
>  		 * Kernel maps might be changed when loading symbols so loading
>  		 * must be done prior to using kernel maps.
>  		 */
> -		if (load_map)
> +		if (load_map) {
> +			/*
> +			 * Note when using -ffunction-sections on the kernel:
> +			 *
> +			 * Only .text got loaded into al->map at this point.
> +			 * Consequently al->map address range encompass the
> +			 * whole image.
> +			 *
> +			 * map__load() will split this map into many function
> +			 * maps by shrinking al->map accordingly.
> +			 *
> +			 * The split happens in dso_process_kernel_symbol()
> +			 * where we call map_groups__find_by_name() to find an
> +			 * existing map, but with -ffunction-sections and a
> +			 * symbol belonging to a new (function) map, such map
> +			 * doesn't exist yet so we end up creating one and
> +			 * adjusting existing maps accordingly because
> +			 * adjust_kernel_syms is set there.
> +			 */
> +
>  			map__load(al->map);
> -		al->addr = al->map->map_ip(al->map, al->addr);
> +
> +			/*
> +			 * Note when using -ffunction-sections on the kernel:
> +			 *
> +			 * Very likely the target address will now be in one of
> +			 * the newly created function maps but al->map still
> +			 * points to .text which has been drastically shrank by
> +			 * the split done in map__load()
> +			 */
> +			if (al->addr < al->map->start ||
> +			    al->addr >= al->map->end)
> +				al->map = map_groups__find(mg, al->addr);

looks like a good place for WARN_ON_ONCE(!al->map) in here

jirka

> +
> +			/*
> +			 * map_groups__find() should always find a map because
> +			 * the target address was initially found in .text which
> +			 * got split *without introducing gaps* by map__load()
> +			 */
> +		}
> +
> +		/*
> +		 * In case the later call to map_groups__find() didn't find a
> +		 * suitable map (it should always, but better be safe) we make
> +		 * sure that al->map is still valid before deferencing it.
> +		 */
> +		if (al->map != NULL)
> +			al->addr = al->map->map_ip(al->map, al->addr);
>  	}
>  
>  	return al->map;
> -- 
> 1.8.3.1
>