EST's VisionClick debugger fixes for Elf files from GNU tools

[Ron Bianco]

In case others are using the same VisionClick/VisionProbe JTAG debugger from EST ( now
WindRiver ) I'm posting this thread.
They will be releasing a new version soon that will fix some problems it had with ELF
files generated by the GNU tools. (PPC)

Also of note is the fact that there is an undocumented and unmentioned tool called
CreateBin.exe in the EST install dir.
It will create an EST flat bin file, from any arbitrary file, that Click will load.

It is especially useful for dealing with a kernel with initrd situation, as EST's convert
tool ignores the image sections.
The kernel (vmlinux) can be loaded and source level debugged normally and the compressed
initrd rootfs can be subsequently loaded anywhere in mem.  after CreateBin is used on it.
(i.e. at the physical address that the kernel has been compiled to expect to find the
ramdisk.image.gz image).

Normally the initrd file offset etc. is defined when arch/ppc/boot/misc.c is re-compiled,
but in my case I don't use the secondary boot loader so I've created a post build script
that uses the same technique and re-compile sandpoint_setup.c with the offset and size
info.
I do something very similar to misc.c in sandpoint_setup.c.

BTW, at some point I'll create my own renamed copy of the sandpoint files for our board so
as to avoid extra work when MontaVista updates their sandpoint files.

I also had to modify arch/ppc/Makefile to add the offset and size defines ( zero ) to the
CFLAGS list.

The only problem with this technique, is that the size of the kernel changes slightly when
the offset and size defines are non-zero.  Not sure if this also happens for the normal
zvmlinux etc. build process.
Slighty different code must be generated?  Don't have time right now, to really check this
and it is easy to deal with anyway.

If anyone wants that script, let me know.  Cheers, Ron

Ron Bianco
Computer Systems Technologist
Level Control Systems
email: ronb at junction.net
phone: 250-549-2558 Ext 8
web:  www.lcsaudio.com

**** thread starts ****
Ron -
It looks like the elf file is correct. The GNU compiler is generating dis-contiguous
module code and we have to do some work in both the convert utility and Click to account
for the separate sections within the module.  We are working on it -- I will keep you
posted.

...gregj


----- Original Message -----
From: Ron Bianco
To: Greg J
Cc: pete.redlien at windriver.com
Sent: Tuesday, September 05, 2000 6:26 PM
Subject: RE: wrong source for function


Hi Greg,  Any progress on this?  I can see why Click would have problems with this.

Is my elf file screwed?   If it is a GNU linker problem, I should try to track this down.
What does the Convert guy say?

It would very cool and helpful to get this working right.

Cheers, Ron
-----Original Message-----
From: Greg J [mailto:gregj at estc.com]
Sent: Friday, August 25, 2000 9:35 PM
To: Ron Bianco
Cc: Pete Redlien; briann at estc.com
Subject: wrong source for function


Ron -
I will attached a newer version of CLick that should restore your assembly labels in a
separate email.

The wrong source problem is being caused by the symbol information.  CLick thinks the
address for ncr_snooptest falls in the range of init_microspeed in mac_key.c.  In looking
at the symbol infomation that convert is producing from your elf file, I find a lot of
suspect function end addresses -- I have copy of handful of samples below.  These "large"
suspect ranges overlap the ligitimate ones an in this particular case, click finds
init_microspeed before it finds ncr_snooptest.

I will have our symbol expert look at the file to see if this is an elf file problem or a
convert problem.

regards...gregj
**** thread ends ****


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/