diff mbox series

[v9,3/8] kbuild: generate an address ranges map at vmlinux link time

Message ID 20221109134132.9052-4-nick.alcock@oracle.com (mailing list archive)
State New, archived
Headers show
Series [v9,1/8] kbuild: bring back tristate.conf | expand

Commit Message

Nick Alcock Nov. 9, 2022, 1:41 p.m. UTC 
This emits a new file, .tmp_vmlinux.ranges, which maps address
range/size pairs in vmlinux to the object files which make them up,
e.g., in part:

0x0000000000000000 0x30 arch/x86/kernel/cpu/common.o
0x0000000000001000 0x1000 arch/x86/events/intel/ds.o
0x0000000000002000 0x4000 arch/x86/kernel/irq_64.o
0x0000000000006000 0x5000 arch/x86/kernel/process.o
0x000000000000b000 0x1000 arch/x86/kernel/cpu/common.o
0x000000000000c000 0x5000 arch/x86/mm/cpu_entry_area.o
0x0000000000011000 0x10 arch/x86/kernel/espfix_64.o
0x0000000000011010 0x2 arch/x86/kernel/cpu/common.o
[...]

In my simple tests this seems to work with clang too, but if I'm not
sure how stable the format of clang's linker mapfiles is: if it turns
out not to work in some versions, the mapfile-massaging awk script added
here might need some adjustment.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
---

Notes:
    v6: use ${wl} where appropriate to avoid failure on UML

 scripts/link-vmlinux.sh | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Comments

Luis Chamberlain Nov. 13, 2022, 3:02 a.m. UTC | #1 
On Wed, Nov 09, 2022 at 01:41:27PM +0000, Nick Alcock wrote:
> This emits a new file, .tmp_vmlinux.ranges, which maps address
> range/size pairs in vmlinux to the object files which make them up,
> e.g., in part:
> 
> 0x0000000000000000 0x30 arch/x86/kernel/cpu/common.o
> 0x0000000000001000 0x1000 arch/x86/events/intel/ds.o
> 0x0000000000002000 0x4000 arch/x86/kernel/irq_64.o
> 0x0000000000006000 0x5000 arch/x86/kernel/process.o
> 0x000000000000b000 0x1000 arch/x86/kernel/cpu/common.o
> 0x000000000000c000 0x5000 arch/x86/mm/cpu_entry_area.o
> 0x0000000000011000 0x10 arch/x86/kernel/espfix_64.o
> 0x0000000000011010 0x2 arch/x86/kernel/cpu/common.o
> [...]

This does't say why we'd want this. So either you merge it with its
first user or you explain here why anyone might find this useful.

  Luis
Nick Alcock Nov. 14, 2022, 4:48 p.m. UTC | #2 
[Added Steve Rostedt to Cc:]

On 13 Nov 2022, Luis Chamberlain stated:

> On Wed, Nov 09, 2022 at 01:41:27PM +0000, Nick Alcock wrote:
>> This emits a new file, .tmp_vmlinux.ranges, which maps address
>> range/size pairs in vmlinux to the object files which make them up,
>> e.g., in part:
>> 
>> 0x0000000000000000 0x30 arch/x86/kernel/cpu/common.o
>> 0x0000000000001000 0x1000 arch/x86/events/intel/ds.o
>> 0x0000000000002000 0x4000 arch/x86/kernel/irq_64.o
>> 0x0000000000006000 0x5000 arch/x86/kernel/process.o
>> 0x000000000000b000 0x1000 arch/x86/kernel/cpu/common.o
>> 0x000000000000c000 0x5000 arch/x86/mm/cpu_entry_area.o
>> 0x0000000000011000 0x10 arch/x86/kernel/espfix_64.o
>> 0x0000000000011010 0x2 arch/x86/kernel/cpu/common.o
>> [...]
>
> This does't say why we'd want this. So either you merge it with its
> first user or you explain here why anyone might find this useful.

