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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 28 Nov 2018 16:49:36 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Eric Saint-Etienne <eric.saint.etienne@...cle.com>
Cc:     Linux Kernel <linux-kernel@...r.kernel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Darren Kenny <darren.kenny@...cle.com>,
        Eric Saint-Etienne <eric.saintetienne@...il.com>
Subject: Re: [PATCH v2] perf symbols: Cannot disassemble some routines when
 debuginfo present

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
>