FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 02-03-2010, 01:27 AM
Piet Delaney
 
Default Crash Subscription - Something Wrong

Dave Anderson wrote:

Piet Delaney wrote:

Hi Dave [I moved]:

I subscribed to your crash mailing list last evening and didn't receive
anything yet.

Looks like there was a posting today.


I remember approving your subscription request. Looking at the current
list of subscribers, I see these two:

Piet.Delaney@tensilica.com
piet@bluelane.com

How much work do you think it would take to add the xtensa architecture
to crash?
From our IA64 work together I recall it mostly being the backtrace code
needing work.


That's certainly a big part of it, but that's only the "gravy" that needs
to be done after all of the foundational work is done. New architectures
basically require:

1. cloning the arch-specific parts of configure.c so that there
can be "#ifdef XTENSA" parts of the code.
2. creating a new "xtensa.c" file that satisfies all of the
requirements for the generic machdep-><architecture-data> and
machdep-><architecture-function> fields used throughout the
common code. The crash sources do contain a template PLATFORM.c
file, which is a bit dated and will most likely not have everything
needed, but it's a good place to start. You would basically copy
PLATFORM.c to xtensa.c, and then do a "s/PLATFORM/xtensa/" on the
file, and then start working on the specifics.


I'll start work on xtensa.c next now that configure.c seems to be fine.


3. in conjunction with step 2, satisfying all of the "common" #define's
in defs.h.
4. After 1, 2 and 3 are done, update the Makefile to compile the
new file, and as it continually fails due to missing stuff, fix then
one step at a time.
5. At that point, you can start working on stuff like the backtrace
implementation.

Although -- now that I think of it -- none of the above will be worth
a damn without gdb support of the architecture. And gdb-6.1 certainly
doesn't have it unless it's a clone of some pre-existing architecture.


With your new crash 5.0 and it's use of gdb-8.0 that's no longer a problem.



So that's a whole other can of worms. Updating the version of gdb to
"merge" with the crash sources is yet another massive, always prone-to-error,
always finding-something-that-no-long-applies-anymore, situation.


Besides my maintaining a subscription to your mailing list I've created a crash-xtensa
mailing list at linux-xtensa.org and an associated crash-xtensa-commits for logging the
git repository changes. Your welcome to be a list administrators if your interested to to
recommend when to push changes/patches to your repository.

Should be interesting but likely a rather slow effort; lots of other stuff on my plate.

-piet



Dave


Some the the 'vm' command functionality would be helpful right now to debug
a cache/tldb bug that I'm looking at.

-piet




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 01:28 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org