[PATCH 0/3] clang-14 fixes
This series contains a few clang-14 fixes to partly resolve the problems shown by [1].
The event_dump problem is that the symbol name is not printed by addr2line even though it seems to be present:
Without LTO:
$ addr2line -e u-boot.clang14.no-lto 4a37f addr2line: DWARF error: invalid or unhandled FORM value: 0x23 vbe_simple.c:?
$ nm u-boot.clang14.no-lto |grep 4a37f 000000000004a37f t bootmeth_vbe_simple_ft_fixup
With LTO is even worse:
$ addr2line -e u-boot.clang14.lto 2d2ee0 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0
$ nm u-boot.clang14.lto |grep 4dad1 000000000004dad1 t bootmeth_vbe_simple_ft_fixup
Perhaps this is a bug in addr2line or the clang DWARF output?
[1] https://source.denx.de/u-boot/u-boot/-/jobs/510282#L287
Simon Glass (3): dm: core: Fix lists_bind_fdt() using non-existent of_match event: Drop the path when checking event-list filenames test: Drop unwanted option in event_dump.py
drivers/core/lists.c | 4 +++- scripts/event_dump.py | 2 -- test/py/tests/test_event_dump.py | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)
The call to device_bind_with_driver_data() passes id->data but if the entry has no of_match then the id has not been set by the selected driver.
Normally this passes unnoticed since a previous driver likely had an of_match value, so the id is set to that. Of course it is not correct to pass the id->data from a different driver.
With clang-14 the driver ordering is such that the id is never actually set in the 'bind /usb@1 usb_ether' line in test_bind_unbind_with_node() thus causing a crash.
Fix this by passing 0 if the of_match for a driver does not exist.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/core/lists.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/core/lists.c b/drivers/core/lists.c index c49695b24f0..3878957c9ef 100644 --- a/drivers/core/lists.c +++ b/drivers/core/lists.c @@ -222,6 +222,7 @@ int lists_bind_fdt(struct udevice *parent, ofnode node, struct udevice **devp, log_debug(" - attempt to match compatible string '%s'\n", compat);
+ id = NULL; for (entry = driver; entry != driver + n_ents; entry++) { if (drv) { if (drv != entry) @@ -250,7 +251,8 @@ int lists_bind_fdt(struct udevice *parent, ofnode node, struct udevice **devp, entry->name, entry->of_match->compatible, id->compatible); ret = device_bind_with_driver_data(parent, entry, name, - id->data, node, &dev); + id ? id->data : 0, node, + &dev); if (ret == -ENODEV) { log_debug("Driver '%s' refuses to bind\n", entry->name); continue;
The call to device_bind_with_driver_data() passes id->data but if the entry has no of_match then the id has not been set by the selected driver.
Normally this passes unnoticed since a previous driver likely had an of_match value, so the id is set to that. Of course it is not correct to pass the id->data from a different driver.
With clang-14 the driver ordering is such that the id is never actually set in the 'bind /usb@1 usb_ether' line in test_bind_unbind_with_node() thus causing a crash.
Fix this by passing 0 if the of_match for a driver does not exist.
Signed-off-by: Simon Glass sjg@chromium.org ---
drivers/core/lists.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
This path does not seem to be present in clang-14 for some reason. Relax the regular expression so that the test works, at least for non-LTO.
Signed-off-by: Simon Glass sjg@chromium.org ---
test/py/tests/test_event_dump.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/py/tests/test_event_dump.py b/test/py/tests/test_event_dump.py index bc54149e8f2..56b67da96df 100644 --- a/test/py/tests/test_event_dump.py +++ b/test/py/tests/test_event_dump.py @@ -16,6 +16,6 @@ def test_event_dump(u_boot_console): out = util.run_and_log(cons, ['scripts/event_dump.py', sandbox]) expect = '''.*Event type Id Source location -------------------- ------------------------------ ------------------------------ -EVT_FT_FIXUP bootmeth_vbe_simple_ft_fixup .*boot/vbe_simple.c:.* -EVT_MISC_INIT_F sandbox_misc_init_f .*arch/sandbox/cpu/start.c:''' +EVT_FT_FIXUP bootmeth_vbe_simple_ft_fixup .*vbe_simple.c:.* +EVT_MISC_INIT_F sandbox_misc_init_f .*start.c:''' assert re.match(expect, out, re.MULTILINE) is not None
This path does not seem to be present in clang-14 for some reason. Relax the regular expression so that the test works, at least for non-LTO.
Signed-off-by: Simon Glass sjg@chromium.org ---
test/py/tests/test_event_dump.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Applied to u-boot-dm, thanks!
This option is not used. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
scripts/event_dump.py | 2 -- 1 file changed, 2 deletions(-)
diff --git a/scripts/event_dump.py b/scripts/event_dump.py index 6aadddf28da..d87823f3749 100755 --- a/scripts/event_dump.py +++ b/scripts/event_dump.py @@ -108,8 +108,6 @@ def main(argv): parser.add_argument('elf', type=str, help='ELF file to decode') parser.add_argument('-e', '--endian', type=str, default='auto', help='Big-endian image') - parser.add_argument('-t', '--test', action='store_true', - help='Big-endian image') args = parser.parse_args(argv) show_event_spy_list(args.elf, args.endian)
This option is not used. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
scripts/event_dump.py | 2 -- 1 file changed, 2 deletions(-)
Applied to u-boot-dm, thanks!
Hi Tom,
On Sat, 8 Oct 2022 at 21:33, Simon Glass sjg@chromium.org wrote:
This series contains a few clang-14 fixes to partly resolve the problems shown by [1].
The event_dump problem is that the symbol name is not printed by addr2line even though it seems to be present:
Without LTO:
$ addr2line -e u-boot.clang14.no-lto 4a37f addr2line: DWARF error: invalid or unhandled FORM value: 0x23 vbe_simple.c:?
$ nm u-boot.clang14.no-lto |grep 4a37f 000000000004a37f t bootmeth_vbe_simple_ft_fixup
With LTO is even worse:
$ addr2line -e u-boot.clang14.lto 2d2ee0 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0
$ nm u-boot.clang14.lto |grep 4dad1 000000000004dad1 t bootmeth_vbe_simple_ft_fixup
Perhaps this is a bug in addr2line or the clang DWARF output?
I should have mentioned that I can respin the series to deal with this, perhaps by not requiring the function name to be present when clang is used (or just at all?)
Plus I have one more patch to add for the LTO stuff.
Let me know what you think and I can respin this this.
Simon Glass (3): dm: core: Fix lists_bind_fdt() using non-existent of_match event: Drop the path when checking event-list filenames test: Drop unwanted option in event_dump.py
drivers/core/lists.c | 4 +++- scripts/event_dump.py | 2 -- test/py/tests/test_event_dump.py | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-)
-- 2.38.0.rc1.362.ged0d419d3c-goog
Regards, Simon
On Tue, Oct 11, 2022 at 08:14:53AM -0600, Simon Glass wrote:
Hi Tom,
On Sat, 8 Oct 2022 at 21:33, Simon Glass sjg@chromium.org wrote:
This series contains a few clang-14 fixes to partly resolve the problems shown by [1].
The event_dump problem is that the symbol name is not printed by addr2line even though it seems to be present:
Without LTO:
$ addr2line -e u-boot.clang14.no-lto 4a37f addr2line: DWARF error: invalid or unhandled FORM value: 0x23 vbe_simple.c:?
$ nm u-boot.clang14.no-lto |grep 4a37f 000000000004a37f t bootmeth_vbe_simple_ft_fixup
With LTO is even worse:
$ addr2line -e u-boot.clang14.lto 2d2ee0 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0
$ nm u-boot.clang14.lto |grep 4dad1 000000000004dad1 t bootmeth_vbe_simple_ft_fixup
Perhaps this is a bug in addr2line or the clang DWARF output?
I should have mentioned that I can respin the series to deal with this, perhaps by not requiring the function name to be present when clang is used (or just at all?)
Plus I have one more patch to add for the LTO stuff.
Let me know what you think and I can respin this this.
Maybe it's worth raising a question on one of the LLVM lists? This seems fairly odd.
I would like to move to LLVM-14 / gcc-12.2 for CI, for v2023.01, but there's still other warnings to be fixed too, so we have a little time yet.
Hi Tom,
On Wed, 12 Oct 2022 at 05:13, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 11, 2022 at 08:14:53AM -0600, Simon Glass wrote:
Hi Tom,
On Sat, 8 Oct 2022 at 21:33, Simon Glass sjg@chromium.org wrote:
This series contains a few clang-14 fixes to partly resolve the problems shown by [1].
The event_dump problem is that the symbol name is not printed by addr2line even though it seems to be present:
Without LTO:
$ addr2line -e u-boot.clang14.no-lto 4a37f addr2line: DWARF error: invalid or unhandled FORM value: 0x23 vbe_simple.c:?
$ nm u-boot.clang14.no-lto |grep 4a37f 000000000004a37f t bootmeth_vbe_simple_ft_fixup
With LTO is even worse:
$ addr2line -e u-boot.clang14.lto 2d2ee0 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0
$ nm u-boot.clang14.lto |grep 4dad1 000000000004dad1 t bootmeth_vbe_simple_ft_fixup
Perhaps this is a bug in addr2line or the clang DWARF output?
I should have mentioned that I can respin the series to deal with this, perhaps by not requiring the function name to be present when clang is used (or just at all?)
Plus I have one more patch to add for the LTO stuff.
Let me know what you think and I can respin this this.
Maybe it's worth raising a question on one of the LLVM lists? This seems fairly odd.
I would like to move to LLVM-14 / gcc-12.2 for CI, for v2023.01, but there's still other warnings to be fixed too, so we have a little time yet.
It looks like you fixed this with the dwarf change.
Regards, Simon
On Tue, Dec 06, 2022 at 05:11:46AM +1300, Simon Glass wrote:
Hi Tom,
On Wed, 12 Oct 2022 at 05:13, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 11, 2022 at 08:14:53AM -0600, Simon Glass wrote:
Hi Tom,
On Sat, 8 Oct 2022 at 21:33, Simon Glass sjg@chromium.org wrote:
This series contains a few clang-14 fixes to partly resolve the problems shown by [1].
The event_dump problem is that the symbol name is not printed by addr2line even though it seems to be present:
Without LTO:
$ addr2line -e u-boot.clang14.no-lto 4a37f addr2line: DWARF error: invalid or unhandled FORM value: 0x23 vbe_simple.c:?
$ nm u-boot.clang14.no-lto |grep 4a37f 000000000004a37f t bootmeth_vbe_simple_ft_fixup
With LTO is even worse:
$ addr2line -e u-boot.clang14.lto 2d2ee0 addr2line: DWARF error: invalid or unhandled FORM value: 0x23 ??:0
$ nm u-boot.clang14.lto |grep 4dad1 000000000004dad1 t bootmeth_vbe_simple_ft_fixup
Perhaps this is a bug in addr2line or the clang DWARF output?
I should have mentioned that I can respin the series to deal with this, perhaps by not requiring the function name to be present when clang is used (or just at all?)
Plus I have one more patch to add for the LTO stuff.
Let me know what you think and I can respin this this.
Maybe it's worth raising a question on one of the LLVM lists? This seems fairly odd.
I would like to move to LLVM-14 / gcc-12.2 for CI, for v2023.01, but there's still other warnings to be fixed too, so we have a little time yet.
It looks like you fixed this with the dwarf change.
Yes, the dwarf change addresses this, and I'll be picking that up for next as well.
participants (2)
-
Simon Glass -
Tom Rini