Re: [PATCH 6/7] perf tools: Do not need to read symbols for source line lookup
Em Wed, Dec 04, 2013 at 04:00:18PM +0200, Adrian Hunter escreveu: > On 03/12/13 22:24, Arnaldo Carvalho de Melo wrote: > > Em Tue, Dec 03, 2013 at 09:23:09AM +0200, Adrian Hunter escreveu: > >> When using libbfd to lookup source filename and line number, > >> libbfd does not need the symbol table. Removing the symbol > >> table reading, doubles the speed of 'perf script' with the > >> 'srcline' option. > > > > [root@zoo ~]# gdb perf > > run report -s srcline > > > > b0m > > I wasn't able to reproduce this but I noticed the line numbers > were not found for kernel modules with this patch - so it seems > some binaries need the symbol information and some don't. > > So please disregard this patch, sorry for your trouble. No problem, disregarding it. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] perf tools: Do not need to read symbols for source line lookup
On 03/12/13 22:24, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 03, 2013 at 09:23:09AM +0200, Adrian Hunter escreveu:
>> When using libbfd to lookup source filename and line number,
>> libbfd does not need the symbol table. Removing the symbol
>> table reading, doubles the speed of 'perf script' with the
>> 'srcline' option.
>
> [root@zoo ~]# gdb perf
> run report -s srcline
>
> b0m
I wasn't able to reproduce this but I noticed the line numbers
were not found for kernel modules with this patch - so it seems
some binaries need the symbol information and some don't.
So please disregard this patch, sorry for your trouble.
>
> bt
> #0 0x0050ac60 in read_unsigned_leb128 ()
> #1 0x005189f7 in find_abstract_instance_name.isra.20 ()
> #2 0x005190e1 in scan_unit_for_symbols ()
> #3 0x00519a69 in comp_unit_find_nearest_line ()
> #4 0x0051a6ff in find_line.part.26 ()
> #5 0x00531063 in _bfd_elf_find_nearest_line_discriminator ()
> #6 0x0053117b in _bfd_elf_find_nearest_line ()
> #7 0x004bf22d in find_address_in_section (abfd=0x39de5f0,
> section=0x3a32c38, data=0x3901950) at util/srcline.c:51
> #8 0x0050ccdc in bfd_map_over_sections ()
> #9 0x004bf48b in addr2line (dso_name=0x39fb830
> "/lib/modules/3.13.0-rc1+/kernel/drivers/gpu/drm/drm.ko", addr=20832,
> file=0x7fffcc00, line=0x7fffcbfc, dso=0x90f9e0) at
> util/srcline.c:116
> #10 0x004bf608 in get_srcline (dso=0x90f9e0, addr=20832) at
> util/srcline.c:217
> #11 0x004b00fe in sort__srcline_cmp (left=0x1dc76f0,
> right=0x7fffcd70) at util/sort.c:268
> #12 0x004b3942 in hist_entry__cmp (left=0x1dc76f0,
> right=0x7fffcd70) at util/hist.c:450
> #13 0x004b35f4 in add_hist_entry (hists=0x90f278,
> entry=0x7fffcd70, al=0x7fffcf90, period=399301, weight=0)
> at util/hist.c:367
> #14 0x004b38d8 in __hists__add_entry (hists=0x90f278,
> al=0x7fffcf90, sym_parent=0x0, bi=0x0, mi=0x0, period=399301,
> weight=0, transaction=0) at util/hist.c:440
> #15 0x0042c9da in perf_evsel__add_hist_entry (tool=0x7fffd510,
> evsel=0x90f1d0, al=0x7fffcf90, sample=0x7fffd140,
> machine=0x90e6b8) at builtin-report.c:274
> #16 0x0042cd4f in process_sample_event (tool=0x7fffd510,
> event=0x717aea30, sample=0x7fffd140, evsel=0x90f1d0,
> machine=0x90e6b8) at builtin-report.c:347
> #17 0x0049df43 in perf_session__deliver_sample (session=0x90e5e0,
> tool=0x7fffd510, event=0x717aea30,
> sample=0x7fffd140, evsel=0x90f1d0, machine=0x90e6b8) at
> util/session.c:930
> #18 0x0049e107 in perf_session_deliver_event (session=0x90e5e0,
> event=0x717aea30, sample=0x7fffd140,
> tool=0x7fffd510, file_offset=821808) at util/session.c:984
> #19 0x0049cfb4 in flush_sample_queue (s=0x90e5e0,
> tool=0x7fffd510) at util/session.c:526
> #20 0x0049ef53 in __perf_session__process_events (session=0x90e5e0,
> data_offset=216, data_size=832400, file_size=832616,
> tool=0x7fffd510) at util/session.c:1371
> #21 0x0049f02e in perf_session__process_events (session=0x90e5e0,
> tool=0x7fffd510) at util/session.c:1389
> #22 0x0042d605 in __cmd_report (rep=0x7fffd510) at
> builtin-report.c:527
> ---Type to continue, or q to quit---
>
> Applied all except this one and the other one David commented on,
> waiting for that discussion to reach some conclusion.
>
> But with the ones applied 'perf report -s srcline' is _much_ faster,
> thanks!
>
> - Arnaldo
>
>> Signed-off-by: Adrian Hunter
>> ---
>> tools/perf/util/srcline.c | 53
>> +--
>> 1 file changed, 1 insertion(+), 52 deletions(-)
>>
>> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
>> index 93795f9..e09c9e0 100644
>> --- a/tools/perf/util/srcline.c
>> +++ b/tools/perf/util/srcline.c
>> @@ -29,54 +29,6 @@ struct a2l_data {
>> asymbol **syms;
>> };
>>
>> -static int bfd_error(const char *string)
>> -{
>> -const char *errmsg;
>> -
>> -errmsg = bfd_errmsg(bfd_get_error());
>> -fflush(stdout);
>> -
>> -if (string)
>> -pr_debug("%s: %s\n", string, errmsg);
>> -else
>> -pr_debug("%s\n", errmsg);
>> -
>> -return -1;
>> -}
>> -
>> -static int slurp_symtab(bfd *abfd, struct a2l_data *a2l)
>> -{
>> -long storage;
>> -long symcount;
>> -asymbol **syms;
>> -bfd_boolean dynamic = FALSE;
>> -
>> -if ((bfd_get_file_flags(abfd) & HAS_SYMS) == 0)
>> -return bfd_error(bfd_get_filename(abfd));
>> -
>> -storage = bfd_get_symtab_upper_bound(abfd);
>> -if (storage == 0L) {
>> -storage = bfd_get_dynamic_symtab_upper_bound(abfd);
>> -dynamic = TRUE;
>> -}
>> -if (storage < 0L)
>> -return bfd_error(bfd_get_filename(abfd));
>> -
>> -syms
Re: [PATCH 6/7] perf tools: Do not need to read symbols for source line lookup
On 03/12/13 22:24, Arnaldo Carvalho de Melo wrote:
Em Tue, Dec 03, 2013 at 09:23:09AM +0200, Adrian Hunter escreveu:
When using libbfd to lookup source filename and line number,
libbfd does not need the symbol table. Removing the symbol
table reading, doubles the speed of 'perf script' with the
'srcline' option.
[root@zoo ~]# gdb perf
run report -s srcline
b0m
I wasn't able to reproduce this but I noticed the line numbers
were not found for kernel modules with this patch - so it seems
some binaries need the symbol information and some don't.
So please disregard this patch, sorry for your trouble.
bt
#0 0x0050ac60 in read_unsigned_leb128 ()
#1 0x005189f7 in find_abstract_instance_name.isra.20 ()
#2 0x005190e1 in scan_unit_for_symbols ()
#3 0x00519a69 in comp_unit_find_nearest_line ()
#4 0x0051a6ff in find_line.part.26 ()
#5 0x00531063 in _bfd_elf_find_nearest_line_discriminator ()
#6 0x0053117b in _bfd_elf_find_nearest_line ()
#7 0x004bf22d in find_address_in_section (abfd=0x39de5f0,
section=0x3a32c38, data=0x3901950) at util/srcline.c:51
#8 0x0050ccdc in bfd_map_over_sections ()
#9 0x004bf48b in addr2line (dso_name=0x39fb830
/lib/modules/3.13.0-rc1+/kernel/drivers/gpu/drm/drm.ko, addr=20832,
file=0x7fffcc00, line=0x7fffcbfc, dso=0x90f9e0) at
util/srcline.c:116
#10 0x004bf608 in get_srcline (dso=0x90f9e0, addr=20832) at
util/srcline.c:217
#11 0x004b00fe in sort__srcline_cmp (left=0x1dc76f0,
right=0x7fffcd70) at util/sort.c:268
#12 0x004b3942 in hist_entry__cmp (left=0x1dc76f0,
right=0x7fffcd70) at util/hist.c:450
#13 0x004b35f4 in add_hist_entry (hists=0x90f278,
entry=0x7fffcd70, al=0x7fffcf90, period=399301, weight=0)
at util/hist.c:367
#14 0x004b38d8 in __hists__add_entry (hists=0x90f278,
al=0x7fffcf90, sym_parent=0x0, bi=0x0, mi=0x0, period=399301,
weight=0, transaction=0) at util/hist.c:440
#15 0x0042c9da in perf_evsel__add_hist_entry (tool=0x7fffd510,
evsel=0x90f1d0, al=0x7fffcf90, sample=0x7fffd140,
machine=0x90e6b8) at builtin-report.c:274
#16 0x0042cd4f in process_sample_event (tool=0x7fffd510,
event=0x717aea30, sample=0x7fffd140, evsel=0x90f1d0,
machine=0x90e6b8) at builtin-report.c:347
#17 0x0049df43 in perf_session__deliver_sample (session=0x90e5e0,
tool=0x7fffd510, event=0x717aea30,
sample=0x7fffd140, evsel=0x90f1d0, machine=0x90e6b8) at
util/session.c:930
#18 0x0049e107 in perf_session_deliver_event (session=0x90e5e0,
event=0x717aea30, sample=0x7fffd140,
tool=0x7fffd510, file_offset=821808) at util/session.c:984
#19 0x0049cfb4 in flush_sample_queue (s=0x90e5e0,
tool=0x7fffd510) at util/session.c:526
#20 0x0049ef53 in __perf_session__process_events (session=0x90e5e0,
data_offset=216, data_size=832400, file_size=832616,
tool=0x7fffd510) at util/session.c:1371
#21 0x0049f02e in perf_session__process_events (session=0x90e5e0,
tool=0x7fffd510) at util/session.c:1389
#22 0x0042d605 in __cmd_report (rep=0x7fffd510) at
builtin-report.c:527
---Type return to continue, or q return to quit---
Applied all except this one and the other one David commented on,
waiting for that discussion to reach some conclusion.
But with the ones applied 'perf report -s srcline' is _much_ faster,
thanks!
- Arnaldo
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/srcline.c | 53
+--
1 file changed, 1 insertion(+), 52 deletions(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 93795f9..e09c9e0 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -29,54 +29,6 @@ struct a2l_data {
asymbol **syms;
};
-static int bfd_error(const char *string)
-{
-const char *errmsg;
-
-errmsg = bfd_errmsg(bfd_get_error());
-fflush(stdout);
-
-if (string)
-pr_debug(%s: %s\n, string, errmsg);
-else
-pr_debug(%s\n, errmsg);
-
-return -1;
-}
-
-static int slurp_symtab(bfd *abfd, struct a2l_data *a2l)
-{
-long storage;
-long symcount;
-asymbol **syms;
-bfd_boolean dynamic = FALSE;
-
-if ((bfd_get_file_flags(abfd) HAS_SYMS) == 0)
-return bfd_error(bfd_get_filename(abfd));
-
-storage = bfd_get_symtab_upper_bound(abfd);
-if (storage == 0L) {
-storage = bfd_get_dynamic_symtab_upper_bound(abfd);
-dynamic = TRUE;
-}
-if (storage 0L)
-return bfd_error(bfd_get_filename(abfd));
-
-syms = malloc(storage);
-if (dynamic)
-symcount = bfd_canonicalize_dynamic_symtab(abfd, syms);
-else
-symcount =
Re: [PATCH 6/7] perf tools: Do not need to read symbols for source line lookup
Em Wed, Dec 04, 2013 at 04:00:18PM +0200, Adrian Hunter escreveu: On 03/12/13 22:24, Arnaldo Carvalho de Melo wrote: Em Tue, Dec 03, 2013 at 09:23:09AM +0200, Adrian Hunter escreveu: When using libbfd to lookup source filename and line number, libbfd does not need the symbol table. Removing the symbol table reading, doubles the speed of 'perf script' with the 'srcline' option. [root@zoo ~]# gdb perf run report -s srcline b0m I wasn't able to reproduce this but I noticed the line numbers were not found for kernel modules with this patch - so it seems some binaries need the symbol information and some don't. So please disregard this patch, sorry for your trouble. No problem, disregarding it. - Arnaldo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] perf tools: Do not need to read symbols for source line lookup
Em Tue, Dec 03, 2013 at 09:23:09AM +0200, Adrian Hunter escreveu:
> When using libbfd to lookup source filename and line number,
> libbfd does not need the symbol table. Removing the symbol
> table reading, doubles the speed of 'perf script' with the
> 'srcline' option.
[root@zoo ~]# gdb perf
run report -s srcline
b0m
bt
#0 0x0050ac60 in read_unsigned_leb128 ()
#1 0x005189f7 in find_abstract_instance_name.isra.20 ()
#2 0x005190e1 in scan_unit_for_symbols ()
#3 0x00519a69 in comp_unit_find_nearest_line ()
#4 0x0051a6ff in find_line.part.26 ()
#5 0x00531063 in _bfd_elf_find_nearest_line_discriminator ()
#6 0x0053117b in _bfd_elf_find_nearest_line ()
#7 0x004bf22d in find_address_in_section (abfd=0x39de5f0,
section=0x3a32c38, data=0x3901950) at util/srcline.c:51
#8 0x0050ccdc in bfd_map_over_sections ()
#9 0x004bf48b in addr2line (dso_name=0x39fb830
"/lib/modules/3.13.0-rc1+/kernel/drivers/gpu/drm/drm.ko", addr=20832,
file=0x7fffcc00, line=0x7fffcbfc, dso=0x90f9e0) at
util/srcline.c:116
#10 0x004bf608 in get_srcline (dso=0x90f9e0, addr=20832) at
util/srcline.c:217
#11 0x004b00fe in sort__srcline_cmp (left=0x1dc76f0,
right=0x7fffcd70) at util/sort.c:268
#12 0x004b3942 in hist_entry__cmp (left=0x1dc76f0,
right=0x7fffcd70) at util/hist.c:450
#13 0x004b35f4 in add_hist_entry (hists=0x90f278, entry=0x7fffcd70,
al=0x7fffcf90, period=399301, weight=0)
at util/hist.c:367
#14 0x004b38d8 in __hists__add_entry (hists=0x90f278,
al=0x7fffcf90, sym_parent=0x0, bi=0x0, mi=0x0, period=399301,
weight=0, transaction=0) at util/hist.c:440
#15 0x0042c9da in perf_evsel__add_hist_entry (tool=0x7fffd510,
evsel=0x90f1d0, al=0x7fffcf90, sample=0x7fffd140,
machine=0x90e6b8) at builtin-report.c:274
#16 0x0042cd4f in process_sample_event (tool=0x7fffd510,
event=0x717aea30, sample=0x7fffd140, evsel=0x90f1d0,
machine=0x90e6b8) at builtin-report.c:347
#17 0x0049df43 in perf_session__deliver_sample (session=0x90e5e0,
tool=0x7fffd510, event=0x717aea30,
sample=0x7fffd140, evsel=0x90f1d0, machine=0x90e6b8) at
util/session.c:930
#18 0x0049e107 in perf_session_deliver_event (session=0x90e5e0,
event=0x717aea30, sample=0x7fffd140,
tool=0x7fffd510, file_offset=821808) at util/session.c:984
#19 0x0049cfb4 in flush_sample_queue (s=0x90e5e0, tool=0x7fffd510)
at util/session.c:526
#20 0x0049ef53 in __perf_session__process_events (session=0x90e5e0,
data_offset=216, data_size=832400, file_size=832616,
tool=0x7fffd510) at util/session.c:1371
#21 0x0049f02e in perf_session__process_events (session=0x90e5e0,
tool=0x7fffd510) at util/session.c:1389
#22 0x0042d605 in __cmd_report (rep=0x7fffd510) at
builtin-report.c:527
---Type to continue, or q to quit---
Applied all except this one and the other one David commented on,
waiting for that discussion to reach some conclusion.
But with the ones applied 'perf report -s srcline' is _much_ faster,
thanks!
- Arnaldo
> Signed-off-by: Adrian Hunter
> ---
> tools/perf/util/srcline.c | 53
> +--
> 1 file changed, 1 insertion(+), 52 deletions(-)
>
> diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> index 93795f9..e09c9e0 100644
> --- a/tools/perf/util/srcline.c
> +++ b/tools/perf/util/srcline.c
> @@ -29,54 +29,6 @@ struct a2l_data {
> asymbol **syms;
> };
>
> -static int bfd_error(const char *string)
> -{
> - const char *errmsg;
> -
> - errmsg = bfd_errmsg(bfd_get_error());
> - fflush(stdout);
> -
> - if (string)
> - pr_debug("%s: %s\n", string, errmsg);
> - else
> - pr_debug("%s\n", errmsg);
> -
> - return -1;
> -}
> -
> -static int slurp_symtab(bfd *abfd, struct a2l_data *a2l)
> -{
> - long storage;
> - long symcount;
> - asymbol **syms;
> - bfd_boolean dynamic = FALSE;
> -
> - if ((bfd_get_file_flags(abfd) & HAS_SYMS) == 0)
> - return bfd_error(bfd_get_filename(abfd));
> -
> - storage = bfd_get_symtab_upper_bound(abfd);
> - if (storage == 0L) {
> - storage = bfd_get_dynamic_symtab_upper_bound(abfd);
> - dynamic = TRUE;
> - }
> - if (storage < 0L)
> - return bfd_error(bfd_get_filename(abfd));
> -
> - syms = malloc(storage);
> - if (dynamic)
> - symcount = bfd_canonicalize_dynamic_symtab(abfd, syms);
> - else
> - symcount = bfd_canonicalize_symtab(abfd, syms);
> -
> - if (symcount < 0) {
> - free(syms);
> - return bfd_error(bfd_get_filename(abfd));
> - }
> -
> - a2l->syms = syms;
> - return 0;
> -}
> -
> static void find_address_in_section(bfd *abfd, asection *section, void *data)
Re: [PATCH 6/7] perf tools: Do not need to read symbols for source line lookup
Em Tue, Dec 03, 2013 at 09:23:09AM +0200, Adrian Hunter escreveu:
When using libbfd to lookup source filename and line number,
libbfd does not need the symbol table. Removing the symbol
table reading, doubles the speed of 'perf script' with the
'srcline' option.
[root@zoo ~]# gdb perf
run report -s srcline
b0m
bt
#0 0x0050ac60 in read_unsigned_leb128 ()
#1 0x005189f7 in find_abstract_instance_name.isra.20 ()
#2 0x005190e1 in scan_unit_for_symbols ()
#3 0x00519a69 in comp_unit_find_nearest_line ()
#4 0x0051a6ff in find_line.part.26 ()
#5 0x00531063 in _bfd_elf_find_nearest_line_discriminator ()
#6 0x0053117b in _bfd_elf_find_nearest_line ()
#7 0x004bf22d in find_address_in_section (abfd=0x39de5f0,
section=0x3a32c38, data=0x3901950) at util/srcline.c:51
#8 0x0050ccdc in bfd_map_over_sections ()
#9 0x004bf48b in addr2line (dso_name=0x39fb830
/lib/modules/3.13.0-rc1+/kernel/drivers/gpu/drm/drm.ko, addr=20832,
file=0x7fffcc00, line=0x7fffcbfc, dso=0x90f9e0) at
util/srcline.c:116
#10 0x004bf608 in get_srcline (dso=0x90f9e0, addr=20832) at
util/srcline.c:217
#11 0x004b00fe in sort__srcline_cmp (left=0x1dc76f0,
right=0x7fffcd70) at util/sort.c:268
#12 0x004b3942 in hist_entry__cmp (left=0x1dc76f0,
right=0x7fffcd70) at util/hist.c:450
#13 0x004b35f4 in add_hist_entry (hists=0x90f278, entry=0x7fffcd70,
al=0x7fffcf90, period=399301, weight=0)
at util/hist.c:367
#14 0x004b38d8 in __hists__add_entry (hists=0x90f278,
al=0x7fffcf90, sym_parent=0x0, bi=0x0, mi=0x0, period=399301,
weight=0, transaction=0) at util/hist.c:440
#15 0x0042c9da in perf_evsel__add_hist_entry (tool=0x7fffd510,
evsel=0x90f1d0, al=0x7fffcf90, sample=0x7fffd140,
machine=0x90e6b8) at builtin-report.c:274
#16 0x0042cd4f in process_sample_event (tool=0x7fffd510,
event=0x717aea30, sample=0x7fffd140, evsel=0x90f1d0,
machine=0x90e6b8) at builtin-report.c:347
#17 0x0049df43 in perf_session__deliver_sample (session=0x90e5e0,
tool=0x7fffd510, event=0x717aea30,
sample=0x7fffd140, evsel=0x90f1d0, machine=0x90e6b8) at
util/session.c:930
#18 0x0049e107 in perf_session_deliver_event (session=0x90e5e0,
event=0x717aea30, sample=0x7fffd140,
tool=0x7fffd510, file_offset=821808) at util/session.c:984
#19 0x0049cfb4 in flush_sample_queue (s=0x90e5e0, tool=0x7fffd510)
at util/session.c:526
#20 0x0049ef53 in __perf_session__process_events (session=0x90e5e0,
data_offset=216, data_size=832400, file_size=832616,
tool=0x7fffd510) at util/session.c:1371
#21 0x0049f02e in perf_session__process_events (session=0x90e5e0,
tool=0x7fffd510) at util/session.c:1389
#22 0x0042d605 in __cmd_report (rep=0x7fffd510) at
builtin-report.c:527
---Type return to continue, or q return to quit---
Applied all except this one and the other one David commented on,
waiting for that discussion to reach some conclusion.
But with the ones applied 'perf report -s srcline' is _much_ faster,
thanks!
- Arnaldo
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/srcline.c | 53
+--
1 file changed, 1 insertion(+), 52 deletions(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 93795f9..e09c9e0 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -29,54 +29,6 @@ struct a2l_data {
asymbol **syms;
};
-static int bfd_error(const char *string)
-{
- const char *errmsg;
-
- errmsg = bfd_errmsg(bfd_get_error());
- fflush(stdout);
-
- if (string)
- pr_debug(%s: %s\n, string, errmsg);
- else
- pr_debug(%s\n, errmsg);
-
- return -1;
-}
-
-static int slurp_symtab(bfd *abfd, struct a2l_data *a2l)
-{
- long storage;
- long symcount;
- asymbol **syms;
- bfd_boolean dynamic = FALSE;
-
- if ((bfd_get_file_flags(abfd) HAS_SYMS) == 0)
- return bfd_error(bfd_get_filename(abfd));
-
- storage = bfd_get_symtab_upper_bound(abfd);
- if (storage == 0L) {
- storage = bfd_get_dynamic_symtab_upper_bound(abfd);
- dynamic = TRUE;
- }
- if (storage 0L)
- return bfd_error(bfd_get_filename(abfd));
-
- syms = malloc(storage);
- if (dynamic)
- symcount = bfd_canonicalize_dynamic_symtab(abfd, syms);
- else
- symcount = bfd_canonicalize_symtab(abfd, syms);
-
- if (symcount 0) {
- free(syms);
- return bfd_error(bfd_get_filename(abfd));
- }
-
- a2l-syms = syms;
- return 0;
-}
-
static void find_address_in_section(bfd *abfd, asection *section, void *data)
{
bfd_vma pc, vma;
@@ -96,7
