Re: [Crash-utility] [PATCH 2/2] memory_driver: Support overriding kernel directory
On 28.09.23 05:13, lijiang wrote:
[...]
This issue still exists with the v2:
https://listman.redhat.com/archives/crash-utility/2023-September/011021.html
<https://listman.redhat.com/archives/crash-utility/2023-September/011021.h...
I can reproduce it with the following steps(require kernel-devel package):
[1] make lzo
[2] make clean
[3] make lzo(or make warn)
# make lzo
TARGET: ARM64
CRASH: 8.0.3++
GDB: 10.2
CXX gdb.o
CXX ../../crash_target.o
CXX aarch32-linux-nat.o
CXX aarch32-tdep.o
CXX aarch64-linux-nat.o
CXX aarch64-linux-tdep.o
CXX aarch64-ravenscar-thread.o
CXX aarch64-tdep.o
...
# make warn
TARGET: ARM64
CRASH: 8.0.3++
GDB: 10.2
CXX gdb.o
CXX ../../crash_target.o
CXX aarch32-linux-nat.o
CXX aarch32-tdep.o
CXX aarch64-linux-nat.o
CXX aarch64-linux-tdep.o
CXX aarch64-ravenscar-thread.o
CXX aarch64-tdep.o
...
Thanks, I can see build problems now too after rebasing my changes to
the current master branch.
Digging into, I noticed that building the memory_driver is actually
broken, as it passes the wrong path to the kernel's makefile.
When invoked via '${MAKE} -C memory_driver ...' $(PWD) still refers to
the upper directory, i.e. .../crash and not .../crash/memory_driver.
That's why the '${MAKE} -C ${KDIR} M=${PWD} ... clean' actually calls
the 'clean' target in .../crash and not .../crash/memory_driver as it
should.
The fix is easy, $(PWD) needs to be updated in memory_driver/Makefile.
I'll send a v3 with this change broken out as a separate patch, as it is
a bugfix on its own ('make memory_driver' does nothing in master right now).
>
> [2] With the patch 2/2, it always reports the following error "No such
> file or directory", if the kernel-devel package is not installed.
> # make clean
> ...
> make -C /lib/modules/xxx/build M=/home/crash SUBDIRS=/home/crash clean
> || rm -f *.mod.c *.ko *.o Module.*
> make[3]: *** /lib/modules/xxx/build: No such file or directory. Stop.
>
> Actually, I did not build the crash.ko in the directory
memory_driver/.
>
> Is that expected behavior?
Ahh, yes. That's expected, but unfortunate behavior. I'll fix it by
testing if the build directory exists first to avoid the error message.
The fall-back handling is already there -- simply does the old 'rm
*.mod.c *.ko *.o Module.*'. However, there's no need to generate an
error message when we know in advance that the kernel build directory is
missing.
With the v2, this issue disappeared.
Thanks,
Mathias
Thanks.
Lianbo