Dwarves Archive on lore.kernel.org
 help / color / Atom feed
* [RFT] Request for testing
@ 2009-03-15  3:21 Arnaldo Carvalho de Melo
       [not found] ` <20090315032138.GB22651-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Arnaldo Carvalho de Melo @ 2009-03-15  3:21 UTC (permalink / raw)
  To: dwarves-u79uwXL29TY76Z2rM5mHXA

Hi guys,

	I'm back working on these tools trying to get the in memory
representation to be closer to CTF than to DWARF, i.e.:

o  class_member instances will not have bit_size/bit_offset, that will
   have to be inferred from the base_type with a number of bits less than
   what it would be in DWARF land

o the strings for quite a while already are just indexes into a table
  that will then be compressed when encoding in CTF, and at some point
  will be loaded from CTF directly, without further processing

o The types are being recoded, i.e. cu->types_table, uint16_t entries
  instead of Dwarf_Off types that have to be looked up on a hash table,
  etc.

	Right now I'm trying to insert new base types for the bitfields,
after that we'll be almost there to just dump the in memory
representation into a CTF file. 

	I intend to use the buildid to name a file in a ~/.pahole/
ccache like hierarchy so that the next time we try to load a DWARF
section we instead short circuit to the buildid named file in the cache
to get much, much faster loading.

	Aside from that there are many more improvements, but as we all
know if we do too many changes in one go, as bold as we may feel, bugs
may creep in, so:

	Please, please try what is in the git repo right now, and report
to this list any regressions.

	I have some regression tests where I process with the previously
released version lots of CTF and DWARF encoded C and C++ object files
and then with the new version and finally a diff to see if anything
went bazoo, and all I can say is that right now all I can see is faster
processing, a helluva smaller memory footprint and more correct output :-)

	But if you can prove me wrong, I'll do my best to get that
fixed, and that I guess is a good deal, huh?

	If all goes well I'll tag 1.8 and then get back to getting the
dwarves CTFicated.

Thanks a lot guys,

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Status of Union
       [not found] ` <20090315032138.GB22651-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
@ 2009-03-20 20:22   ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 2+ messages in thread
From: Arnaldo Carvalho de Melo @ 2009-03-20 20:22 UTC (permalink / raw)
  To: dwarves-u79uwXL29TY76Z2rM5mHXA

Hi Folks,

	Even if just to dump what I have to say, here it goes:

Converting all the object files in a Linux make allyesconfig build
leaves us with just these mismatches from what is in the DWARF info and
what is in the CTF info, for types, for the information gathered by the
dwarves tools:

[acme@emilia allyesconfig]$ l /tmp/ctfdwdiff_allyesconfig/*.diff
-rw-rw-r-- 1 acme acme  7154 Mar 20 15:18 /tmp/ctfdwdiff_allyesconfig/BusLogic.o.diff
-rw-rw-r-- 1 acme acme  1766 Mar 20 15:28 /tmp/ctfdwdiff_allyesconfig/callback.o.diff
-rw-rw-r-- 1 acme acme  1410 Mar 20 15:11 /tmp/ctfdwdiff_allyesconfig/config_roms.o.diff
-rw-rw-r-- 1 acme acme   959 Mar 20 15:17 /tmp/ctfdwdiff_allyesconfig/cxio_hal.o.diff
-rw-rw-r-- 1 acme acme 25555 Mar 20 15:13 /tmp/ctfdwdiff_allyesconfig/DAC960.o.diff
-rw-rw-r-- 1 acme acme  1412 Mar 20 15:16 /tmp/ctfdwdiff_allyesconfig/firedtv-1394.o.diff
-rw-rw-r-- 1 acme acme  1009 Mar 20 15:19 /tmp/ctfdwdiff_allyesconfig/libfcoe.o.diff
[acme@emilia allyesconfig]$

The cases can be subsumed to:

1. packed enums, be it in typedefs or directly in the struct member
declaration.

2. CTF doesn't seem to be expressive enough to carry the type of a
forward declaration, i.e. if its "union foo" or "struct foo" it couldn't
care less, as this wouldn't help whatever tools at all.

So I'll concentrate on #1 and then get to the merge stuff, then back to
work on the other sections besides the types section so cherished by
pahole :-)

As always, whatever reports you may have, I'll do my best to keep this
project kicking and helpful for people interested in what is here and in
what can be done once some legwork is in place.

Best Regards,

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-15  3:21 [RFT] Request for testing Arnaldo Carvalho de Melo
     [not found] ` <20090315032138.GB22651-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>
2009-03-20 20:22   ` Status of Union Arnaldo Carvalho de Melo

Dwarves Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dwarves/0 dwarves/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dwarves dwarves/ https://lore.kernel.org/dwarves \
		dwarves@vger.kernel.org
	public-inbox-index dwarves

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.dwarves


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git