Uh... the first user is later in this patch series? If you want each
commit to have a self-contained explanation, I could certainly note why
it's useful for said first user in this commit message (and adjust other
messages similarly), but I had previous complaints that commit log
messages and the cover letter were repeating points, so I was trying to
reduce that kind of thing.
Luis Chamberlain Nov. 15, 2022, 9:22 p.m. UTC | #3 
On Mon, Nov 14, 2022 at 04:48:57PM +0000, Nick Alcock wrote:
> [Added Steve Rostedt to Cc:]
> 
> On 13 Nov 2022, Luis Chamberlain stated:
> 
> > On Wed, Nov 09, 2022 at 01:41:27PM +0000, Nick Alcock wrote:
> >> This emits a new file, .tmp_vmlinux.ranges, which maps address
> >> range/size pairs in vmlinux to the object files which make them up,
> >> e.g., in part:
> >> 
> >> 0x0000000000000000 0x30 arch/x86/kernel/cpu/common.o
> >> 0x0000000000001000 0x1000 arch/x86/events/intel/ds.o
> >> 0x0000000000002000 0x4000 arch/x86/kernel/irq_64.o
> >> 0x0000000000006000 0x5000 arch/x86/kernel/process.o
> >> 0x000000000000b000 0x1000 arch/x86/kernel/cpu/common.o
> >> 0x000000000000c000 0x5000 arch/x86/mm/cpu_entry_area.o
> >> 0x0000000000011000 0x10 arch/x86/kernel/espfix_64.o
> >> 0x0000000000011010 0x2 arch/x86/kernel/cpu/common.o
> >> [...]
> >
> > This does't say why we'd want this. So either you merge it with its
> > first user or you explain here why anyone might find this useful.
> 
> Uh... the first user is later in this patch series? If you want each
> commit to have a self-contained explanation, I could certainly note why
> it's useful for said first user in this commit message (and adjust other
> messages similarly), but I had previous complaints that commit log
> messages and the cover letter were repeating points, so I was trying to
> reduce that kind of thing.

Commit logs should be self contained. The reason for *why* we want to
add ranges should go here, not the cover letter. You can be terse in the
cover letter over the general solution.

  Luis
Nick Alcock Nov. 16, 2022, 4:06 p.m. UTC | #4 
On 15 Nov 2022, Luis Chamberlain verbalised:

> On Mon, Nov 14, 2022 at 04:48:57PM +0000, Nick Alcock wrote:
>> [Added Steve Rostedt to Cc:]
>> 
>> On 13 Nov 2022, Luis Chamberlain stated:
>> > This does't say why we'd want this. So either you merge it with its
>> > first user or you explain here why anyone might find this useful.
>> 
>> Uh... the first user is later in this patch series? If you want each
>> commit to have a self-contained explanation, I could certainly note why
>> it's useful for said first user in this commit message (and adjust other
>> messages similarly), but I had previous complaints that commit log
>> messages and the cover letter were repeating points, so I was trying to
>> reduce that kind of thing.
>
> Commit logs should be self contained. The reason for *why* we want to
> add ranges should go here, not the cover letter. You can be terse in the
> cover letter over the general solution.

Ah, OK, my apologies: I was writing things precisely backwards then
(rationale in the cover letter, self-contained-but-no-rationale in the
individual patches then tying it together in the user at the end).
Whoops!

I'll rephrase as you suggest in the next round.

(And I'll definitely rephrase the cover letter again -- I tried to add a
decent rationale in there but from the sounds of things comprehensively
failed this time. Sorry!)
diff mbox series

Patch

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 918470d768e9..287a2b2c4d46 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -101,7 +101,7 @@  vmlinux_link()
 	${ld} ${ldflags} -o ${output}					\
 		${wl}--whole-archive ${objs} ${wl}--no-whole-archive	\
 		${wl}--start-group ${libs} ${wl}--end-group		\
-		$@ ${ldlibs}
+		${wl}-Map=.tmp_vmlinux.map $@ ${ldlibs}
 }
 
 # generate .BTF typeinfo from DWARF debuginfo
@@ -144,6 +144,19 @@  kallsyms()
 {
 	local kallsymopt;
 
+	# read the linker map to identify ranges of addresses:
+	#   - for each *.o file, report address, size, pathname
+	#       - most such lines will have four fields
+	#       - but sometimes there is a line break after the first field
+	#   - start reading at "Linker script and memory map"
+	#   - stop reading at ".brk"
+	${AWK} '
+	    /\.o$/ && start==1 { print $(NF-2), $(NF-1), $NF }
+	    /^Linker script and memory map/ { start = 1 }
+	    /^\.brk/ { exit(0) }
+	' .tmp_vmlinux.map | sort > .tmp_vmlinux.ranges
+
+	# get kallsyms options
 	if is_enabled CONFIG_KALLSYMS_ALL; then
 		kallsymopt="${kallsymopt} --all-symbols"
 	fi