From pmuldoon@redhat.com Sat Jul 1 02:23:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Sat, 01 Jul 2006 02:23:00 -0000 Subject: the status automation machine graph for frysk In-Reply-To: References: Message-ID: <1151720346.2964.3.camel@phil-amd64x2> Wu Thanks a lot! That's an absolutely superb piece of work, and much needed. Is this hand crafted by yourself? I already printed it out and pinned it on the wall. ;) Regards Phil On Wed, 2006-06-28 at 17:42 +0800, Wu Zhou wrote: > Hi guys, > > Here is the graph I promised to send in the meeting of this Monday. But > I returned late that day, the high-speed internet access expired. So I > don't bother to spend another $15 for that, because we are expected to > leave early next morning. Sorry for that! > > Regards > - Wu Zhou From pmuldoon@redhat.com Sat Jul 1 02:23:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Sat, 01 Jul 2006 02:23:00 -0000 Subject: the status automation machine graph for frysk In-Reply-To: References: Message-ID: <1151720374.2964.5.camel@phil-amd64x2> On Wed, 2006-06-28 at 17:42 +0800, Wu Zhou wrote: > Hi guys, > > Here is the graph I promised to send in the meeting of this Monday. But > I returned late that day, the high-speed internet access expired. So I > don't bother to spend another $15 for that, because we are expected to > leave early next morning. Sorry for that! > > Regards > - Wu Zhou From qiyaoltc@cn.ibm.com Sat Jul 1 12:49:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Sat, 01 Jul 2006 12:49:00 -0000 Subject: the status automation machine graph for frysk In-Reply-To: <17573.14784.636496.219814@localhost.redhat.com> References: <17573.14784.636496.219814@localhost.redhat.com> Message-ID: <20060701124147.GC29045@GreenHouse.cn.ibm.com> On Fri, Jun 30, 2006 at 10:48:32AM -0400, Elena Zannoni wrote: > > Thanks Wu! Is there a way to share an editable version of the > diagram, so that we can make changes? > > thanks > elena > Hi, Elena, This diagram is made by "Dia Diagram Editor", and here is the "source" to this diagram. Hope this useful to make Task State Machine easy to understand. :) Any comments to this diagram are appreciated, and we will update it per your comments! -- Yao Qi -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-task-state-machine.dia Type: application/octet-stream Size: 7972 bytes Desc: not available URL: From woodzltc@cn.ibm.com Sun Jul 2 15:10:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sun, 02 Jul 2006 15:10:00 -0000 Subject: the status automation machine graph for frysk In-Reply-To: <17573.14784.636496.219814@localhost.redhat.com> References: <17573.14784.636496.219814@localhost.redhat.com> Message-ID: Hi Elena, Just got back to Bei Jing. Sorry for replying lately. On Fri, 30 Jun 2006, Elena Zannoni wrote: > Wu Zhou writes: > > Hi guys, > > > > Here is the graph I promised to send in the meeting of this Monday. But > > I returned late that day, the high-speed internet access expired. So I > > don't bother to spend another $15 for that, because we are expected to > > leave early next morning. Sorry for that! > > > > Regards > > - Wu Zhou > > Thanks Wu! Is there a way to share an editable version of the > diagram, so that we can make changes? Surely, we are very happy to do that. I will get into office tomorrow morning and discuss with Yao Qi, who created this diagram, to work out a way to share and co-author this diagram. I believe it is helpful for the frysk team to have a common and latest automation diagram, which can reflect the status of the art. Regards - Wu Zhou From mcvet@redhat.com Mon Jul 3 15:48:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Mon, 03 Jul 2006 15:48:00 -0000 Subject: The memory window Message-ID: <1151941868.19956.10.camel@Warbird.Nifelheim> Hey all, Currently I'm working on implementing the memory window. If any of you have ever used the 'examine memory' data tool from ddd, this is similar to the functionality I would like to have. As of last week, the window displayed all 32 bit words in binary, octal, decimal and hex from the current program counter to a predetermined memory location. As of today, I am working on supporting endian-ness and reading information from memory in 4, 8, 16, 32, and 64 bit chunks. As you can see in the screenshot, the "from" spinbox determines where the words should begin to be read from (will default to the PC) and "to" is where the reading ends. "edit columns" displays options for the number of bits, endian-ness, and radix. Let me know if there are any suggestions, on the interface or otherwise. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: memorywindow.jpg Type: image/jpeg Size: 15599 bytes Desc: not available URL: From mark@klomp.org Mon Jul 3 17:57:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 03 Jul 2006 17:57:00 -0000 Subject: Adding breakpoints Message-ID: <1151949450.2526.20.camel@elsschot.wildebeest.org> Hi, I was playing with adding (low-level) breakpoint support to Tasks and came up with the following setup. We add a BreakpointAddresses class which keeps track of the actual breakpoints needed (one address can have multiple observers). The Task uses this BreakpointAddresses class to notify the observers when it traps a breakpoint. The BreakpointAddresses class interacts with the Task to actually set and remove the breakpoints when needed, and tells the Task when it needs to start or when it can stop tracing breakpoints (because none are left). When a breakpoint is added or removed in a state that doesn't immediately allow setting/removing a breakpoint (normally that can only be done when the Task is in an suspended state) then the BreakpointAddresses class lets the Task know it has updates of the breakpoints list and gets called by the Task as soon as it enters a TaskState that allows addition/removal of breakpoints. An draft of the BreakpointAddresses class and the methods it uses is attached. Some open questions on which I hope to get answers when implementing the rest (or maybe someone already has ideas on these): - What is the precise thread model used? The data-structures of this class are thread safe, but that might be overkill if observers are always added from the same thread. - Breakpoints should be removed from a cloned task, or shouldn't they? Or should that be a property per observer? - Is this setup powerful enough to add higher level language breakpoints on top of it? Comments welcome. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: BreakpointAddresses.java Type: text/x-java Size: 6782 bytes Desc: not available URL: From mark@klomp.org Tue Jul 4 10:24:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 04 Jul 2006 10:24:00 -0000 Subject: Adding breakpoints In-Reply-To: <1151949450.2526.20.camel@elsschot.wildebeest.org> References: <1151949450.2526.20.camel@elsschot.wildebeest.org> Message-ID: <1152008675.2555.21.camel@elsschot.wildebeest.org> On Mon, 2006-07-03 at 19:57 +0200, Mark Wielaard wrote: > Some open questions on which I hope to get answers when implementing > the rest (or maybe someone already has ideas on these): > > - Breakpoints should be removed from a cloned task, or shouldn't they? > Or should that be a property per observer? Just to answer my own question/confusion after having played a bit more with it all. A cloned task shares the address space with the original task so they do share all breakpoints set (or unset). This means that we need a bit more administration. Cloned Tasks need to share their BreakpointAddresses. It also means that if we want to continue the process by temporarily erasing the breakpoint, setting back the original code and stepping and putting back the breakpoint then we must make sure all cloned tasks are suspended till we have set back the breakpoint. Otherwise they might miss a breakpoint. Mark From mark@klomp.org Tue Jul 4 10:45:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 04 Jul 2006 10:45:00 -0000 Subject: Additional PtraceBuffer tests Message-ID: <1152009913.2555.29.camel@elsschot.wildebeest.org> Hi, While playing with the differences between fork() and clone() I reread and reused the PtraceBuffer tests to verify some of my understanding and noticed a small typo in the test and an omission from an earlier version of this test. We weren't checking in all cases whether the PtraceBuffer was operating on the right memory space (that of the child, not of the parent). This patch adds some more checks to make the test more robust. 2006-07-04 Mark Wielaard * frysk-sys/frysk/sys/TestPtraceByteBuffer.java (testTextVariable): Make sure we are manipulating only the child text area not our own. All these tests PASS. I committed this, Mark From mark@klomp.org Tue Jul 4 10:59:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 04 Jul 2006 10:59:00 -0000 Subject: Additional PtraceBuffer tests In-Reply-To: <1152009913.2555.29.camel@elsschot.wildebeest.org> References: <1152009913.2555.29.camel@elsschot.wildebeest.org> Message-ID: <1152010777.2555.30.camel@elsschot.wildebeest.org> On Tue, 2006-07-04 at 12:45 +0200, Mark Wielaard wrote: > This patch adds some more checks to make the test more robust. > > 2006-07-04 Mark Wielaard > > * frysk-sys/frysk/sys/TestPtraceByteBuffer.java > (testTextVariable): Make sure we are manipulating only the child > text area not our own. Now with actual patch attached. Duh... -------------- next part -------------- A non-text attachment was scrubbed... Name: ptrace-test.patch Type: text/x-patch Size: 3118 bytes Desc: not available URL: From swagiaal@redhat.com Tue Jul 4 18:44:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Tue, 04 Jul 2006 18:44:00 -0000 Subject: the status automation machine graph for frysk In-Reply-To: <44A42875.20404@redhat.com> References: <1151584712.2533.73.camel@elsschot.wildebeest.org> <44A42875.20404@redhat.com> Message-ID: <44AAB6E5.2080006@redhat.com> >> - Some methods like handleAddObserver() and handleDeleteObserver() >> always do the same thing and never actually do any state transition. >> >> This adds a lot of (duplicate) code without being clear what it has to >> do with with the actual state machine. >> > Duplicate code worries me too. Inheritance is a solution but as Cagney > as mentioned > before: the flat code is easier to read. Also I would much prefer that > I accedentaly forget > to implement a function casing frysk to crash than accidentally pick > up a function from a > parent and do incorrect handling. One way to get rid of duplicate code is to have static utility functions that do the repeated code. I know this doesnt feel very OO... what do u think ? From cagney@redhat.com Wed Jul 5 04:33:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 05 Jul 2006 04:33:00 -0000 Subject: Adding breakpoints In-Reply-To: <1151949450.2526.20.camel@elsschot.wildebeest.org> References: <1151949450.2526.20.camel@elsschot.wildebeest.org> Message-ID: <44AB4131.9010507@redhat.com> Mark Wielaard wrote: > Hi, > > I was playing with adding (low-level) breakpoint support to Tasks and > came up with the following setup. We add a BreakpointAddresses class > which keeps track of the actual breakpoints needed (one address can have > multiple observers). The Task uses this BreakpointAddresses class to > notify the observers when it traps a breakpoint. The BreakpointAddresses > class interacts with the Task to actually set and remove the breakpoints > when needed, and tells the Task when it needs to start or when it can > stop tracing breakpoints (because none are left). When a breakpoint is > added or removed in a state that doesn't immediately allow > setting/removing a breakpoint (normally that can only be done when the > Task is in an suspended state) then the BreakpointAddresses class lets > the Task know it has updates of the breakpoints list and gets called by > the Task as soon as it enters a TaskState that allows addition/removal > of breakpoints. An draft of the BreakpointAddresses class and the > methods it uses is attached. > > Some open questions on which I hope to get answers when implementing the > rest (or maybe someone already has ideas on these): > > - What is the precise thread model used? The data-structures of this > class are thread safe, but that might be overkill if observers are > always added from the same thread. > you mean for frysk? anything involving the core gets routed through the event-loop and its thread (which is also responsible for juggling kernel events). This is why there's a public Task.requestBLAH that injects an event to call Task.handleBLAH from the event-loop. Yea, that part of the design is deliberately conservative - get it working, then get it working fast :-) > - Breakpoints should be removed from a cloned task, or shouldn't they? > Or should that be a property per observer? > Good question. I think, if the client wants a breakpoint on the new cloned task then they will have a cloned observer that adds breakpoints to each cloned task. > - Is this setup powerful enough to add higher level language breakpoints > on top of it? > Yep. In the end a breakpoint is reduced to an address, this code only needs to handle those addresses. Higher level problems such as module loading and unloading, and projecting a user level breakpoint onto one or more of these code observers are just that, higher level problems. The high level code calls on this and other primitives to implement those abstractions. Andrew From mark@klomp.org Wed Jul 5 09:29:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 05 Jul 2006 09:29:00 -0000 Subject: the status automation machine graph for frysk In-Reply-To: <44AAB6E5.2080006@redhat.com> References: <1151584712.2533.73.camel@elsschot.wildebeest.org> <44A42875.20404@redhat.com> <44AAB6E5.2080006@redhat.com> Message-ID: <1152091725.2577.16.camel@elsschot.wildebeest.org> On Tue, 2006-07-04 at 14:43 -0400, Sami Wagiaalla wrote: > >> - Some methods like handleAddObserver() and handleDeleteObserver() > >> always do the same thing and never actually do any state transition. > >> > >> This adds a lot of (duplicate) code without being clear what it has to > >> do with with the actual state machine. > >> > > Duplicate code worries me too. Inheritance is a solution but as Cagney > > as mentioned > > before: the flat code is easier to read. Also I would much prefer that > > I accedentaly forget > > to implement a function casing frysk to crash than accidentally pick > > up a function from a > > parent and do incorrect handling. > > One way to get rid of duplicate code is to have static utility functions > that do the repeated > code. I know this doesnt feel very OO... what do u think ? I think that would actually be fine. That way you can write out all the state transitions but have the actual implementation pretty small (just a call to one or two static methods). Assuming we name the methods nicely it could be pretty readable. Now that I better understand the TaskState (subclasses) design I think it might be clearer if we group things a little more in separate files for each "cluster" of TaskState subclasses (Attached, StartMainTask, StartClonedTask, Running, BlockedSignal). Then it is easier to see all state transitions of a group of subclasses together. (*) Cheers, Mark (*) I am sure someone will now jump up and show some way to do that easily with the eclipse class browser :) From mark@klomp.org Wed Jul 5 09:51:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 05 Jul 2006 09:51:00 -0000 Subject: Adding breakpoints In-Reply-To: <44AB4131.9010507@redhat.com> References: <1151949450.2526.20.camel@elsschot.wildebeest.org> <44AB4131.9010507@redhat.com> Message-ID: <1152093095.2577.22.camel@elsschot.wildebeest.org> Hi Andrew, On Wed, 2006-07-05 at 00:33 -0400, Andrew Cagney wrote: > > - What is the precise thread model used? The data-structures of this > > class are thread safe, but that might be overkill if observers are > > always added from the same thread. > > > you mean for frysk? anything involving the core gets routed through the > event-loop and its thread (which is also responsible for juggling kernel > events). This is why there's a public Task.requestBLAH that injects an > event to call Task.handleBLAH from the event-loop. Cool. That means no worrying about locking the datastructures used by the Task because there should be no concurrent change request. Nice. I'll remove the synchronization from my classes then. Cheers, Mark From rmoseley@redhat.com Wed Jul 5 12:35:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Wed, 05 Jul 2006 12:35:00 -0000 Subject: The memory window In-Reply-To: <1151941868.19956.10.camel@Warbird.Nifelheim> References: <1151941868.19956.10.camel@Warbird.Nifelheim> Message-ID: <44ABB1DE.5000503@redhat.com> That looks nice Mike! Good work there. I was thinking there needs to be some way to easily determine in what format the data is being displayed and make it pretty easy to change formats, preferably, IMHO, from the main screen. Maybe there could be tabs with a view showing each format(dec, hex, oct, etc.). Maybe these tabs could be "tear-away" where a user could look at 2 or more formats simultaneously? Just my 2??. Rick Mike Cvet wrote: > Hey all, > > Currently I'm working on implementing the memory window. If any of you > have ever used the 'examine memory' data tool from ddd, this is similar > to the functionality I would like to have. > > As of last week, the window displayed all 32 bit words in binary, octal, > decimal and hex from the current program counter to a predetermined > memory location. > > As of today, I am working on supporting endian-ness and reading > information from memory in 4, 8, 16, 32, and 64 bit chunks. > > As you can see in the screenshot, the "from" spinbox determines where > the words should begin to be read from (will default to the PC) and "to" > is where the reading ends. "edit columns" displays options for the > number of bits, endian-ness, and radix. > > Let me know if there are any suggestions, on the interface or otherwise. > > Mike > > > ------------------------------------------------------------------------ > From cmoller@redhat.com Wed Jul 5 14:13:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Wed, 05 Jul 2006 14:13:00 -0000 Subject: [Bug general/2880] New: ftkeventviewer doesn't compile (because of warnings) In-Reply-To: <20060705093115.2880.mark@klomp.org> References: <20060705093115.2880.mark@klomp.org> Message-ID: <44ABC902.1050102@redhat.com> Fixed and committed--sorry 'bout that. (I really ought to use -Werror on my sandbox compiles...) mark at klomp dot org mumbled something on 07/05/2006 05:31 AM: > make[3]: Entering directory `/home/mark/src/build/frysk-gtk/tlwidgets' > source='../../../frysk/frysk-gtk/tlwidgets/src/widgets/ftkeventviewer.c' > object='src/widgets/ftkeventviewer.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/sh ../../../frysk/frysk-gtk/../depcomp \ > gcc -DPACKAGE_NAME=\"frysk\" -DPACKAGE_TARNAME=\"frysk\" > -DPACKAGE_VERSION=\"0.0.1.2006.07.05\" -DPACKAGE_STRING=\"frysk\ > 0.0.1.2006.07.05\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"frysk\" > -DVERSION=\"0.0.1.2006.07.05\" -I. -I../../../frysk/frysk-gtk/tlwidgets > -fPIC -DPIC -std=gnu99 -Wall -Werror > -I../../../frysk/frysk-gtk/tlwidgets/src/widgets -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/libgtk-java -I/usr/include/glib-java -g -O -c -o > src/widgets/ftkeventviewer.o > ../../../frysk/frysk-gtk/tlwidgets/src/widgets/ftkeventviewer.c > cc1: warnings being treated as errors > ../../../frysk/frysk-gtk/tlwidgets/src/widgets/ftkeventviewer.c: In function > ?draw_dlink?: > ../../../frysk/frysk-gtk/tlwidgets/src/widgets/ftkeventviewer.c:579: warning: > unused variable ?loc? > ../../../frysk/frysk-gtk/tlwidgets/src/widgets/ftkeventviewer.c:577: warning: > unused variable ?trace_idx? > make[3]: *** [src/widgets/ftkeventviewer.o] Error 1 > make[3]: Leaving directory `/home/mark/src/build/frysk-gtk/tlwidgets' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/mark/src/build/frysk-gtk' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/mark/src/build/frysk-gtk' > make: *** [all-recursive] Error 1 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From timoore@redhat.com Wed Jul 5 17:50:00 2006 From: timoore@redhat.com (Tim Moore) Date: Wed, 05 Jul 2006 17:50:00 -0000 Subject: proposed refactoring of LinuxIA32 Message-ID: <44ABFBDD.9040709@redhat.com> Hi, I've started looking at supporting x86_64 in frysk. To that end I propose refactoring Isa, LinuxIA32 and friends. I've turned Isa into an interface implemented by IsaIA32 and IsaEMT64. There's also a new interface, SyscallEventDecoder, that just returns a SyscallEventInfo object. Then e.g., LinuxIA32 extends IsaIA32 and implements SyscallEventDecoder. Comments welcome on this code... Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: Isa.java Type: text/x-java Size: 2833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IsaIA32.java Type: text/x-java Size: 4111 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IsaEMT64.java Type: text/x-java Size: 4095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LinuxIa32.java Type: text/x-java Size: 3270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LinuxEMT64.java Type: text/x-java Size: 3277 bytes Desc: not available URL: From mcvet@redhat.com Wed Jul 5 21:12:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Wed, 05 Jul 2006 21:12:00 -0000 Subject: The memory window In-Reply-To: <44ABB1DE.5000503@redhat.com> References: <1151941868.19956.10.camel@Warbird.Nifelheim> <44ABB1DE.5000503@redhat.com> Message-ID: <1152133941.16510.5.camel@to-rhaps3.toronto.redhat.com> On Wed, 2006-07-05 at 07:34 -0500, Rick Moseley wrote: > That looks nice Mike! Good work there. > > I was thinking there needs to be some way to easily determine in what > format the data is being displayed and make it pretty easy to change > formats, preferably, IMHO, from the main screen. Maybe there could be > tabs with a view showing each format(dec, hex, oct, etc.). Maybe these > tabs could be "tear-away" where a user could look at 2 or more formats > simultaneously? > > Just my 2??. > > Rick > > > Mike Cvet wrote: > > Hey all, > > > > Currently I'm working on implementing the memory window. If any of you > > have ever used the 'examine memory' data tool from ddd, this is similar > > to the functionality I would like to have. > > > > As of last week, the window displayed all 32 bit words in binary, octal, > > decimal and hex from the current program counter to a predetermined > > memory location. > > > > As of today, I am working on supporting endian-ness and reading > > information from memory in 4, 8, 16, 32, and 64 bit chunks. > > > > As you can see in the screenshot, the "from" spinbox determines where > > the words should begin to be read from (will default to the PC) and "to" > > is where the reading ends. "edit columns" displays options for the > > number of bits, endian-ness, and radix. > > > > Let me know if there are any suggestions, on the interface or otherwise. > > > > Mike > > > > > > ------------------------------------------------------------------------ > > > Rick, Good ideas! I've attached a screenshot with some further work. This was just committed this evening and so is partially functional. Still having some problems with memory reads though. There are options to select endian-ness, number of bits, and radix, as suggested. In a little while I'll work on getting the SpinButtons to increment in multiple radii as well, and maybe implement some tabs. I know that the alignment/organization of the window is off, so let me know what the best arrangement might look like. I'm not very good with Glade yet. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.jpg Type: image/jpeg Size: 333577 bytes Desc: not available URL: From pmuldoon@redhat.com Wed Jul 5 21:37:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 05 Jul 2006 21:37:00 -0000 Subject: The memory window In-Reply-To: <1152133941.16510.5.camel@to-rhaps3.toronto.redhat.com> References: <1151941868.19956.10.camel@Warbird.Nifelheim> <44ABB1DE.5000503@redhat.com> <1152133941.16510.5.camel@to-rhaps3.toronto.redhat.com> Message-ID: <44AC3131.8010109@redhat.com> Looks like some great work. Some suggestions: First, might be a good idea to host the images on sourceware.org rather than send them to the list Titles: Not so much the memory window - but we need a consistent story with all our window titles. Should it be Frysk: ? Nitpicks: Left Align: "Current Program Counter" with the TreeView. The alignments with "Examine memory location", "From" and "To" look odd and jar the (well my) eye. Not sure what the solution is here. The minus sign offsetting the decimal column in some cells looks a little odd too. Again not sure what the solution is here. Spacing: Add more vertical spacing between the top and bottoms text-boxs and treeview (I think either 12 or 18 - look in the HIG for guides there). Spacing between labels and text-boxes is a little inconsistent. Is the ordering of the columns dependent on how they are added? (IE if I add Hex first, then Binary is that order reflected in the UI?). Can I drag and drop the columns? (Personally I find binary representation least useful, and hex most; but other people will differ ;) Coming together pretty well! Regards Phil Mike Cvet wrote: > On Wed, 2006-07-05 at 07:34 -0500, Rick Moseley wrote: > >> That looks nice Mike! Good work there. >> >> I was thinking there needs to be some way to easily determine in what >> format the data is being displayed and make it pretty easy to change >> formats, preferably, IMHO, from the main screen. Maybe there could be >> tabs with a view showing each format(dec, hex, oct, etc.). Maybe these >> tabs could be "tear-away" where a user could look at 2 or more formats >> simultaneously? >> >> Just my 2??. >> >> Rick >> >> >> Mike Cvet wrote: >> >>> Hey all, >>> >>> Currently I'm working on implementing the memory window. If any of you >>> have ever used the 'examine memory' data tool from ddd, this is similar >>> to the functionality I would like to have. >>> >>> As of last week, the window displayed all 32 bit words in binary, octal, >>> decimal and hex from the current program counter to a predetermined >>> memory location. >>> >>> As of today, I am working on supporting endian-ness and reading >>> information from memory in 4, 8, 16, 32, and 64 bit chunks. >>> >>> As you can see in the screenshot, the "from" spinbox determines where >>> the words should begin to be read from (will default to the PC) and "to" >>> is where the reading ends. "edit columns" displays options for the >>> number of bits, endian-ness, and radix. >>> >>> Let me know if there are any suggestions, on the interface or otherwise. >>> >>> Mike >>> >>> >>> ------------------------------------------------------------------------ >>> >>> > > Rick, > > Good ideas! > > I've attached a screenshot with some further work. This was just > committed this evening and so is partially functional. Still having some > problems with memory reads though. > > There are options to select endian-ness, number of bits, and radix, as > suggested. > > In a little while I'll work on getting the SpinButtons to increment in > multiple radii as well, and maybe implement some tabs. I know that the > alignment/organization of the window is off, so let me know what the > best arrangement might look like. I'm not very good with Glade yet. > > Mike > > > ------------------------------------------------------------------------ > From mark@klomp.org Thu Jul 6 09:18:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 06 Jul 2006 09:18:00 -0000 Subject: Build Breakage In-Reply-To: References: <449D61E4.3010506@redhat.com> <44A13B36.9070503@redhat.com> Message-ID: <1152177489.2536.10.camel@elsschot.wildebeest.org> On Wed, 2006-06-28 at 17:34 +0800, Wu Zhou wrote: > > Yes, I agree, and there is. It's really simple: frysk always builds; frysk's > > testsuite always passes. > > I totally agree to the first one: frysk has to always build. But in my > opinion, the testcases exist to find bug. To expose new problem is the > value of the testcase, right? So I hold the point that we can let these > failing tests enabled. We would like to see all frysk's testsuite pass. > But if there are anything failing, why not just let them open. This is a > sign that there are some problem for us to resolve. A 100 percent pass > rate might obscure our eyes. What do you think? We do have XFAIL and <>PASS. These are not really failures, but indicate that either it is a known bug if it is a XFAIL, or that the testcase is written badly (or cannot currently be written correctly), if it is a <>PASS. These two make sure that make check "passes". That way we have it both ways. Make check passes and we have an overview of things that still need to be fixed. > The second concern I have is on the execution of the presribed policy. I > am thinking that if we can test at least on two platforms before we > check in the code, that will be great. Yes indeed. But not everybody has access to multiple platforms. It would probably be good if people could setup some kind of autobuilder for the platforms they care for. Then we would have an overview of what works on what platform over time. Mozilla has a nice tool for this Tinderbox. But I don't know how hard it is to setup. http://www.mozilla.org/projects/tinderbox/ There is also http://buildbot.sourceforge.net/ which seems popular with the gnome hackers. Cheers, Mark From mark@klomp.org Thu Jul 6 11:18:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 06 Jul 2006 11:18:00 -0000 Subject: Small patchlet for Makefile.gen.sh Message-ID: <1152184694.2536.26.camel@elsschot.wildebeest.org> Hi, Makefile.gen.sh depends on the output of grep to include the filename. If you only have one .cxx file in your cni directory it doesn't correctly parse the include statements. This patch fixes that by adding -H to the grep invocation to force it to output the filename. 2006-07-06 Mark Wielaard * Makefile.gen.sh: Add -H to grep invocation. Committed to frysk-core/common. Through the magic of cvs modules this should show up in all Makefile.gen.sh in the tree. Cheers, Mark --- frysk-core/common/Makefile.gen.sh 12 May 2006 17:07:13 -0000 1.105 +++ frysk-core/common/Makefile.gen.sh 6 Jul 2006 11:13:16 -0000 @@ -411,7 +411,7 @@ do find $d -name "[A-Za-z]*.cxx" -print done \ - | xargs grep '#include ".*.h"' \ + | xargs grep -H '#include ".*.h"' \ | sed -e 's/\.cxx:#include "/.o /' -e 's/\.h".*$//' -e 's/$.*//' \ | while read o h do From woodzltc@linux.ibm.com Fri Jul 7 02:33:00 2006 From: woodzltc@linux.ibm.com (woodzltc@linux.ibm.com) Date: Fri, 07 Jul 2006 02:33:00 -0000 Subject: Build Breakage Message-ID: <20060706223306.tfa38sn5dwkk8o0g@imap.linux.ibm.com> On Thu, 6 Jul 2006, Mark Wielaard wrote: > On Wed, 2006-06-28 at 17:34 +0800, Wu Zhou wrote: > > > Yes, I agree, and there is. It's really simple: frysk always > builds; frysk's > > > testsuite always passes. > > > > I totally agree to the first one: frysk has to always build. But in my > > opinion, the testcases exist to find bug. To expose new problem is the > > value of the testcase, right? So I hold the point that we can let these > > failing tests enabled. We would like to see all frysk's testsuite pass. > > But if there are anything failing, why not just let them open. This is a > > sign that there are some problem for us to resolve. A 100 percent pass > > rate might obscure our eyes. What do you think? > > We do have XFAIL and <>PASS. These are not really failures, but > indicate that either it is a known bug if it is a XFAIL, or that the > testcase is written badly (or cannot currently be written correctly), if > it is a <>PASS. These two make sure that make check "passes". > That way we have it both ways. Make check passes and we have an overview > of things that still need to be fixed. XFAIL and <>PASS is good for tracking problems. If it is very important for "make check" to pass, this policy is ok with me. > > > The second concern I have is on the execution of the presribed policy. I > > am thinking that if we can test at least on two platforms before we > > check in the code, that will be great. > > Yes indeed. But not everybody has access to multiple platforms. It would > probably be good if people could setup some kind of autobuilder for the > platforms they care for. Then we would have an overview of what works on > what platform over time. I had some script to do similar job. But on PPC64, I need to resolve quite some 64-bit libraries dependence issues to make it build ok. This make it somewhat hard to build completely automatically on ppc64. I am also interested in x86 and x86-64 platforms, though ppc64 is what interested most. :-) now I can run these test automatically on x86. But I only have remote access to x86-64 machine, and it can't be dedicated to frysk usage. Anyway, I can put the test results on x86 first. Will do a while later. > Mozilla has a nice tool for this Tinderbox. But I don't know how hard it > is to setup. http://www.mozilla.org/projects/tinderbox/ > There is also http://buildbot.sourceforge.net/ which seems popular with > the gnome hackers. I can have some looks into these two tools to see if they are proper for our usage. If any of you have any experience in them, feel free to help me. :-) Regards - Wu Zhou From woodzltc@cn.ibm.com Fri Jul 7 05:07:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 07 Jul 2006 05:07:00 -0000 Subject: Build and test results on x86:2006-07-06 Message-ID: <20060707010705.6zux603u8s8sck0w@imap.linux.ibm.com> Hello all, Attached is the build and test result on x86. There is one FAIL in run-arsymtest.sh, 12 XFAIL in frysk-imports tests. XFAIL: frysk2491/Nest XFAIL: frysk2270/SameName XFAIL: frysk2270/WrongVariable XFAIL: frysk2270/WrongScope.gcj XFAIL: frysk2492/java.sh XFAIL: frysk1840/gcj.sh XFAIL: frysk2595/ptrace_peek_wrong_thread XFAIL: frysk2595/ptrace_before_forked_thread_exits XFAIL: frysk2670/gcj.sh XFAIL: frysk2630/noerror.sh XFAIL: frysk2631/ice.sh XFAIL: frysk2760/barriertest And one test skipped: SKIP: frysk2595/ptrace_after_forked_thread_exits Please refer to the attached file for details. Regards - Wu Zhou -------------- next part -------------- A non-text attachment was scrubbed... Name: make-check.log Type: text/x-log Size: 8403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imports-check.log Type: text/x-log Size: 22542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gtk-check.log Type: text/x-log Size: 3048 bytes Desc: not available URL: From npremji@redhat.com Fri Jul 7 15:24:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Fri, 07 Jul 2006 15:24:00 -0000 Subject: Eventviewer Vertical Message-ID: <1152285889.2468.9.camel@to-rhaps5.toronto.redhat.com> Here is a screen shot of what the frysk eventviewer could look like if it was vertical. (I also tried showing what tasks being dotted before they existed would look like) -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Frysk.jpg Type: image/jpeg Size: 76251 bytes Desc: not available URL: From cagney@redhat.com Fri Jul 7 17:29:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 07 Jul 2006 17:29:00 -0000 Subject: Eventviewer Vertical In-Reply-To: <1152285889.2468.9.camel@to-rhaps5.toronto.redhat.com> References: <1152285889.2468.9.camel@to-rhaps5.toronto.redhat.com> Message-ID: <44AE9A02.6030008@redhat.com> Nurdin Premji wrote: > Here is a screen shot of what the frysk eventviewer could look like if > it was vertical. (I also tried showing what tasks being dotted before > they existed would look like) > Yes, I actually prefer vertical. My only thought is to move the index or key to either the top or bottom, and perhaps have a way of shrinking it out-of-view. That way there's even more real-estate. Andrew From cmoller@redhat.com Fri Jul 7 18:29:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Fri, 07 Jul 2006 18:29:00 -0000 Subject: Eventviewer Vertical In-Reply-To: <44AE9A02.6030008@redhat.com> References: <1152285889.2468.9.camel@to-rhaps5.toronto.redhat.com> <44AE9A02.6030008@redhat.com> Message-ID: <44AEA7C1.2030700@redhat.com> The latest version--not up yet--has the legend in its own drawing area above the chart. It's not in the scrolled window, so it's always visible, but it could also be on a button that makes it go away entirely when it's not needed. Andrew Cagney mumbled something on 07/07/2006 01:29 PM: > Nurdin Premji wrote: >> Here is a screen shot of what the frysk eventviewer could look like if >> it was vertical. (I also tried showing what tasks being dotted before >> they existed would look like) >> > Yes, I actually prefer vertical. My only thought is to move the index > or key to either the top or bottom, and perhaps have a way of > shrinking it out-of-view. That way there's even more real-estate. > > Andrew > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From npremji@redhat.com Fri Jul 7 19:31:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Fri, 07 Jul 2006 19:31:00 -0000 Subject: Breakpoint meeting Message-ID: <1152300690.2468.42.camel@to-rhaps5.toronto.redhat.com> So we had a meeting about the current and future state of breakpoints in frysk. Here is a rough outline of what we talked about. We plan to have about 2 levels of breakpoints: High Level and Low level. (I believe 2-3 where the exact words used but I can't see a third) High Level Issues: Usually the user looks at the source code and adds breakpoints, then starts debugging. Tagsets are these predefined breakpoints. The high level breakpoints are from the user/source code side of things where a user can put a break point on a function or line or such. The issue we have in frysk is that these breakpoints must be projected down to the currently running processes and libraries and new running processes and libraries. Frysk must look at every process and library and check if these break points apply. The reason for this is because we really don't know which processes and libraries are going to use that code before hand. For example putting a break point on printf. We have to prepare for the worst case and for us the worst case is that we know nothing (about the source code and libraries that are going to be used) We have to be able to handle inline functions, and inheritance and all that object oriented, event driven fun stuff. Linking Between high and low: So high level user breakpoints should accumulate low level address breakpoints. If we implement the low level breakpoints, high level breakpoints will follow. We can implement a 2 level breakpoint table. The relationship between high level breakpoints to low level breakpoints is many to many (n to n). That is, a high level breakpoint can have can have many low level address breakpoints. And a low level breakpoint can be associated with many high level breakpoints. Low Level Issues: Low level breakpoints should keep addresses per process (since tasks can share breakpoints) Side note: When a process gets a trap signal, only the triggered thread is stopped. Thread Hop: When we have a breakpoint, the natural thing to do is have the thread run until it hits that breakpoint, stop, and then continue and retain the thread. The obvious way to do this is to (on a breakpoint): stop the thread, remove the breakpoint, single step the thread, add the breakpoint back, and then continue. However other threads (in a multi-threaded environment) could miss the breakpoint when we (temporarily) remove that breakpoint. So the first possible solution is to: stop all threads, remove bp single step the single thread, add the bp back, and then continue all threads. This adds a lot of overhead because stopping all the threads and restarting them takes some time. In frysk we want to try to keep things running as long as possible, which brings up the second possible solution. Second method involves kprobes. When we insert the breakpoint, we know the instruction it is replacing. So we copy the entire instruction, put it somewhere else* in the running process Set the thread pc to point to this copy, single step execute, put pc back to where it should be after the instruction, and continue. somewhere else*: Possible candidates: 1. the process stack. However there may be security issues. 2. the starting point address (however only one thread can use this at any time so we need locking) The next issue with the low level threads is a 386 complexity decraPCAfterBreak: For every architecture (other than 386) the instruction address is the address of the breakpoint. For 386 the instruction address is the address AFTER the breakpoint, thus we have to backtrack. So look at the instruction you are on -1, determine if that is a breakpoint and react accordingly. Also we have to ignore system calls because we can't do system call tracing and single stepping at the same time. This is apparently a kernel bug. From woodzltc@cn.ibm.com Sat Jul 8 17:12:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sat, 08 Jul 2006 17:12:00 -0000 Subject: Build and test results on x86:2006-07-08 Message-ID: <20060708131236.r37aex9og0cowcc0@imap.linux.ibm.com> The build and test results today is the same as last time. There are still a FAIL when running "make check", it is at run-arsymtest.sh, which is part of elfutils testsuite. I made some analysis, and found that the reason is that I am running the test in chinese local environment. then "/^Arch/" will match nothing, and sed -e '1,/^Arch/d' will delete all the lines "nm -s ../libelf/libelf.a" outputs. So I have a questoin here: will we take international local building environment into consideration, no matter we are running test or frysk itself? From woodzltc@cn.ibm.com Sat Jul 8 17:35:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sat, 08 Jul 2006 17:35:00 -0000 Subject: Breakpoint meeting In-Reply-To: <1152300690.2468.42.camel@to-rhaps5.toronto.redhat.com> References: <1152300690.2468.42.camel@to-rhaps5.toronto.redhat.com> Message-ID: <20060708133548.a08w9ewioggggoc0@imap.linux.ibm.com> Quoting Nurdin Premji : > Second method involves kprobes. > > When we insert the breakpoint, we know the instruction it is replacing. > So we copy the entire instruction, put it somewhere else* in the running > process > Set the thread pc to point to this copy, > single step execute, > put pc back to where it should be after the instruction, > and continue. Do you mean you will use kprobe to replace the instruction at the breakpoint address? As far as I know, kprobe is used in kernel space. Maybe you meand something similar in kprobe in user space. I know that there are some user-space probe proposal there, but I am not sure if they are mature enough for our usage. If you could elaborate a little on this method, that will be highly appreciated. > Also we have to ignore system calls because we can't do system call > tracing and single stepping at the same time. This is apparently a > kernel bug. I guess the utrace mechanism Roland McGrath proposed can resolve this. If it is, maybe we can re-conisder this, at least at desigh phase. My two cents anyway. Regards - Wu Zhou From woodzltc@cn.ibm.com Sat Jul 8 17:37:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sat, 08 Jul 2006 17:37:00 -0000 Subject: Fwd: Re: Eventviewer Vertical Message-ID: <20060708133734.oe5ascpr28c4g4gg@imap.linux.ibm.com> Sorry, forget to include frysk@ in the cc list. ------- Quoting Chris Moller : > The latest version--not up yet--has the legend in its own drawing area > above the chart. It's not in the scrolled window, so it's always > visible, but it could also be on a button that makes it go away entirely > when it's not needed. I like what is seen in the latest code: having the legend in its own drawing area and on the top, having the eventviewer horizontal. :-) BTW, I can hardly see anything in eventviewer with the interval setting default to 10. I had to modify that to a much larger number to see the effect. What is your situatoin there? Do we need to modify that default value to a larger one? > > Andrew Cagney mumbled something on 07/07/2006 01:29 PM: >> Nurdin Premji wrote: >>> Here is a screen shot of what the frysk eventviewer could look like if >>> it was vertical. (I also tried showing what tasks being dotted before >>> they existed would look like) >>> >> Yes, I actually prefer vertical. My only thought is to move the index >> or key to either the top or bottom, and perhaps have a way of >> shrinking it out-of-view. That way there's even more real-estate. >> >> Andrew >> >> > Regards - Wu Zhou ----- End forwarded message ----- Regards - Wu Zhou From woodzltc@cn.ibm.com Sat Jul 8 18:11:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sat, 08 Jul 2006 18:11:00 -0000 Subject: About libunwind and dogtail Message-ID: <20060708141112.i9oi6uv1w8scgg40@imap.linux.ibm.com> Hello Andrew and all, We talked about libunwind and dogtail for ppc64 before. I am recently taking some look into these two. I would like to post my current understanding here for your review. If there are anything wrong or missing, please point out and correct me. Thanks a lot! For dogtail, it is writen in python, based on accessibility technology. It will use at-spi to communicate with the AT-supporting GNOME (or other GUI) application. From the point of theory/design, all of them are platform independent. But from the point of practice, all these package (GNOME, at-spi, pyspi, dogtail) are receving much less attention on ppc64 than on x86. So our point is that we need to test them on ppc64 and try to find how it works on this platform. We will aslo work with upstream package maintainers to fix exposed defects. Is my understanding right? About libunwind, there are some platform dependent feature. My understanding is that it initiated from ia64 platform and are now being ported to x86 platform. On ia64, it support local unwind, remote unwind (I guess this is what interests frysk most, right?), ptrace stop and resume, get proc/register information... In my opinion, quite some of these features are platform dependent. Do we need to port all these functionality to other platforms (x86, ppc64 or x86-64)? I run a make check on x86 platform, it reported 13 of 24 tests failed. There are some segmentation fault and also some failure of unw_step. So I guess libunwind is not very mature on x86 yet and not all features are ported to x86 too. My opinion is that we need only port what is needed by frysk first. So I have a quesiton here: in what way is libunwind expected to be used in frysk? I guess it surely includes different process unwind on the same machine. But will it includes remote process unwind on a different machine/target? Getting the answer for these is very helpful for us to focus on high-priority work item. Regards - Wu Zhou From cagney@redhat.com Sun Jul 9 03:18:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sun, 09 Jul 2006 03:18:00 -0000 Subject: Breakpoint meeting In-Reply-To: <20060708133548.a08w9ewioggggoc0@imap.linux.ibm.com> References: <1152300690.2468.42.camel@to-rhaps5.toronto.redhat.com> <20060708133548.a08w9ewioggggoc0@imap.linux.ibm.com> Message-ID: <44B0759D.4080002@redhat.com> First thanks to Nurden for making these notes. Wu Zhou wrote: > Quoting Nurdin Premji : > > >> Second method involves kprobes. >> >> When we insert the breakpoint, we know the instruction it is replacing. >> So we copy the entire instruction, put it somewhere else* in the running >> process >> Set the thread pc to point to this copy, >> single step execute, >> put pc back to where it should be after the instruction, >> and continue. > > Do you mean you will use kprobe to replace the instruction at the > breakpoint address? As far as I know, kprobe is used in kernel space. > Maybe you meand something similar in kprobe in user space. I know that > there are some user-space probe proposal there, but I am not sure if > they are mature enough for our usage. > > If you could elaborate a little on this method, that will be highly > appreciated. No, the intent is to borrow the underlying technique used by kprobes, not actually use kprobes :-) However, long term if the kernel were to grow a better low-level mechanism we'd be all over it! > >> Also we have to ignore system calls because we can't do system call >> tracing and single stepping at the same time. This is apparently a >> kernel bug. > > I guess the utrace mechanism Roland McGrath proposed can resolve this. > If it is, maybe we can re-conisder this, at least at desigh phase. My > two cents anyway. The above is an implementation, rather than design, decision. We can investigate the possability of working around the bug later (like we did for the bug where ptrace only works from one thread). Yes, we're expecting utrace to address this sort of problem. Andrew From cagney@redhat.com Sun Jul 9 03:29:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sun, 09 Jul 2006 03:29:00 -0000 Subject: proposed refactoring of LinuxIA32 In-Reply-To: <44ABFBDD.9040709@redhat.com> References: <44ABFBDD.9040709@redhat.com> Message-ID: <44B0785E.80608@redhat.com> Tim Moore wrote: > Hi, > I've started looking at supporting x86_64 in frysk. To that end I > propose refactoring Isa, LinuxIA32 and friends. I've turned Isa into > an interface implemented by IsaIA32 and IsaEMT64. There's also a new > interface, SyscallEventDecoder, that just returns a SyscallEventInfo > object. Then e.g., LinuxIA32 extends IsaIA32 and implements > SyscallEventDecoder. Comments welcome on this code... > Tim, this all reads right (I even sketched a bit of it out). Making SyscallEventDecoder is a nice way of separating out sub-components - I think it sets a trend that can be followed as other ISA related coponents get added. One suggestion, going forward, I think the only thing really of interest is the objects and their relationships - if looking for comment you could just post a simple sketch of how things should be. I think if that is determined, the code just drops into place. sorry to not comment earlier, Andrew From qiyaoltc@cn.ibm.com Mon Jul 10 02:20:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 10 Jul 2006 02:20:00 -0000 Subject: proposed refactoring of LinuxIA32 In-Reply-To: <44ABFBDD.9040709@redhat.com> References: <44ABFBDD.9040709@redhat.com> Message-ID: <20060710021146.GA8385@GreenHouse.cn.ibm.com> On Wed, Jul 05, 2006 at 07:50:21PM +0200, Tim Moore wrote: > Hi, > I've started looking at supporting x86_64 in frysk. To that end I > propose refactoring Isa, LinuxIA32 and friends. I've turned Isa into an > interface implemented by IsaIA32 and IsaEMT64. There's also a new > interface, SyscallEventDecoder, that just returns a SyscallEventInfo > object. Then e.g., LinuxIA32 extends IsaIA32 and implements > SyscallEventDecoder. Comments welcome on this code... > > Tim Hi, Tim, Sorry for delayed reply! The code looks good to me, and there is two points I want discuss with here. 1) In your code, you refactor Isa as an interface, and IsaIA32, IsaEMT64 implement it, Isa could not be instantiated, but instance of Isa is needed in Task and LinuxTask, so it is better to refactor Isa as an super class, and IsaIA32, IsaEMT64 inherit it. Task and LinuxTask could get registers, byte orders via isa without concerning what exactly isa is. 2) Assuming IsaIA32, IsaEMT64 work OK, the next problem is which class among the set of subclasses(IsaIA32, IsaEMT64, etc.) of the parent class(Isa) is to be selected, and what is the criteria to select. IMO, it is reasonable and flexible to read ELF headers of /proc//exe as the criteria to select sub class, and I coded a Class named IsaFactory, get e_machine from ELF header as the criteria. Some other discussions about this issues could be found http://sourceware.org/bugzilla/show_bug.cgi?id=2458 Any comments are welcome! -- Yao Qi From mark@klomp.org Mon Jul 10 09:17:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 10 Jul 2006 09:17:00 -0000 Subject: frysk-gtk tlwidgets/Makefile.am tlwidgets/Chan ... In-Reply-To: <20060706194311.26372.qmail@sourceware.org> References: <20060706194311.26372.qmail@sourceware.org> Message-ID: <1152523049.2673.10.camel@elsschot.wildebeest.org> Hi Nurdin, On Thu, 2006-07-06 at 19:43 +0000, npremji@sourceware.org wrote: > * src/java/com/redhat/ftk/SimultaneousEvent.java: Added. > * Makefile.am: Added in SimultaneousEvent.java and modified classpath of > Eventviewer to see this class. > * src/jni/com_redhat_ftk_EventViewer.c: Added support for set_*_color methods. > Changed ints to gints. Uncommented resize support, now implemented. > Added support for ties and Simultaneous Events. > * src/widgets/ftkeventviewer.c: Added a comment to show where code to create > new marker starts. This broke builddir != srcdir builds. Fixed as follows: 2006-07-10 Mark Wielaard * Makefile.am (EventViewer.o): Add $(srcdir) to include path. (SimultaneousEvent.o): Likewise. Committed, Mark diff -u -r1.13 Makefile.am --- frysk-gtk/tlwidgets/Makefile.am 6 Jul 2006 19:43:10 -0000 1.13 +++ frysk-gtk/tlwidgets/Makefile.am 10 Jul 2006 09:11:31 -0000 @@ -111,11 +111,11 @@ # -g -O2 -fPIC -c $< -o $@ EventViewer.o: $(tlwidgetssrc)/java/com/redhat/ftk/EventViewer.java SimultaneousEvent.o - $(GCJ) -fjni -classpath $(FRYSK_GTK_CLASSPATH) -I ./src/java -I ./ \ + $(GCJ) -fjni -classpath $(FRYSK_GTK_CLASSPATH) -I $(srcdir)/src/java -I ./ \ -g -O2 -fPIC -c $< -o $@ SimultaneousEvent.o: $(tlwidgetssrc)/java/com/redhat/ftk/SimultaneousEvent.java- $(GCJ) -fjni -classpath $(FRYSK_GTK_CLASSPATH) -I ./src/java \ + $(GCJ) -fjni -classpath $(FRYSK_GTK_CLASSPATH) -I $(srcdir)/src/java \ -g -O2 -fPIC -c $< -o $@ #libftkjava.so: Stripchart.o StripchartX.o EventViewer.o SimultaneousEvent.o From rmoseley@redhat.com Mon Jul 10 14:04:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Mon, 10 Jul 2006 14:04:00 -0000 Subject: About libunwind and dogtail In-Reply-To: <20060708141112.i9oi6uv1w8scgg40@imap.linux.ibm.com> References: <20060708141112.i9oi6uv1w8scgg40@imap.linux.ibm.com> Message-ID: <44B25E54.2000806@redhat.com> Wu Zhou wrote: > Hello Andrew and all, > > We talked about libunwind and dogtail for ppc64 before. I am recently > taking some look into these two. I would like to post my current > understanding here for your review. If there are anything wrong or > missing, please point out and correct me. Thanks a lot! > > For dogtail, it is writen in python, based on accessibility > technology. It will use at-spi to communicate with the AT-supporting > GNOME (or other GUI) application. From the point of theory/design, all > of them are platform independent. But from the point of practice, all > these package (GNOME, at-spi, pyspi, dogtail) are receving much less > attention on ppc64 than on x86. So our point is that we need to test > them on ppc64 and try to find how it works on this platform. We will > aslo work with upstream package maintainers to fix exposed defects. Is > my understanding right? > > About libunwind, there are some platform dependent feature. My > understanding is that it initiated from ia64 platform and are now > being ported to x86 platform. On ia64, it support local unwind, remote > unwind (I guess this is what interests frysk most, right?), ptrace > stop and resume, get proc/register information... In my opinion, quite > some of these features are platform dependent. Do we need to port all > these functionality to other platforms (x86, ppc64 or x86-64)? I run a > make check on x86 platform, it reported 13 of 24 tests failed. There > are some segmentation fault and also some failure of unw_step. So I > guess libunwind is not very mature on x86 yet and not all features are > ported to x86 too. My opinion is that we need only port what is needed > by frysk first. So I have a quesiton here: in what way is libunwind > expected to be used in frysk? I guess it surely includes different > process unwind on the same machine. But will it includes remote > process unwind on a different machine/target? Getting the answer for > these is very helpful for us to focus on high-priority work item. Yes, your information is correct about libunwind originating on the ia64 platform as HP engineers are doing the development there. According to the README, the x86_64 "Works well." and the x86 status is "Works well, but C library is missing some unwind-info." Also, according the README several tests on x86 are expected to fail: ** Expected results on x86 Linux The following tests are expected to fail on x86 Linux: Gtest-bt (see http://sources.redhat.com/bugzilla/show_bug.cgi?id=595) Ltest-bt (likewise) Gtest-resume-sig (likewise) Ltest-resume-sig (likewise) Gtest-dyn1 (no dynamic unwind info support yet) Ltest-dyn1 (no dynamic unwind info support yet) test-setjmp (longjmp() not implemented yet) run-check-namespace (no _Ux86_getcontext yet) So, indeed, x86 tests are expected to fail and according to the README, a lot of the same ones fail for x86_64. The first major feature we are trying to implement for Frysk using libunwind will be to get backtraces, so, if you want some focus on where to place development resources, that is the initial area we will be concentrating on. Remote debugging is definitely in our plans, but is not our immediate goal. We want to get local debugging solid before moving on to remote deugging. Any changes you make should be flexible enough to be able to handle remote debugging in the future. Hope this helps. Rick > > Regards > - Wu Zhou From rmoseley@redhat.com Mon Jul 10 19:13:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Mon, 10 Jul 2006 19:13:00 -0000 Subject: libunwind problems Message-ID: <44B2A6C1.2050700@redhat.com> Hi all, Andrew Haley tracked down our problem with linking against the libunwind library. Below is his explanation of what he found and how it can be resolved. Thanks to Andrew Haley for his valuable time. Rick The problem is that you have linked frysk in such a way that it uses part of libunwindand part of libgcc for exception handling . So, symbol resolution in FryskGui goes like this: 4411: binding file /lib/libc.so.6 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_Find_FDE' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /usr/lib/libgcj.so.7 [0]: normal symbol `_ZN14_Jv_StackTrace13UnwindTraceFnEP15_Unwind_ContextPv' 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_Backtrace' [GCC_3.3] 4411: binding file /lib/libgcc_s.so.1 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_Find_FDE' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetRegionStart' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetIP' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_RaiseException' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetLanguageSpecificData' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetIPInfo' [GCC_4.2.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_SetGR' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to /lib/libgcc_s.so.1 [0]: normal symbol `_Unwind_SetIP' [GCC_3.0] 4411: binding file /usr/lib/libgcj.so.7 [0] to ./frysk-gui/frysk/gui/FryskGui [0]: normal symbol `_Unwind_Resume' [GCC_3.0] Note that all of libgcj's exception handling is linked to libgcc_s.so.1 except for `_Unwind_Resume', which is linked to the libunwind version of that symbol that is built into FryskGui. As far as I can see this can never work, because the context structure used in `_Unwind_RaiseException' and `_Unwind_Resume' must be the same, and they must be satisfied from the same library. FryskGui exports just _one_ libunwind function, and as soon as it gets called the program crashes. -bash-3.1$ nm ./frysk-gui/frysk/gui/FryskGui | grep _Unwind_ 083af4e0 T __libunwind_Unwind_Resume 083af4e0 T _Unwind_Resume So, the way to fix frysk is to make sure that libgcc_s.so is in the link path before libunwind. This causes the libunwind version of _Unwind_Resume not to be put into FryskGui. I linked FryskGui like this: ... mports/elfutils/libdw/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imports/elfutils/libdwfl/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imports/elfutils/libebl/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imp\orts/elfutils/libelf/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-imports/libunwind/src/:/home/aph/frysk-libunwind/build/frysk-gui/../frysk-sys/:./elfutils/libdw \ -Dgnu.gcj.runtime.NameFinder.demangle=false \ -Dgnu.gcj.runtime.NameFinder.use_addr2line=false \ -lgcc_s \ frysk/gui/FryskGui.o \ libfrysk-gui.a \ ../frysk-gtk/libfrysk-gtk.a ... This problem is really due to mixing dynamic and static libraries. I imagine -- but I haven't tried -- that if you used a dynamically linked version of libunwind it would be OK. Andrew. P.S. gcj on trunk doesn't call `_Unwind_Resume' at all; this is a 4.1 issue. From ajocksch@redhat.com Tue Jul 11 19:58:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Tue, 11 Jul 2006 19:58:00 -0000 Subject: libunwind Message-ID: <44B4013D.3030206@redhat.com> k, now that libunwind has been (in somewhat stable condition) integrated into the frysk build, I have committed the first part of the binding that will allow frysk to use the library for stack back traces. In order to function, libunwind must be passed callbacks to access data from the process it is unwinding. In a normal C program this looks as such (assuming ptrace is used): Libunwind ---> User provided Callbaks ---> PTrace Now with the partial java wrapper I have committed, the interface to libunwind within frysk will look as follows: libunwind ---> Callbacks Provided by Java Wrapper ---> Common Java API ---> XXX Where 'XXX' is the code that will extract the information that libunwind needs from the current task using ptrace. The question is where should this code be located? My instinct tells me that it should be somewhere in frysk-core, since there will be interation with the Task/Isa objects. Are there any other thoughts on this issue? Adam From roland@redhat.com Tue Jul 11 21:23:00 2006 From: roland@redhat.com (Roland McGrath) Date: Tue, 11 Jul 2006 21:23:00 -0000 Subject: libunwind In-Reply-To: Adam Jocksch's message of Tuesday, 11 July 2006 15:51:25 -0400 <44B4013D.3030206@redhat.com> Message-ID: <20060711212327.83F97180061@magilla.sf.frob.com> It needs two kinds of things. One is access to the active thread/process state, which is to say registers and memory. That goes to the frysk core that is what's calling into libunwind. The other is access to the unwind info from the ELF files. This is data in whole ELF sections (.debug_frame, .eh_frame) that nothing but the unwinder needs to think about. The raw section contents are easily gotten from libdwfl+libelf calls starting from the Dwfl object for an address space. The libunwind callbacks are especially poorly structured so that you need to wade into a bunch of weirdness to have your callbacks use some libunwind code that does part of the DWARF parsing, instead of simply supplying libunwind with the raw sections it needs. From ezannoni@redhat.com Tue Jul 11 21:26:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Tue, 11 Jul 2006 21:26:00 -0000 Subject: Frysk weekly meeting minutes 20060711 Message-ID: <17588.5906.312175.636846@localhost.redhat.com> Guadec report: attendance was good. Fair number of people in the talk. Done demo but not slides, because only 5 minutes session. syscall tracing work: wrote ftrace application. Chokes on syscalls need to find better way to figure out which syscall are legal. Is there a database somwhere? Seems like there isn't. Kernel audit system probably has something like that. Sami to find out. Libunwind build/linking problem with gcj: Rick/Andrew: two identically named symbols in 2 different libraries, libunwind and libgcj. libunwind.so or libunwind-.so? Maybe try to use the target one instead of the generic one. There are different ways to build it. Workaround is there, but doesn't solve the symbol clash. This is fixed in gcc-4.2, but that's irrelevant to us for now. Only way is to not build that stuff in. Fix: workaround is in. Proper fix seems to be simple makefile change. Needs to be in by tomorrow. Rick. Libunwind status: Adam: checked out the lower half of the bindings. Callbacks need to be pointed at ptrace. Enabler for raw addresses backtraces. Multiple invocations of frysk: Mike: problem on amd64. Still being worked on. right now it cannot bring up the window of the currently running frysk on amd64. Can we get this fixed by tomorrow on x64-64. Frysk on Frysk: cannot debug same instance of frysk (obviously) but should be able to debug another instance of frysk. We need to enable that. There is a bug about frysk debugging itself (same pid): ignore that bug, we don't want to do that. Please close that bug. Phil needs to cleanup the process list though, we don't want to have Frysk listed or can we grey it out so that it cannot be selected? Try to get this done by tomorrow. Event viewer: Nurdin: accessibility: being added but having trouble finding a testing program. Using sniff from dogtail, but it seems to get itself into a locked state. Talk to Len. utrace: Chris fulltime on it. Writing tests for utrace. back burner item: investigate why the different platforms of java-gnome behave differently. register window: nothing to do for now. Tim had a few 32/64 bits bugs. End of day tomorrow for amd64. memory window: should work on 64-bit. Tim checked something in. (I didn't catch the details sorry). Mostly a port of the register window, including bugs :-) 64-bit: Tim: source comes up fine, reg window (working through that now) memory window not yet. Need to run through the tests. breakpoints: in progress, tasks are understood. no showstoppers. console/terminal workflow: people are goin to discuss this offline. process list window problems: - will show also defunct processes, because they are caught in between states. Len filed a bug. - "cannot find name": on Phil's buglist. Same as defunct process problem: cannot get a name of executable. - frysk listed twice: Filter it out - define sorting: need to sort them alphabetically. Phil says they should all be done by tomorrow. Yea! gcov: on its way. Results should be available next week. Stan has this on backburner. dogtail on ppc64: Len will give it a spin tomorrow just to see is it works at all. IBM will do more serious testing. From ipantuye@redhat.com Tue Jul 11 21:33:00 2006 From: ipantuye@redhat.com (Ivan Pantuyev) Date: Tue, 11 Jul 2006 21:33:00 -0000 Subject: console workflow meeting results Message-ID: <44B4187E.60802@redhat.com> So it was Sami, Andrew, Phil and me talking on the phone for over 1.5 hours, and here's what we came up with (correct/add if I screw up): The console (the HPD command line interface) should be working with the same processes and threads as the frysk monitor window. In terms of workflow that would require an extra tab in the monitor window which would contain the console. The engine is designed to allow multiple interface, but in this case the workflow requires synchronization of the two interfaces. Since this is a symbiosis of the two, each has to be aware of some things other one does, such as: * adding breakspoints: the two should have a common breakpoint pool * running/attaching processes, coredumps...: just like with breakpoints each one has to be aware of when the other adds or attaches a process and react accordingly another issue, which is not that important right now (not discussed): * stepping through code (and other things that you can do in source window): synchronization of console and source window? The HPD (the standard console is based on) does not include creation of custom commands (or observers), and extension to do such was discussed, but it's way down the roadmap. From swagiaal@redhat.com Tue Jul 11 21:35:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Tue, 11 Jul 2006 21:35:00 -0000 Subject: ftrace utility Message-ID: <44B4199B.1070509@redhat.com> Hi everyone, After recent work on system calls, i have written ftrace which is a utility with similar functionality to strace using the frysk engine. What it does is start start the requested process though frysk add a systemcall observer to it and starts printing out syscall info. It is a work in progress and atm there are some obvious bugs in it. It does work however, and it is a proof of concept. Please give it a run frysk/frysk-core/prog/util/ftrace From woodzltc@cn.ibm.com Wed Jul 12 01:43:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 12 Jul 2006 01:43:00 -0000 Subject: About dogtail on x86 and ppc64 Message-ID: <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> Hello all, We can setup dogtail on x86 and ppc64 as well. On both platform, we run "python ./gedit-test-utf8-procedural-api.py". Here is the results: On x86: ======== # python ./gedit-test-utf8-procedural-api.py Creating logfile at /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-093635 ... Detecting distribution: Red Hat/Fedora/derived distribution Warning: AT-SPI error: pre method check: add: Unknown CORBA exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' GTK Accessibility Module initialized Warning: AT-SPI error: pre method check: add: Unknown CORBA exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' Bonobo accessibility support initialized Warning: AT-SPI error: pre method check: add: Unknown CORBA exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' Warning: AT-SPI error: pre method check: add: Unknown CORBA exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' Warning: AT-SPI error: pre method check: add: Unknown CORBA exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' /tmp/dogtail/screenshot_20060712-093640.png Screenshot taken: /tmp/dogtail/screenshot_20060712-093640.png click on {child with name="Save" ("??(S)", "??(S)", "??", "??", )} Traceback (most recent call last): File "./gedit-test-utf8-procedural-api.py", line 56, in ? focus.dialog(u'Save As\u2026') File "/usr/lib/python2.4/site-packages/dogtail/procedural.py", line 78, in __call__ result = FocusApplication.node.findChild(predicate, requireResult=False, recursive = False) File "/usr/lib/python2.4/site-packages/dogtail/tree.py", line 769, in findChild result.debugName = pred.describeSearchResult() File "/usr/lib/python2.4/site-packages/dogtail/predicate.py", line 235, in describeSearchResult return '%s dialog'%self.dialogName File "/usr/lib/python2.4/site-packages/dogtail/i18n.py", line 144, in __str__ result = '"%s" (%s)' % (self.untranslatedString, translations) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 8: ordinal not in range(128) On ppc64: ======== # python ./gedit-test-utf8-procedural-api.py Creating logfile at /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-133632 ... Detecting distribution: Red Hat/Fedora/derived distribution /tmp/dogtail/screenshot_20060712-133637.png Screenshot taken: /tmp/dogtail/screenshot_20060712-133637.png click on {child with name="Save"} activate on {child with name="Browse for other folders"} activate on {child with name="Desktop" roleName='table cell'} click on {child with name="Save"} click on {child with name="Quit"} ** (process:26377): WARNING **: Failed to send buffer ** (process:26377): WARNING **: Failed to send buffer ** (process:26377): WARNING **: Failed to send buffer ** (process:26377): WARNING **: Failed to send buffer ....... ** (process:26377): WARNING **: Failed to send buffer The difference I noticed is: 1. There are some warning messages there in ppc64 complaining that failed to send buffer 2. the gedit session quited on ppc64, don't on x86 I guess it work correctly on ppc64, not on x86. 3. on x86, it complained with some warning message: Warning: AT-SPI error: pre method check: add: Unknown CORBA exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' I want to get some suggestion from you, what we need to do to test dogtail seriously? Thanks a lot! Regards - Wu Zhou From roland@redhat.com Wed Jul 12 01:50:00 2006 From: roland@redhat.com (Roland McGrath) Date: Wed, 12 Jul 2006 01:50:00 -0000 Subject: About dogtail on x86 and ppc64 In-Reply-To: Wu Zhou's message of Tuesday, 11 July 2006 21:43:45 -0400 <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> Message-ID: <20060712015034.8B112180061@magilla.sf.frob.com> Please see http://people.redhat.com/zcerza/dogtail/ and get in touch with the dogtail developers directly. They should be able to advise us on what constitutes good testing of dogtail and what the stuff you're seeing means. Thanks, Roland From cagney@redhat.com Wed Jul 12 04:40:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 12 Jul 2006 04:40:00 -0000 Subject: ftrace utility In-Reply-To: <44B4199B.1070509@redhat.com> References: <44B4199B.1070509@redhat.com> Message-ID: <44B47D96.2010201@redhat.com> Sami Wagiaalla wrote: > Hi everyone, > > After recent work on system calls, i have written ftrace which is a > utility > with similar functionality to strace using the frysk engine. What it > does is > start start the requested process though frysk add a systemcall observer > to it and starts printing out syscall info. It is a work in progress > and atm > there are some obvious bugs in it. It does work however, and it is a > proof > of concept. > > Please give it a run > frysk/frysk-core/prog/util/ftrace > > Sami, nice. I'd move the source to frysk-core/frysk/bindir/ftrace{.java,xml}, as then the build system will automatically install it into $(bindir). Andrew From ezannoni@redhat.com Wed Jul 12 13:11:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Wed, 12 Jul 2006 13:11:00 -0000 Subject: About dogtail on x86 and ppc64 In-Reply-To: <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> References: <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> Message-ID: <17588.62608.340741.20235@localhost.redhat.com> Wu, thanks for starting looking at this. Len is using dogtail successfully on x86 for testing of Frysk, so I suspect something in your setup. On ppc64, Len was going to try it today, but since that platform is more of an unknown, I am cc-ing Zack directly as well. But in general I think Len can offer you some pointers on how to set things up. elena Wu Zhou writes: > Hello all, > > We can setup dogtail on x86 and ppc64 as well. > > On both platform, we run "python ./gedit-test-utf8-procedural-api.py". > > Here is the results: > > On x86: > ======== > # python ./gedit-test-utf8-procedural-api.py > Creating logfile at > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-093635 ... > Detecting distribution: Red Hat/Fedora/derived distribution > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > GTK Accessibility Module initialized > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > Bonobo accessibility support initialized > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > /tmp/dogtail/screenshot_20060712-093640.png > Screenshot taken: /tmp/dogtail/screenshot_20060712-093640.png > click on {child with name="Save" ("?$A4f(B(S)", "$A1#4f(B(S)", "$A1#4f(B", "?$A4f(B", )} > Traceback (most recent call last): > File "./gedit-test-utf8-procedural-api.py", line 56, in ? > focus.dialog(u'Save As\u2026') > File "/usr/lib/python2.4/site-packages/dogtail/procedural.py", line > 78, in __call__ > result = FocusApplication.node.findChild(predicate, > requireResult=False, recursive = False) > File "/usr/lib/python2.4/site-packages/dogtail/tree.py", line 769, > in findChild > result.debugName = pred.describeSearchResult() > File "/usr/lib/python2.4/site-packages/dogtail/predicate.py", line > 235, in describeSearchResult > return '%s dialog'%self.dialogName > File "/usr/lib/python2.4/site-packages/dogtail/i18n.py", line 144, > in __str__ > result = '"%s" (%s)' % (self.untranslatedString, translations) > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position > 8: ordinal not in range(128) > > On ppc64: > ======== > # python ./gedit-test-utf8-procedural-api.py > Creating logfile at > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-133632 ... > Detecting distribution: Red Hat/Fedora/derived distribution > /tmp/dogtail/screenshot_20060712-133637.png > Screenshot taken: /tmp/dogtail/screenshot_20060712-133637.png > click on {child with name="Save"} > activate on {child with name="Browse for other folders"} > activate on {child with name="Desktop" roleName='table cell'} > click on {child with name="Save"} > click on {child with name="Quit"} > > ** (process:26377): WARNING **: Failed to send buffer > > ** (process:26377): WARNING **: Failed to send buffer > > ** (process:26377): WARNING **: Failed to send buffer > > ** (process:26377): WARNING **: Failed to send buffer > ...... > ** (process:26377): WARNING **: Failed to send buffer > > > The difference I noticed is: > > 1. There are some warning messages there in ppc64 complaining that > failed to send buffer > > 2. the gedit session quited on ppc64, don't on x86 > I guess it work correctly on ppc64, not on x86. > > 3. on x86, it complained with some warning message: > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > > I want to get some suggestion from you, what we need to do to test > dogtail seriously? Thanks a lot! > > Regards > - Wu Zhou > From ajocksch@redhat.com Wed Jul 12 13:36:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Wed, 12 Jul 2006 13:36:00 -0000 Subject: libunwind In-Reply-To: <20060711212327.83F97180061@magilla.sf.frob.com> References: <20060711212327.83F97180061@magilla.sf.frob.com> Message-ID: <44B4FAB9.3030903@redhat.com> Roland McGrath wrote: > It needs two kinds of things. One is access to the active thread/process > state, which is to say registers and memory. That goes to the frysk core > that is what's calling into libunwind. > > The other is access to the unwind info from the ELF files. This is data in > whole ELF sections (.debug_frame, .eh_frame) that nothing but the unwinder > needs to think about. The raw section contents are easily gotten from > libdwfl+libelf calls starting from the Dwfl object for an address space. > > The libunwind callbacks are especially poorly structured so that you need > to wade into a bunch of weirdness to have your callbacks use some libunwind > code that does part of the DWARF parsing, instead of simply supplying > libunwind with the raw sections it needs. > I like the idea of grabbing whole memory segmends from lib{dwfl,elf} and passing that into libunwind (or more specifically: the libunwind wrapper, most likely via a bytebuffer) rather than trying to mimic the C callbacks. There will still be some callbacks required for registers et al. but I think this would be a much cleaner approach. Does this sounds feasible? From woodzltc@cn.ibm.com Wed Jul 12 15:52:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 12 Jul 2006 15:52:00 -0000 Subject: About dogtail on x86 and ppc64 In-Reply-To: <17588.62608.340741.20235@localhost.redhat.com> References: <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> <17588.62608.340741.20235@localhost.redhat.com> Message-ID: <20060712115159.i06dh6svz4kgswgc@imap.linux.ibm.com> Quoting Elena Zannoni : > > Wu, thanks for starting looking at this. Len is using dogtail > successfully on x86 for testing of Frysk, so I suspect something in > your setup. Yes. I am now also thinking that it is the problem of setup. I can now make i18n-test.py, gnome-panel-test-starting-every-app.py and gcalctool-test-fibonacci.py work ok on x86. So I guess it also depends on how the target application behave whether it will work or not. BTW, I am using the latest rpm package for dogtail, pyspi, at-spi packages: dogtail-0.5.1-4.fc5 pyspi-0.5.4-3.fc5 at-spi-1.7.7-8 at-spi-devel-1.7.7-8 > On ppc64, Len was going to try it today, but since that > platform is more of an unknown, I am cc-ing Zack directly as well. But > in general I think Len can offer you some pointers on how to set > things up. I will appreciate that if anyone can give me guidance. Thanks. > > elena > > > Wu Zhou writes: > > Hello all, > > > > We can setup dogtail on x86 and ppc64 as well. > > > > On both platform, we run "python ./gedit-test-utf8-procedural-api.py". > > > > Here is the results: > > > > On x86: > > ======== > > # python ./gedit-test-utf8-procedural-api.py > > Creating logfile at > > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-093635 ... > > Detecting distribution: Red Hat/Fedora/derived distribution > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > GTK Accessibility Module initialized > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > Bonobo accessibility support initialized > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > /tmp/dogtail/screenshot_20060712-093640.png > > Screenshot taken: /tmp/dogtail/screenshot_20060712-093640.png > > click on {child with name="Save" ("?$A4f(S)", "$A1#4f(S)", > "$A1#4f", "?$A4f", )} > > Traceback (most recent call last): > > File "./gedit-test-utf8-procedural-api.py", line 56, in ? > > focus.dialog(u'Save As\u2026') > > File "/usr/lib/python2.4/site-packages/dogtail/procedural.py", line > > 78, in __call__ > > result = FocusApplication.node.findChild(predicate, > > requireResult=False, recursive = False) > > File "/usr/lib/python2.4/site-packages/dogtail/tree.py", line 769, > > in findChild > > result.debugName = pred.describeSearchResult() > > File "/usr/lib/python2.4/site-packages/dogtail/predicate.py", line > > 235, in describeSearchResult > > return '%s dialog'%self.dialogName > > File "/usr/lib/python2.4/site-packages/dogtail/i18n.py", line 144, > > in __str__ > > result = '"%s" (%s)' % (self.untranslatedString, translations) > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position > > 8: ordinal not in range(128) > > > > On ppc64: > > ======== > > # python ./gedit-test-utf8-procedural-api.py > > Creating logfile at > > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-133632 ... > > Detecting distribution: Red Hat/Fedora/derived distribution > > /tmp/dogtail/screenshot_20060712-133637.png > > Screenshot taken: /tmp/dogtail/screenshot_20060712-133637.png > > click on {child with name="Save"} > > activate on {child with name="Browse for other folders"} > > activate on {child with name="Desktop" roleName='table cell'} > > click on {child with name="Save"} > > click on {child with name="Quit"} > > > > ** (process:26377): WARNING **: Failed to send buffer > > > > ** (process:26377): WARNING **: Failed to send buffer > > > > ** (process:26377): WARNING **: Failed to send buffer > > > > ** (process:26377): WARNING **: Failed to send buffer > > ...... > > ** (process:26377): WARNING **: Failed to send buffer > > > > > > The difference I noticed is: > > > > 1. There are some warning messages there in ppc64 complaining that > > failed to send buffer > > > > 2. the gedit session quited on ppc64, don't on x86 > > I guess it work correctly on ppc64, not on x86. > > > > 3. on x86, it complained with some warning message: > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > > > > > I want to get some suggestion from you, what we need to do to test > > dogtail seriously? Thanks a lot! > > > > Regards > > - Wu Zhou > > > Regards - Wu Zhou From woodzltc@cn.ibm.com Wed Jul 12 16:12:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 12 Jul 2006 16:12:00 -0000 Subject: ftrace utility In-Reply-To: <44B4199B.1070509@redhat.com> References: <44B4199B.1070509@redhat.com> Message-ID: <20060712121241.o2h9kfq7ksk0c8sg@imap.linux.ibm.com> Quoting Sami Wagiaalla : > Hi everyone, > > After recent work on system calls, i have written ftrace which is a utility > with similar functionality to strace using the frysk engine. What it does is > start start the requested process though frysk add a systemcall observer > to it and starts printing out syscall info. It is a work in progress and atm > there are some obvious bugs in it. It does work however, and it is a proof > of concept. > > Please give it a run > frysk/frysk-core/prog/util/ftrace I give it a try. It works almost ok. some observation though. 1. The first system call is normally exec or similar, ftrace misses that. 2. There are some output like this "frysk.proc.Syscall@168f60", which should be a string representing a file directory. 3. I notice an exception when running "./prog/util/ftrace pwd" [woodzltc@woodzltc frysk-core]$ ./prog/util/ftrace pwd ftrace.main() Proc.getPid() 12938 brk (NULL) = 153636864 mmap (NULL,4096,3,34,-1,-38) = 0xb7fc9000 access ("frysk.proc.Syscall@168cc0,4) = -1 ERRNO=2 open ("frysk.proc.Syscall@168f60,0,0) = 3 fstat64 (3,0xbfdc758c) = 0 mmap (NULL,116510,1,2,3,-38) = 0xb7fac000 close (3) = 0 open ("frysk.proc.Syscall@168f60,0,-1208303616) = 3 read (3,0xbfdc76e8,512) = 512 fstat64 (3,0xbfdc7610) = 0 mmap (0x633000,1254780,5,2050,3,-38) = 0x633000 mmap (0x75f000,16384,3,2066,3,-38) = 0x75f000 mmap (0x763000,9596,3,50,-1,-38) = 0x763000 close (3) = 0 mmap (NULL,4096,3,34,-1,-38) = 0xb7fab000 set_thread_area (0xbfdc7ae8) = 0 mprotect (0x75f000,12288,1) = 0 mprotect (0x62f000,4096,1) = 0 munmap (0xb7fac000,116510) = 0 brk (NULL) = 153636864 brk (0x92a6000) = 153772032 open ("frysk.proc.Syscall@168f60,32768,1) = 3 fstat64 (3,0x762aa0) = 0 mmap (NULL,2097152,1,2,3,-38) = 0xb7dab000 close (3) = 0 lstat64 ("frysk.proc.Syscall@169d38,0xbfdc7c98) = 0 lstat64 ("frysk.proc.Syscall@169d38,0xbfdc7c98) = 0 Exception in thread "Thread-1" java.lang.ArrayIndexOutOfBoundsException: 295 at frysk.proc.Syscall.syscallByNum(ftrace) at prog.util.ftrace$SyscallObserver.updateSyscallEnter(ftrace) at frysk.proc.Task.notifySyscallEnter(ftrace) at frysk.proc.TaskState$SyscallRunning.handleSyscalledEvent(ftrace) at frysk.proc.Task.processSyscalledEvent(ftrace) at frysk.proc.LinuxHost$PollWaitOnSigChld$2.syscallEvent(ftrace) at frysk.sys.Wait.waitAllNoHang(ftrace) at frysk.proc.LinuxHost$PollWaitOnSigChld.execute(ftrace) at frysk.event.EventLoop.runEventLoop(ftrace) at frysk.event.EventLoop.run(ftrace) /root/DE-Frysk/latest-cvs/build/frysk-core Regards - Wu Zhou From woodzltc@cn.ibm.com Wed Jul 12 16:15:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 12 Jul 2006 16:15:00 -0000 Subject: About libunwind and dogtail In-Reply-To: <44B25E54.2000806@redhat.com> References: <20060708141112.i9oi6uv1w8scgg40@imap.linux.ibm.com> <44B25E54.2000806@redhat.com> Message-ID: <20060712121454.ysgd54twgk4wows4@imap.linux.ibm.com> Quoting Rick Moseley : > ** Expected results on x86 Linux > > The following tests are expected to fail on x86 Linux: > > Gtest-bt (see http://sources.redhat.com/bugzilla/show_bug.cgi?id=595) > Ltest-bt (likewise) > Gtest-resume-sig (likewise) > Ltest-resume-sig (likewise) > Gtest-dyn1 (no dynamic unwind info support yet) > Ltest-dyn1 (no dynamic unwind info support yet) > test-setjmp (longjmp() not implemented yet) > run-check-namespace (no _Ux86_getcontext yet) > > So, indeed, x86 tests are expected to fail and according to the README, > a lot of the same ones fail for x86_64. > > The first major feature we are trying to implement for Frysk using > libunwind will be to get backtraces, so, if you want some focus on where > to place development resources, that is the initial area we will be > concentrating on. Remote debugging is definitely in our plans, but is > not our immediate goal. We want to get local debugging solid before > moving on to remote deugging. Any changes you make should be flexible > enough to be able to handle remote debugging in the future. > > Hope this helps. Yes. These information are helpful Thanks a lot! Regards - Wu Zhou From ezannoni@redhat.com Wed Jul 12 17:34:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Wed, 12 Jul 2006 17:34:00 -0000 Subject: utrace in rawhide Message-ID: <17589.12833.351334.181018@localhost.redhat.com> Wu, utrace is in rawhide as of last night, kernel-2.6.17-1.2373.fc6. Any chance you can look at the ppc64 arch specific bits? Coordinate with Roland and Chris Moller for directions. thanks elena From ldimaggi@redhat.com Wed Jul 12 17:41:00 2006 From: ldimaggi@redhat.com (Len DiMaggio) Date: Wed, 12 Jul 2006 17:41:00 -0000 Subject: About dogtail on x86 and ppc64 In-Reply-To: <20060712115159.i06dh6svz4kgswgc@imap.linux.ibm.com> References: <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> <17588.62608.340741.20235@localhost.redhat.com> <20060712115159.i06dh6svz4kgswgc@imap.linux.ibm.com> Message-ID: <44B53427.6090901@redhat.com> 'Afternoon Wu, I was just able to build pyspi and dogtail from CVS and run the "gedit-test-utf8-procedural-api.py" sample script on a PPC (uname -a = Linux i5-lp5.test.redhat.com 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:57:06 EST 2006 ppc64 ppc64 ppc64 GNU/Linu) system. The only error that I encountered was a known, but not let logged bug about warning messages being displayed when a test exits: http://bugzilla.gnome.org/show_bug.cgi?id=347327 Have you tried building pyspi and dogtail from CVS head? -- Len D. Wu Zhou wrote: > Quoting Elena Zannoni : > >> >> Wu, thanks for starting looking at this. Len is using dogtail >> successfully on x86 for testing of Frysk, so I suspect something in >> your setup. > > Yes. I am now also thinking that it is the problem of setup. I can now > make i18n-test.py, gnome-panel-test-starting-every-app.py and > gcalctool-test-fibonacci.py work ok on x86. So I guess it also depends > on how the target application behave whether it will work or not. > > BTW, I am using the latest rpm package for dogtail, pyspi, at-spi > packages: > dogtail-0.5.1-4.fc5 > pyspi-0.5.4-3.fc5 > at-spi-1.7.7-8 > at-spi-devel-1.7.7-8 > >> On ppc64, Len was going to try it today, but since that >> platform is more of an unknown, I am cc-ing Zack directly as well. But >> in general I think Len can offer you some pointers on how to set >> things up. > > I will appreciate that if anyone can give me guidance. Thanks. > >> >> elena >> >> >> Wu Zhou writes: >> > Hello all, >> > >> > We can setup dogtail on x86 and ppc64 as well. >> > >> > On both platform, we run "python >> ./gedit-test-utf8-procedural-api.py". >> > >> > Here is the results: >> > >> > On x86: >> > ======== >> > # python ./gedit-test-utf8-procedural-api.py >> > Creating logfile at >> > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-093635 ... >> > Detecting distribution: Red Hat/Fedora/derived distribution >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > GTK Accessibility Module initialized >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > Bonobo accessibility support initialized >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > /tmp/dogtail/screenshot_20060712-093640.png >> > Screenshot taken: /tmp/dogtail/screenshot_20060712-093640.png >> > click on {child with name="Save" ("?$A4f(S)", "$A1#4f(S)", >> "$A1#4f", "?$A4f", )} >> > Traceback (most recent call last): >> > File "./gedit-test-utf8-procedural-api.py", line 56, in ? >> > focus.dialog(u'Save As\u2026') >> > File "/usr/lib/python2.4/site-packages/dogtail/procedural.py", >> line >> > 78, in __call__ >> > result = FocusApplication.node.findChild(predicate, >> > requireResult=False, recursive = False) >> > File "/usr/lib/python2.4/site-packages/dogtail/tree.py", line 769, >> > in findChild >> > result.debugName = pred.describeSearchResult() >> > File "/usr/lib/python2.4/site-packages/dogtail/predicate.py", line >> > 235, in describeSearchResult >> > return '%s dialog'%self.dialogName >> > File "/usr/lib/python2.4/site-packages/dogtail/i18n.py", line 144, >> > in __str__ >> > result = '"%s" (%s)' % (self.untranslatedString, translations) >> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position >> > 8: ordinal not in range(128) >> > >> > On ppc64: >> > ======== >> > # python ./gedit-test-utf8-procedural-api.py >> > Creating logfile at >> > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-133632 ... >> > Detecting distribution: Red Hat/Fedora/derived distribution >> > /tmp/dogtail/screenshot_20060712-133637.png >> > Screenshot taken: /tmp/dogtail/screenshot_20060712-133637.png >> > click on {child with name="Save"} >> > activate on {child with name="Browse for other folders"} >> > activate on {child with name="Desktop" roleName='table cell'} >> > click on {child with name="Save"} >> > click on {child with name="Quit"} >> > >> > ** (process:26377): WARNING **: Failed to send buffer >> > >> > ** (process:26377): WARNING **: Failed to send buffer >> > >> > ** (process:26377): WARNING **: Failed to send buffer >> > >> > ** (process:26377): WARNING **: Failed to send buffer >> > ...... >> > ** (process:26377): WARNING **: Failed to send buffer >> > >> > >> > The difference I noticed is: >> > >> > 1. There are some warning messages there in ppc64 complaining that >> > failed to send buffer >> > >> > 2. the gedit session quited on ppc64, don't on x86 >> > I guess it work correctly on ppc64, not on x86. >> > >> > 3. on x86, it complained with some warning message: >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception >> > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > >> > >> > I want to get some suggestion from you, what we need to do to test >> > dogtail seriously? Thanks a lot! >> > >> > Regards >> > - Wu Zhou >> > >> > > Regards > - Wu Zhou -- Len DiMaggio (ldimaggi@redhat.com) Red Hat USA 10 Technology Park Drive Westford, MA 01886 tel: 978.392.3179 cell: 617.872.3673 http://www.redhat.com From roland@redhat.com Wed Jul 12 18:42:00 2006 From: roland@redhat.com (Roland McGrath) Date: Wed, 12 Jul 2006 18:42:00 -0000 Subject: utrace in rawhide In-Reply-To: Elena Zannoni's message of Wednesday, 12 July 2006 13:32:17 -0400 <17589.12833.351334.181018@localhost.redhat.com> Message-ID: <20060712184229.A444C180061@magilla.sf.frob.com> > utrace is in rawhide as of last night, kernel-2.6.17-1.2373.fc6. > Any chance you can look at the ppc64 arch specific bits? ppc64 already works. From npremji@redhat.com Wed Jul 12 18:48:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Wed, 12 Jul 2006 18:48:00 -0000 Subject: Accessibility in EventViewer Message-ID: <1152730126.2442.7.camel@to-rhaps5.toronto.redhat.com> Here are my thoughts on accessibility in the event viewer. Specifically what I think needs to be done (and what I will be doing.) The eventviewer is made up of a bunch of widgets the most important of which is a large "drawing area" widget. (Actually there are two, one for the legend, and then the main drawing area.) There are about three major tasks that I can see right now. 1. Label each component widget with an accessibility name and description, for standard widgets this is apparently all that is needed to access them. (Done, committed) 2. Create some dogtail scripts to see if we can now interact with these widgets and for example click buttons and such or if more accessibility code is needed for these standard widgets. 3. Figure out some way to read the drawing areas to decipher what is actually being displayed. I suspect this will be the most challenging portion and the most useful for testing. Any thoughts on these? I have finished part 1 and am now looking into part 2. From woodzltc@cn.ibm.com Thu Jul 13 01:37:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 13 Jul 2006 01:37:00 -0000 Subject: utrace in rawhide In-Reply-To: <20060712184229.A444C180061@magilla.sf.frob.com> References: <20060712184229.A444C180061@magilla.sf.frob.com> Message-ID: <20060712213704.xsngyee7uoc0g80c@imap.linux.ibm.com> Quoting Roland McGrath : >> utrace is in rawhide as of last night, kernel-2.6.17-1.2373.fc6. >> Any chance you can look at the ppc64 arch specific bits? > > ppc64 already works. > That is great. I would like to have some try with that. But what is rawhide? Seen from http://download.fedora.redhat.com/pub/fedora/linux/core/development/, the kernel is 2.6.17-1.2366. Where can I get 2373? To Roland, can you please give any pointer for me to try utrace on ppc64.... build, setup, test and whatever you can thought of as helpful. Thanks! Regards - Wu Zhou From woodzltc@cn.ibm.com Thu Jul 13 01:53:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 13 Jul 2006 01:53:00 -0000 Subject: About dogtail on x86 and ppc64 In-Reply-To: <44B53427.6090901@redhat.com> References: <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> <17588.62608.340741.20235@localhost.redhat.com> <20060712115159.i06dh6svz4kgswgc@imap.linux.ibm.com> <44B53427.6090901@redhat.com> Message-ID: <20060712215258.09fmryrg0sk400kg@imap.linux.ibm.com> Quoting Len DiMaggio : > 'Afternoon Wu, > > I was just able to build pyspi and dogtail from CVS and run the > "gedit-test-utf8-procedural-api.py" sample script on a PPC (uname -a = > Linux i5-lp5.test.redhat.com 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 > 15:57:06 EST 2006 ppc64 ppc64 ppc64 GNU/Linu) system. > > The only error that I encountered was a known, but not let logged bug > about warning messages being displayed when a test exits: > http://bugzilla.gnome.org/show_bug.cgi?id=347327 I had a look at this bug report. It is the same as what I am seeing on ppc64. Lots of "WARNING **: Failed to send buffer". What does this mean? > Have you tried building pyspi and dogtail from CVS head? I didn't try that yet. Will find a chance to do that. Regards - Wu Zhou From mark@klomp.org Thu Jul 13 09:00:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 13 Jul 2006 09:00:00 -0000 Subject: utrace in rawhide In-Reply-To: <20060712213704.xsngyee7uoc0g80c@imap.linux.ibm.com> References: <20060712184229.A444C180061@magilla.sf.frob.com> <20060712213704.xsngyee7uoc0g80c@imap.linux.ibm.com> Message-ID: <1152781195.2738.26.camel@elsschot.wildebeest.org> On Wed, 2006-07-12 at 21:37 -0400, Wu Zhou wrote: > Quoting Roland McGrath : > > >> utrace is in rawhide as of last night, kernel-2.6.17-1.2373.fc6. > >> Any chance you can look at the ppc64 arch specific bits? > > > > ppc64 already works. > > > That is great. Nice indeed! > I would like to have some try with that. > > But what is rawhide? Seen from > http://download.fedora.redhat.com/pub/fedora/linux/core/development/, > the kernel is 2.6.17-1.2366. Where can I get 2373? Rawhide is the code name for Fedora development, so I guess it should be there, but hasn't been pushed out yet? > To Roland, can you please give any pointer for me to try utrace on > ppc64.... build, setup, test and whatever you can thought of as > helpful. Thanks! I haven't played with it myself yet. But Roland has a testframework (ntrace) plus some introduction texts to utrace available at: http://people.redhat.com/roland/utrace/ Cheers, Mark From mark@klomp.org Thu Jul 13 16:11:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 13 Jul 2006 16:11:00 -0000 Subject: Kill and refresh Message-ID: <1152807064.2738.58.camel@elsschot.wildebeest.org> Hi, I had some issues trying to write some tests that I tracked down to some TaskStates and the LinuxHost not handling disappearing/killed processes nicely. I tried to write a self contained test case, but I found it only triggered when running the EventLoop in its own Thread. This probably means that I haven't pinned down the real sequence of events causing this. Or maybe my idea of how process creation, Host process discovery and process disappearance should interact is not correct. Attached is a testcase that shows (at least for me) that a Task in the detached state can get a handleTerminatedEvent() call that it doesn't know how to handle. Could someone take a look/try this testcase out? And tell me whether it also fails for them and/or whether this is supposed to work or not? Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: newKillTest.diff Type: text/x-patch Size: 7895 bytes Desc: not available URL: From ipantuye@redhat.com Thu Jul 13 22:42:00 2006 From: ipantuye@redhat.com (Ivan Pantuyev) Date: Thu, 13 Jul 2006 22:42:00 -0000 Subject: terminal workflow meeting Message-ID: <44B6CB9D.8020202@redhat.com> What the "terminal" is: it's a terminal with a bash prompt all action in which is monitored by frysk. It was decided that an option should be added to the session manager to launch an empty session with a terminal window tab. See attached images for visual representation of the concept. -------------- next part -------------- A non-text attachment was scrubbed... Name: manager.png Type: image/png Size: 29980 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: monitor.png Type: image/png Size: 15911 bytes Desc: not available URL: From cagney@redhat.com Fri Jul 14 02:48:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 14 Jul 2006 02:48:00 -0000 Subject: [Fwd: [Bug general/1400] Host method for creating an AttachedStop process] Message-ID: <44B70652.6040105@redhat.com> Anyone care to enlighten me as to why one would do this? -------------- next part -------------- An embedded message was scrubbed... From: "zzejazz at hotmail dot com" Subject: [Bug general/1400] Host method for creating an AttachedStop process Date: 11 Jul 2006 02:20:33 -0000 Size: 2100 URL: From cagney@redhat.com Fri Jul 14 05:09:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 14 Jul 2006 05:09:00 -0000 Subject: Kill and refresh In-Reply-To: <1152807064.2738.58.camel@elsschot.wildebeest.org> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> Message-ID: <44B7273F.6040708@redhat.com> Mark Wielaard wrote: > Hi, > > I had some issues trying to write some tests that I tracked down to some > TaskStates and the LinuxHost not handling disappearing/killed processes > nicely. I tried to write a self contained test case, but I found it only > triggered when running the EventLoop in its own Thread. This probably > means that I haven't pinned down the real sequence of events causing > this. Or maybe my idea of how process creation, Host process discovery > and process disappearance should interact is not correct. > > Attached is a testcase that shows (at least for me) that a Task in the > detached state can get a handleTerminatedEvent() call that it doesn't > know how to handle. > > A detached process shouldn't be generating a terminated event; ah, it looks like it is a detached child process - can you check the parent-pid of the process to see what it is? I suspect the wait-pid is comming from the child exiting, rather than it being some how attached. Consequently, I'm not sure if it should be treated as a bug or wart? -- For reference I'll provide some commentary on the code (but the above is more interesting): > Could someone take a look/try this testcase out? > And tell me whether it also fails for them and/or whether this is > supposed to work or not? > > Thanks, > > Mark > > ------------------------------------------------------------------------ > > Index: frysk/proc/TestKill.java > =================================================================== > RCS file: frysk/proc/TestKill.java > diff -N frysk/proc/TestKill.java > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ frysk/proc/TestKill.java 13 Jul 2006 16:02:27 -0000 > @@ -0,0 +1,187 @@ > +// This file is part of the program FRYSK. > +// > +// Copyright 2006, Red Hat Inc. > +// > +// FRYSK is free software; you can redistribute it and/or modify it > +// under the terms of the GNU General Public License as published by > +// the Free Software Foundation; version 2 of the License. > +// > +// FRYSK is distributed in the hope that it will be useful, but > +// WITHOUT ANY WARRANTY; without even the implied warranty of > +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +// General Public License for more details. > +// > +// You should have received a copy of the GNU General Public License > +// along with FRYSK; if not, write to the Free Software Foundation, > +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. > +// > +// In addition, as a special exception, Red Hat, Inc. gives You the > +// additional right to link the code of FRYSK with code not covered > +// under the GNU General Public License ("Non-GPL Code") and to > +// distribute linked combinations including the two, subject to the > +// limitations in this paragraph. Non-GPL Code permitted under this > +// exception must only link to the code of FRYSK through those well > +// defined interfaces identified in the file named EXCEPTION found in > +// the source code files (the "Approved Interfaces"). The files of > +// Non-GPL Code may instantiate templates or use macros or inline > +// functions from the Approved Interfaces without causing the > +// resulting work to be covered by the GNU General Public > +// License. Only Red Hat, Inc. may make changes or additions to the > +// list of Approved Interfaces. You must obey the GNU General Public > +// License in all respects for all of the FRYSK code and other code > +// used in conjunction with FRYSK except the Non-GPL Code covered by > +// this exception. If you modify this file, you may extend this > +// exception to your version of the file, but you are not obligated to > +// do so. If you do not wish to provide this exception without > +// modification, you must delete this exception statement from your > +// version and license this file solely under the GPL without > +// exception. > + > +package frysk.proc; > + > +import frysk.sys.*; > +import frysk.event.*; > + > +/** > + * Check that a program can be killed/disappear without the > + * core going crazy. > + */ > +public class TestKill > + extends TestLib > +{ > + > + // The eventloop that needs to be stopped at the end of the test. > + EventLoopRunner eventloop; > + > + // Process ids that need to be cleaned up. > + int pid1, pid2; > There's http://sourceware.org/frysk/javadoc/private/frysk/proc/TestLib.html#killDuringTearDown:int > + > + // Monitor that gets notified as soon as some event occured. > + Object monitor = new Object(); > + > + public void setUp() > + { > super.setUp (); > + pid1 = pid2 = -1; > + eventloop = new EventLoopRunner(); > + eventloop.start(); > + } > + > + public void tearDown() > + { > + try > + { > + if (pid1 != -1) > + Signal.kill(pid1, Sig.KILL); > + } > + catch(Errno e) > + { > + // Already killed > + } > + > + try > + { > + if (pid2 != -1) > + Signal.kill(pid2, Sig.KILL); > + } > + catch(Errno e) > + { > + // Already killed > + } > + > + eventloop.requestStop(); > + } > + > + public void testKill() > + { > + // Create a detached process. > + String command = getExecPrefix() + "funit-loop"; > + pid1 = Fork.daemon (null, null, null, new String[] { command }); > You'll want a way of knowing that the funit-loop process is really running, funit-child, for instance, does this be sending frysk a signal(2) once it is fully set up - frysk runs the event loop until it sees that signal. > + ProcId procId1 = new ProcId(pid1); > + > + // Try to find it > + Manager.host.requestRefreshXXX(true); > Call runPending() here, it will process the refresh. > + > + // No, lets kill it... > + Signal.kill(pid1, Sig.KILL); > This should generate an event. You just want to know that the event has been received and processed. Will this event have an effect that can be observed? If there is, add an observer to it, and then when it occures, request the event loop to shut down. > +int > +main (int argc, char **argv) > +{ > + // Happily count to infinity > + int i = 0; > + while(1) > + i++; > + > + return 0; > +} > suggest having a timer as well (default 5 seconds) so that if frysk crashes this isn't left around (at least long term). Andrew From mark@klomp.org Fri Jul 14 09:59:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 09:59:00 -0000 Subject: FYI: Removed unused imports from TestStackBacktrace.java Message-ID: <1152871165.2529.4.camel@elsschot.wildebeest.org> Hi, My ecj was complaining (and failing to build) TestStackBacktrace because of unused imports. Removed to make the build succeed again. 2005-07-14 Mark Wielaard * TestStackBacktrace.java: Removed unused Level and Host imports. Committed, Mark diff -u -r1.4 TestStackBacktrace.java --- frysk-core/frysk/rt/TestStackBacktrace.java 13 Jul 2006 20:21:04 -0000 1.4 +++ frysk-core/frysk/rt/TestStackBacktrace.java 14 Jul 2006 09:57:44 -0000 @@ -39,10 +39,7 @@ package frysk.rt; -import java.util.logging.Level; - import frysk.proc.Action; -import frysk.proc.Host; import frysk.proc.Manager; import frysk.proc.Task; import frysk.proc.TaskObserver; From mark@klomp.org Fri Jul 14 10:06:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 10:06:00 -0000 Subject: frysk-imports/libunwind ChangeLog Makefile.in In-Reply-To: <20060714090033.18852.qmail@sourceware.org> References: <20060714090033.18852.qmail@sourceware.org> Message-ID: <20060714100558.GA24601@elsschot.wildebeest.org> Hi Stephan, On Fri, Jul 14, 2006 at 09:00:33AM -0000, kasal@sourceware.org wrote: > * Makefile.in: Do not install for frysk. This seems to cause the following error for me: Making all in libunwind make[3]: Entering directory `/home/mark/src/build/frysk-imports/libunwind' Makefile:125: *** target file `install' has both : and :: entries. Stop. make[3]: Leaving directory `/home/mark/src/build/frysk-imports/libunwind' make[2]: *** [all-recursive] Error 1 Reverting frysk-imports/libunwind/Makefile.in to revision 1.2 solved it for me for now. Could you have a look? I admit to not actually knowing what : and :: entries are. Thanks, Mark From roland@redhat.com Fri Jul 14 10:43:00 2006 From: roland@redhat.com (Roland McGrath) Date: Fri, 14 Jul 2006 10:43:00 -0000 Subject: utrace in rawhide In-Reply-To: Wu Zhou's message of Wednesday, 12 July 2006 21:37:04 -0400 <20060712213704.xsngyee7uoc0g80c@imap.linux.ibm.com> Message-ID: <20060714104329.BC4CF180062@magilla.sf.frob.com> > But what is rawhide? Seen from > http://download.fedora.redhat.com/pub/fedora/linux/core/development/, > the kernel is 2.6.17-1.2366. Where can I get 2373? Sorry, "in rawhide" doesn't necessarily mean "successfully built in rawhide". ;-) There is a lot of flux in rawhide this week generally, and issues in the kernel build aside from the utrace integration. There may be some delay in getting the published rpms updated when things are changing and breaking fast; I think it's updated once a day and can that fail to happen if there are bugs in building the distribution, which is not too uncommon for rawhide. Usually there will be something new and usable within a few days at most. Rawhide will become FC6 test2 next week, so things will be fixed by then. You can always see the complete Fedora Core development sources going into the rpms with at most a few hours lag via cvs from cvs.fedora.redhat.com (web pages there describe using cvs or cvsweb). What you find there might not be successfully built into rpms yet, or might be built at Red Hat but not percolated to the download web site yet. > To Roland, can you please give any pointer for me to try utrace on > ppc64.... build, setup, test and whatever you can thought of as > helpful. Thanks! Whenever you get a new rawhide kernel that works, that will be all you need to be using utrace. Right now, the most constructive way to help is with testing of existing things that use ptrace on the new kernel. The ptrace system call implementation is now layered on top of the new utrace core. So testing uses of ptrace tests the whole body of new code. So, running whatever there is using ptrace: use strace, use gdb, run the frysk test suite, run the gdb test suite. For all such tests you can do, run the test on an old kernel that works (rawhide from a while back if it was stable for you, or something more reliable like FC5), and compare those results as a baseline with running that test on the new utrace-based kernel. I'm not interested in the absolute results--the exercise is not to debug strace, or gdb, or frysk. These tests exercise the kernel support for the ptrace system call interface, and the new kernel aims to exactly match the defined behavior of the old ptrace code. What we need to examine is every difference in behavior of a test between the old kernel and the new kernel. Rick Moseley did some testing of the frysk suite on my kernels a while back and found some problems, regressions from the stable kernel. I still have not gotten to debugging those, so if you use the frysk suite I won't be surprised to see some regressions. I'd appreciate the assistance of any efforts you can make in whittling down each failure to the concise description of what pattern of ptrace system calls elicited what kind of wrong kernel behavior. (The ideal for me is that it's reduced to a self-contained all-C test case reproducing the bug using direct ptrace calls, that I can use as a small regression test for kernel debugging and to put into a kernel regression test suite.) The gdb test suite is the most thorough and moderately torturous test of ptrace (and by extension, all my new utrace infrastructure code) I know of. I've just written up detailed instructions for the folks doing new utrace arch support, on setting up and running it, comparing the results, and doing all the myriad biarch variations that can be tested. If you get to the stage of wanting to run the hard tests and scour painfully for the obscure problems, I can send you the same details. For ppc64, I did already do the testing with gdb, including all the biarch variations, though it was a while ago now the last time I did it. It should be done again, but there is good reason to hope that it will at worst show minor regressions from what I had working before. What I've not tested at all is the native ppc32 kernel. I don't have an old mac laptop lying around, nor a working qemu setup handy to try it. I did what I think is all the work for the arch support for ppc32 kernels along with the ppc64 support and ppc32 users on ppc64 (which I tested). (My only powerpc hardware is a Mac G5 supplied by IBM.) In the near future, there will be another test suite specifically for newer utrace stuff. It will be useful to use that often on all kinds of machines and look into anything that crops up. But for now, by far the most effective means of testing is normal stuff using good old crufty ptrace. Thanks, Roland From mark@klomp.org Fri Jul 14 12:17:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 12:17:00 -0000 Subject: Kill and refresh In-Reply-To: <44B7273F.6040708@redhat.com> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> Message-ID: <1152879437.2529.31.camel@elsschot.wildebeest.org> Hi Andrew, On Fri, 2006-07-14 at 01:10 -0400, Andrew Cagney wrote: > A detached process shouldn't be generating a terminated event; OK, that is what I expected. I have also seen this happen in the disappeared state. I assume Terminated events should also not happen in that state? > ah, it > looks like it is a detached child process - can you check the parent-pid > of the process to see what it is? I am a bit confused by what parent-pid it has. It seems to have a ppid that doesn't exist (anymore). I assume this is because we start the process with Fork.daemon(), so it has has ppid our forked process that is no longer there. I had assumed that would mean that the ppid would be zero. This is different from when we create the process with Fork.exec(), then it has a ppid the process id/main thread id of our process. > I suspect the wait-pid is comming > from the child exiting, rather than it being some how attached. > Consequently, I'm not sure if it should be treated as a bug or wart? According to Wait.log() we are seeing three waitpids with: pid: 0, status: 1be660, errno: 0 pid: 32500, status: 0, errno: 0 pid: -1, status: b73b1300, errno: 10 Where 32500 is the non-existing process described above. > For reference I'll provide some commentary on the code (but the above is > more interesting): > There's > http://sourceware.org/frysk/javadoc/private/frysk/proc/TestLib.html#killDuringTearDown:int Thanks. While writing some tests I seem to be duplicating functionality of TestLib. Will cleanup and use that. > > + public void setUp() > > + { > > > super.setUp (); Similar as above. But this time I knew and explicitly didn't want to use it to get a more minimal testcase to see if I better understood what went wrong where. So I didn't wanted to add extra observers if not absolutely necessary. > You'll want a way of knowing that the funit-loop process is really > running, funit-child, for instance, does this be sending frysk a > signal(2) once it is fully set up - frysk runs the event loop until it > sees that signal. Yes, I actually have an addition to Fork which just gives you an Input/OutputStream to the process to communicate with. I found that a little more convenient then using signals. I'll post it to the list so you can see if that is something we might want to add. > > + ProcId procId1 = new ProcId(pid1); > > + > > + // Try to find it > > + Manager.host.requestRefreshXXX(true); > > > Call runPending() here, it will process the refresh. Right. But... that was the confusing thing. I could only get this weird failure when running the EventLoop in a separate Thread. When starting/stopping/resuming the EventLoop on the same thread things do seem to go forward without getting the weird state transitions of the tasks. That was why I started writing this testcase in the first place to understand where/when exactly I would get such unexpected TerminateEvents. > > + // No, lets kill it... > > + Signal.kill(pid1, Sig.KILL); > > > This should generate an event. > > You just want to know that the event has been received and processed. > Will this event have an effect that can be observed? If there is, add > an observer to it, and then when it occures, request the event loop to > shut down. Right again, but I wanted to test what happened when a signal was send to a process that wasn't attached. And when I add an observer then the process will become attached. So it then is in a different state then I was interested in. > > +int > > +main (int argc, char **argv) > > +{ > > + // Happily count to infinity > > + int i = 0; > > + while(1) > > + i++; > > + > > + return 0; > > +} > > > suggest having a timer as well (default 5 seconds) so that if frysk > crashes this isn't left around (at least long term). Good point. Added that with a simple alarm. Cheers, Mark From mark@klomp.org Fri Jul 14 12:24:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 12:24:00 -0000 Subject: Kill and refresh In-Reply-To: <1152879437.2529.31.camel@elsschot.wildebeest.org> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> <1152879437.2529.31.camel@elsschot.wildebeest.org> Message-ID: <1152879848.2529.35.camel@elsschot.wildebeest.org> On Fri, 2006-07-14 at 14:17 +0200, Mark Wielaard wrote: > > I suspect the wait-pid is comming > > from the child exiting, rather than it being some how attached. > > Consequently, I'm not sure if it should be treated as a bug or wart? > > According to Wait.log() [...] While investigating this I noticed that errno wasn't saved before calling log() which seems to make it possible for errno to change before it is actually used in the next statement. Does the following patch make sense? 2006-07-14 Mark Wielaard * cni/Wait.cxx (waitAll): Save errno before calling log(). Cheers, Mark --- frysk/sys/cni/Wait.cxx 15 Jun 2006 19:23:28 -0000 1.13 +++ frysk/sys/cni/Wait.cxx 14 Jul 2006 12:22:55 -0000 @@ -224,9 +224,10 @@ int status; errno = 0; pid_t pid = ::waitpid (wpid, &status, __WALL); + int myErrno = errno; log (pid, status, errno); if (pid <= 0) - throwErrno (errno, "waitpid", "process", wpid); + throwErrno (myErrno, "waitpid", "process", wpid); // Process the result. processStatus (pid, status, observer); } From mark@klomp.org Fri Jul 14 12:49:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 12:49:00 -0000 Subject: Kill and refresh In-Reply-To: <1152879437.2529.31.camel@elsschot.wildebeest.org> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> <1152879437.2529.31.camel@elsschot.wildebeest.org> Message-ID: <1152881355.2529.41.camel@elsschot.wildebeest.org> On Fri, 2006-07-14 at 14:17 +0200, Mark Wielaard wrote: > Yes, I actually have an addition to Fork which just gives you an > Input/OutputStream to the process to communicate with. I found that a > little more convenient then using signals. I'll post it to the list so > you can see if that is something we might want to add. Here it is. I found it useful to write some quick tests which needed to exchange information with the child process without needing to attach to the process or send signals between frysk and the child process. 2006-07-14 Mark Wielaard * Fork.java (ForkedProcess): New static inner class. (ForkedInputStream): Likewise. (ForkedOutputStream): Likewise. (ForkedProcess): New static method. * cni/Fork.cxx (fork): New method. (ForkedOutputStream::write): Likewise. (ForkedInputStream::read(void)): Likewise. (ForkedInputStream::read(jbyteArray,jint,jint)): Likewise. At first I used Runtime.exec() for this, but since that spawns a new Thread that tries to wait() on all processes that didn't work nicely with the rest of frysk core. Would it make sense to add this new functionality to Fork? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: Fork.patch Type: text/x-patch Size: 5852 bytes Desc: not available URL: From mark@klomp.org Fri Jul 14 13:05:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 13:05:00 -0000 Subject: frysk-imports/libunwind ChangeLog Makefile.in In-Reply-To: <20060714100558.GA24601@elsschot.wildebeest.org> References: <20060714090033.18852.qmail@sourceware.org> <20060714100558.GA24601@elsschot.wildebeest.org> Message-ID: <1152882322.2529.44.camel@elsschot.wildebeest.org> On Fri, 2006-07-14 at 12:05 +0200, Mark Wielaard wrote: > Reverting frysk-imports/libunwind/Makefile.in to revision 1.2 solved it > for me for now. Could you have a look? I admit to not actually knowing > what : and :: entries are. And 2 minutes after I posted this Stephan already fixed it. Thanks! For those wondering about :: Makefile rules, they are explained at: http://www.gnu.org/software/make/manual/html_node/Double_002dColon.html Cheers, Mark From mcvet@redhat.com Fri Jul 14 13:39:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 14 Jul 2006 13:39:00 -0000 Subject: [Fwd: [Bug general/1400] Host method for creating an AttachedStop process] In-Reply-To: <44B70652.6040105@redhat.com> References: <44B70652.6040105@redhat.com> Message-ID: <1152884385.2054.1.camel@to-rhaps3.toronto.redhat.com> On Thu, 2006-07-13 at 22:49 -0400, Andrew Cagney wrote: > Anyone care to enlighten me as to why one would do this? > > email message attachment ([Bug general/1400] Host method for creating > an AttachedStop process) > > -------- Forwarded Message -------- > > From: zzejazz at hotmail dot com > > > > Reply-To: sourceware-bugzilla@sourceware.org > > To: cagney@redhat.com > > Subject: [Bug general/1400] Host method for creating an AttachedStop > > process > > Date: 11 Jul 2006 02:20:33 -0000 > > Weirdest thing I've ever seen... From mark@klomp.org Fri Jul 14 13:51:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 13:51:00 -0000 Subject: [Fwd: [Bug general/1400] Host method for creating an AttachedStop process] In-Reply-To: <44B70652.6040105@redhat.com> References: <44B70652.6040105@redhat.com> Message-ID: <1152885079.2529.49.camel@elsschot.wildebeest.org> On Thu, 2006-07-13 at 22:49 -0400, Andrew Cagney wrote: > Anyone care to enlighten me as to why one would do this? I looked at the attachment and wanted to comment on what seemed to be missing and what I thought it was supposed to do. Then I looked at the actual bug report and see that it really has nothing at all to do with the bug report... Which was already closed in the first place... This seems to be someone that has gone through the trouble of registering an account with our bugzilla, then attached a random file to a bug report and assigned the bug to him/her self. I cannot enlighten you because I am too confused myself as to why someone would do that. Cheers, Mark From cagney@redhat.com Fri Jul 14 14:42:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 14 Jul 2006 14:42:00 -0000 Subject: Kill and refresh In-Reply-To: <1152879848.2529.35.camel@elsschot.wildebeest.org> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> <1152879437.2529.31.camel@elsschot.wildebeest.org> <1152879848.2529.35.camel@elsschot.wildebeest.org> Message-ID: <44B7ADA4.9030205@redhat.com> Mark Wielaard wrote: > On Fri, 2006-07-14 at 14:17 +0200, Mark Wielaard wrote: > >>> I suspect the wait-pid is comming >>> from the child exiting, rather than it being some how attached. >>> Consequently, I'm not sure if it should be treated as a bug or wart? >>> >> According to Wait.log() [...] >> > > While investigating this I noticed that errno wasn't saved before > calling log() which seems to make it possible for errno to change before > it is actually used in the next statement. Does the following patch make > sense? > Big oops! Thanks! > 2006-07-14 Mark Wielaard > > * cni/Wait.cxx (waitAll): Save errno before calling log(). > > Cheers, > > Mark > > --- frysk/sys/cni/Wait.cxx 15 Jun 2006 19:23:28 -0000 1.13 > +++ frysk/sys/cni/Wait.cxx 14 Jul 2006 12:22:55 -0000 > @@ -224,9 +224,10 @@ > int status; > errno = 0; > pid_t pid = ::waitpid (wpid, &status, __WALL); > + int myErrno = errno; > log (pid, status, errno); > if (pid <= 0) > - throwErrno (errno, "waitpid", "process", wpid); > + throwErrno (myErrno, "waitpid", "process", wpid); > // Process the result. > processStatus (pid, status, observer); > } > > > From mcvet@redhat.com Fri Jul 14 15:16:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 14 Jul 2006 15:16:00 -0000 Subject: x86_64 build failiure Message-ID: <1152890160.2054.4.camel@to-rhaps3.toronto.redhat.com> On a Xeon machine: Making all in libunwind make[3]: Entering directory `/home/mcvet/build/frysk-imports/libunwind' make[4]: Entering directory `/home/mcvet/build/frysk-imports/libunwind/src' rm -f libunwind-x86_64.so* gcc -shared -nostartfiles -Wl,-soname,libunwind-x86_64.so.7 -o libunwind-x86_64.so.7.0 elf64.os mi/init.os mi/flush_cache.os mi/mempool.os mi/strerror.os x86_64/regname.os x86_64/is_fpreg.os os-linux.os dwarf/global.os mi/Gdyn-extract.os mi/Gfind_dynamic_proc_info.os mi/Gget_accessors.os mi/Gget_proc_info_by_ip.os mi/Gget_proc_name.os mi/Gput_dynamic_unwind_info.os mi/Gdestroy_addr_space.os mi/Gget_reg.os mi/Gset_reg.os mi/Gget_fpreg.os mi/Gset_fpreg.os mi/Gset_caching_policy.os x86_64/Gcreate_addr_space.os x86_64/Gget_proc_info.os x86_64/Gget_save_loc.os x86_64/Gglobal.os x86_64/Ginit.os x86_64/Ginit_local.os x86_64/Ginit_remote.os x86_64/Gis_signal_frame.os x86_64/Gregs.os x86_64/Gresume.os x86_64/Gstep.os dwarf/Gfind_proc_info-lsb.os dwarf/Gexpr.os dwarf/Gfde.os dwarf/Gparser.os dwarf/Gpe.os dwarf/Gstep.os mi/Gdyn-remote.os && ln -s libunwind-x86_64.so.7.0 libunwind-x86_64.so.7 && ln -s libunwind-x86_64.so.7.0 libunwind-x86_64.so /usr/bin/ld: dwarf/Gfind_proc_info-lsb.os: relocation R_X86_64_PC32 against `_Ux86_64_dwarf_search_unwind_table' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[4]: *** [libunwind-x86_64.so] Error 1 make[4]: Leaving directory `/home/mcvet/build/frysk-imports/libunwind/src' make[3]: *** [all] Error 1 make[3]: Leaving directory `/home/mcvet/build/frysk-imports/libunwind' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/mcvet/build/frysk-imports' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/mcvet/build/frysk-imports' make: *** [all-recursive] Error 1 Can someone please take a look at this? Thanks, Mike From mark@klomp.org Fri Jul 14 20:12:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 14 Jul 2006 20:12:00 -0000 Subject: Error opening frysk In-Reply-To: <20060714195753.97376.qmail@web53811.mail.yahoo.com> References: <20060714195753.97376.qmail@web53811.mail.yahoo.com> Message-ID: <1152907945.21275.8.camel@hermans.wildebeest.org> Hi, On Fri, 2006-07-14 at 12:57 -0700, Shwetha Doss wrote: > Mark, > > I am unable to send to the group.( I dont knwo why its failing). It > would be great if u you could help me with this. Unfortunately I have never seen these error messages. I have CCed the list. Hopefully someone else recognizes them. If all fails you could try building your own Frysk from source using the instructions at: http://sourceware.org/frysk/build/ > While trying to run frysk on my > FC5,( frysk-0.0.1.2006.06.15.rh4-0.FC5), this is the error message > that pops up.Please help. > > [shwetha@localhost ~]$ frysk > java.lang.NullPointerException > at frysk.gui.monitor.ObservableLinkedList.load(frysk) > at frysk.gui.monitor.LiaisonPoint.load(frysk) > at frysk.gui.monitor.observers.ObserverRoot.load(frysk) > at frysk.gui.monitor.ObjectFactory.loadObject(frysk) > at frysk.gui.monitor.observers.ObserverManager.loadObservers(frysk) > at frysk.gui.monitor.observers.ObserverManager.(frysk) > at java.lang.Class.initializeClass(libgcj.so.7) > at frysk.gui.monitor.CustomObserverDialog.(frysk) > at frysk.gui.monitor.WindowManager.initLegacyProcpopWindows(frysk) > at frysk.gui.Gui.(frysk) > at frysk.gui.Gui.gui(frysk) > at frysk.main(frysk) > Exception in thread "main" java.lang.ExceptionInInitializerError > at java.lang.Class.initializeClass(libgcj.so.7) > at frysk.gui.monitor.CustomObserverDialog.(frysk) > at frysk.gui.monitor.WindowManager.initLegacyProcpopWindows(frysk) > at frysk.gui.Gui.(frysk) > at frysk.gui.Gui.gui(frysk) > at frysk.main(frysk) > Caused by: java.lang.NullPointerException > at frysk.gui.monitor.UniqueHashMap.add(frysk) > at > frysk.gui.monitor.observers.ObserverManager.addTaskObserverPrototype(frysk) > at frysk.gui.monitor.observers.ObserverManager.loadObservers(frysk) > at frysk.gui.monitor.observers.ObserverManager.(frysk) > at java.lang.Class.initializeClass(libgcj.so.7) > ...5 more > > > > > > Regards, > Shwetha Harish From pmuldoon@redhat.com Fri Jul 14 20:31:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 14 Jul 2006 20:31:00 -0000 Subject: Error opening frysk In-Reply-To: <1152907945.21275.8.camel@hermans.wildebeest.org> References: <20060714195753.97376.qmail@web53811.mail.yahoo.com> <1152907945.21275.8.camel@hermans.wildebeest.org> Message-ID: <44B7FF47.4080702@redhat.com> Shweta, Best things to do in these cases is file a bug in the bugzilla so we can track it. I would try doing something like mv ~/.frysk ~/.frysk_old just to make sure something in the ~/.frysk store is not corrupted. Let us now if that works! Regards Phil Mark Wielaard wrote: > Hi, > > On Fri, 2006-07-14 at 12:57 -0700, Shwetha Doss wrote: > >> Mark, >> >> I am unable to send to the group.( I dont knwo why its failing). It >> would be great if u you could help me with this. >> > > Unfortunately I have never seen these error messages. I have CCed the > list. Hopefully someone else recognizes them. > > If all fails you could try building your own Frysk from source using the > instructions at: http://sourceware.org/frysk/build/ > > >> While trying to run frysk on my >> FC5,( frysk-0.0.1.2006.06.15.rh4-0.FC5), this is the error message >> that pops up.Please help. >> >> [shwetha@localhost ~]$ frysk >> java.lang.NullPointerException >> at frysk.gui.monitor.ObservableLinkedList.load(frysk) >> at frysk.gui.monitor.LiaisonPoint.load(frysk) >> at frysk.gui.monitor.observers.ObserverRoot.load(frysk) >> at frysk.gui.monitor.ObjectFactory.loadObject(frysk) >> at frysk.gui.monitor.observers.ObserverManager.loadObservers(frysk) >> at frysk.gui.monitor.observers.ObserverManager.(frysk) >> at java.lang.Class.initializeClass(libgcj.so.7) >> at frysk.gui.monitor.CustomObserverDialog.(frysk) >> at frysk.gui.monitor.WindowManager.initLegacyProcpopWindows(frysk) >> at frysk.gui.Gui.(frysk) >> at frysk.gui.Gui.gui(frysk) >> at frysk.main(frysk) >> Exception in thread "main" java.lang.ExceptionInInitializerError >> at java.lang.Class.initializeClass(libgcj.so.7) >> at frysk.gui.monitor.CustomObserverDialog.(frysk) >> at frysk.gui.monitor.WindowManager.initLegacyProcpopWindows(frysk) >> at frysk.gui.Gui.(frysk) >> at frysk.gui.Gui.gui(frysk) >> at frysk.main(frysk) >> Caused by: java.lang.NullPointerException >> at frysk.gui.monitor.UniqueHashMap.add(frysk) >> at >> frysk.gui.monitor.observers.ObserverManager.addTaskObserverPrototype(frysk) >> at frysk.gui.monitor.observers.ObserverManager.loadObservers(frysk) >> at frysk.gui.monitor.observers.ObserverManager.(frysk) >> at java.lang.Class.initializeClass(libgcj.so.7) >> ...5 more >> >> >> >> >> >> Regards, >> Shwetha Harish >> > > From mark@klomp.org Sat Jul 15 12:15:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Sat, 15 Jul 2006 12:15:00 -0000 Subject: Error opening frysk In-Reply-To: <20060715000133.72151.qmail@web53803.mail.yahoo.com> References: <20060715000133.72151.qmail@web53803.mail.yahoo.com> Message-ID: <1152965708.2791.31.camel@hermans.wildebeest.org> On Fri, 2006-07-14 at 17:01 -0700, Shwetha Doss wrote: > What is strange is that this error comes up only when I choose "Debug > the executable" from the initial pop-up screen. > > Any ideas? That option only works for executables that have all debug information available (including the libraries). Older versions of Frysk didn't put up a nice dialog warning about this. That might be it. Cheers, Mark From woodzltc@cn.ibm.com Sun Jul 16 16:24:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sun, 16 Jul 2006 16:24:00 -0000 Subject: utrace in rawhide In-Reply-To: <20060714104329.BC4CF180062@magilla.sf.frob.com> References: <20060714104329.BC4CF180062@magilla.sf.frob.com> Message-ID: <20060716122411.engz7yhbggww8wk0@imap.linux.ibm.com> Quoting Roland McGrath : >> But what is rawhide? Seen from >> http://download.fedora.redhat.com/pub/fedora/linux/core/development/, >> the kernel is 2.6.17-1.2366. Where can I get 2373? > > Sorry, "in rawhide" doesn't necessarily mean "successfully built in rawhide". > ;-) There is a lot of flux in rawhide this week generally, and issues in > the kernel build aside from the utrace integration. There may be some > delay in getting the published rpms updated when things are changing and > breaking fast; I think it's updated once a day and can that fail to happen > if there are bugs in building the distribution, which is not too uncommon > for rawhide. Usually there will be something new and usable within a few > days at most. Rawhide will become FC6 test2 next week, so things will be > fixed by then. You can always see the complete Fedora Core development > sources going into the rpms with at most a few hours lag via cvs from > cvs.fedora.redhat.com (web pages there describe using cvs or cvsweb). What > you find there might not be successfully built into rpms yet, or might be > built at Red Hat but not percolated to the download web site yet. Thanks for these information. They explained well why I can't get my ppc64 box boot up. :-) I had also a test with the yesterday's kernel build and had no luck yet. One guy named DaveJ said that it might be the problem of mkinitrd. I hope that it will be fixed soon. Using these kernel, I can boot up x86. But the scripts/mod/modpost reports a "float point exception" when trying to build crash_suspend.o into a kernel module. I am trying to use modpost in other kernel build, but with no luck too. >> To Roland, can you please give any pointer for me to try utrace on >> ppc64.... build, setup, test and whatever you can thought of as >> helpful. Thanks! > > Whenever you get a new rawhide kernel that works, that will be all you need > to be using utrace. Right now, the most constructive way to help is with > testing of existing things that use ptrace on the new kernel. The ptrace > system call implementation is now layered on top of the new utrace core. > So testing uses of ptrace tests the whole body of new code. So, running > whatever there is using ptrace: use strace, use gdb, run the frysk test > suite, run the gdb test suite. For all such tests you can do, run the test > on an old kernel that works (rawhide from a while back if it was stable for > you, or something more reliable like FC5), and compare those results as a > baseline with running that test on the new utrace-based kernel. I'm not > interested in the absolute results--the exercise is not to debug strace, or > gdb, or frysk. These tests exercise the kernel support for the ptrace > system call interface, and the new kernel aims to exactly match the defined > behavior of the old ptrace code. What we need to examine is every > difference in behavior of a test between the old kernel and the new kernel. Yes. We need to make these two compatible. > > Rick Moseley did some testing of the frysk suite on my kernels a while back > and found some problems, regressions from the stable kernel. I still have > not gotten to debugging those, so if you use the frysk suite I won't be > surprised to see some regressions. I'd appreciate the assistance of any > efforts you can make in whittling down each failure to the concise > description of what pattern of ptrace system calls elicited what kind of > wrong kernel behavior. (The ideal for me is that it's reduced to a > self-contained all-C test case reproducing the bug using direct ptrace > calls, that I can use as a small regression test for kernel debugging and > to put into a kernel regression test suite.) Good idea. If I find any failure/difference, I will try to reduce that to a small reproducible testcase. > > The gdb test suite is the most thorough and moderately torturous test of > ptrace (and by extension, all my new utrace infrastructure code) I know of. > I've just written up detailed instructions for the folks doing new utrace > arch support, on setting up and running it, comparing the results, and > doing all the myriad biarch variations that can be tested. If you get to > the stage of wanting to run the hard tests and scour painfully for the > obscure problems, I can send you the same details. I would like to. Can you send me these detail? Thanks. > For ppc64, I did already do the testing with gdb, including all the biarch > variations, though it was a while ago now the last time I did it. It > should be done again, but there is good reason to hope that it will at > worst show minor regressions from what I had working before. > > What I've not tested at all is the native ppc32 kernel. I don't have an > old mac laptop lying around, nor a working qemu setup handy to try it. > I did what I think is all the work for the arch support for ppc32 kernels > along with the ppc64 support and ppc32 users on ppc64 (which I tested). > (My only powerpc hardware is a Mac G5 supplied by IBM.) I had a ppc32 machine available. But I am not sure if I can squeeze some time to run test on it. If time/resource is available, I will have a test on that. > > In the near future, there will be another test suite specifically for newer > utrace stuff. It will be useful to use that often on all kinds of machines > and look into anything that crops up. But for now, by far the most > effective means of testing is normal stuff using good old crufty ptrace. > > > Thanks, > Roland > Regards - Wu Zhou From roland@redhat.com Mon Jul 17 09:14:00 2006 From: roland@redhat.com (Roland McGrath) Date: Mon, 17 Jul 2006 09:14:00 -0000 Subject: utrace in rawhide In-Reply-To: Wu Zhou's message of Sunday, 16 July 2006 12:24:11 -0400 <20060716122411.engz7yhbggww8wk0@imap.linux.ibm.com> Message-ID: <20060717091436.809D5180063@magilla.sf.frob.com> > Thanks for these information. They explained well why I can't get my > ppc64 box boot up. :-) I had also a test with the yesterday's kernel > build and had no luck yet. One guy named DaveJ said that it might be > the problem of mkinitrd. I hope that it will be fixed soon. Same for me. :-( > Using these kernel, I can boot up x86. But the scripts/mod/modpost > reports a "float point exception" when trying to build crash_suspend.o > into a kernel module. I am trying to use modpost in other kernel > build, but with no luck too. Check dmesg for errors. These are things to report in a kernel bugzilla, not to discuss in detail here. > Good idea. If I find any failure/difference, I will try to reduce > that to a small reproducible testcase. That's very much appreciated. > > The gdb test suite is the most thorough and moderately torturous test of > > ptrace (and by extension, all my new utrace infrastructure code) I know of. > > I've just written up detailed instructions for the folks doing new utrace > > arch support, on setting up and running it, comparing the results, and > > doing all the myriad biarch variations that can be tested. If you get to > > the stage of wanting to run the hard tests and scour painfully for the > > obscure problems, I can send you the same details. > > I would like to. Can you send me these detail? Thanks. I will. > I had a ppc32 machine available. But I am not sure if I can squeeze > some time to run test on it. If time/resource is available, I will > have a test on that. Great. The rawhide ppc kernel should be easy enough to test with, modulo the rawhide kernel being impossible to test with. ;-) Thanks, Roland From cagney@redhat.com Mon Jul 17 17:16:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 17 Jul 2006 17:16:00 -0000 Subject: htdocs added to the <> cvs module Message-ID: <44BBC65F.70001@redhat.com> Just FYI, So as to make everyones life easier, I've added htdocs (the web pages) to the cvs module <>. There's no longer a need for a second check-out. Given that this doesn't affect building, there's no reason to rush and do a new fresh check-out, just keep in mind that the next time you do a clean check-out these files will appear. Andrew From mark@klomp.org Tue Jul 18 14:53:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 18 Jul 2006 14:53:00 -0000 Subject: PTraceByteBuffer vs errno Message-ID: <1153234389.2531.20.camel@elsschot.wildebeest.org> Hi, While investigating some strange RuntimeExceptions (indicating interrupted system calls) coming from PTraceByteBuffer I noticed that it does its own errno handling when calling the Ptrace class. This seems incorrect since Ptrace a) does its own errno handling and will throw the appropriate exception when errno is set and b) Ptrace is not just a simple call, but a complex chaining of calls through multiple threads so the errno value set might not be related at all to the original errno call. So I propose to remove all errno handling from PtraceByteBuffer. This also made my local breakpoint tests become more predictable. 2006-07-18 Mark Wielaard * frysk/sys/cni/PtraceByteBuffer.cxx (newPerror): Removed. (peek(long)): Remove errno handling. (peek(long,jbyteArray,jlong,jlong)): Likewise. (poke): Likewise. Does this look OK? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: PtraceByteBuffer-errno.patch Type: text/x-patch Size: 2851 bytes Desc: not available URL: From qiyao@cn.ibm.com Wed Jul 19 05:19:00 2006 From: qiyao@cn.ibm.com (Yao Qi) Date: Wed, 19 Jul 2006 05:19:00 -0000 Subject: Permission to task and proc Message-ID: <20060719051057.GD28727@GreenHouse.cn.ibm.com> When I write IsaFactory and test it, I get a problem, and I hope your suggestions are helpful for me to resolve this problem. When frysk starts up, it will iterate all the processes and tasks, and initialize objects correspondingly. setupMapsXXX() in LinuxTask will get byteorder via isa(byteorder used to hardwired to little endian), and then get isa via ELF header of /proc//exe. The problem here is frysk do not have the read permission to all the processes and task, even I start frysk as root, still fail to read /proc//exe if is a kernel thread, such as aio. frysk, as a debugger or monitor, should only manipulate and inspect the processes and tasks that it has the permission to. If user want to monitor process or task owned by root, please switch user to root, and start up frysk again. So, the policy to filter process and task, which frysk has not read permission to, is needed. In my working copy, I did it as follows, 1. Add a member boolean permission, and a member function protected abstract void setPermission() to Class Task, 2. Override setPermission in LinuxTask like this, protected void setPermission() { File f = new File("/proc/"+ Integer.toString(id.id) + "/exe"); permission = f.canRead(); } 3. Call setPermission() in constructor of LinuxTask, and then call setupMapsXXX() if permission is true. In this schema, frysk could skip the process or task it has no read permission to, and does not set up maps. Is there any api to check process or task permission in java? I could not find, so I equal permission of /proc//exe to process permission. Any comments? In "Create a Frysk session" when FryskSessionDruid start up, all the processes in "Available Process Groups" box are owned by the currenty user, and process owned by other users are not listed. I read frysk-gui/frysk/gui/druid/CreateFryskSessionDruid.java, but still not know how these processes filtered. Could anybody here clarify it for me? Thanks! -- Yao Qi From mark@klomp.org Wed Jul 19 09:46:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 19 Jul 2006 09:46:00 -0000 Subject: Permission to task and proc In-Reply-To: <20060719051057.GD28727@GreenHouse.cn.ibm.com> References: <20060719051057.GD28727@GreenHouse.cn.ibm.com> Message-ID: <1153302376.2527.2.camel@elsschot.wildebeest.org> On Wed, 2006-07-19 at 13:10 +0800, Yao Qi wrote: > Is there any api to check process or task permission in java? I could > not find, so I equal permission of /proc//exe to process > permission. Seems that is the best you can do. Otherwise you will have to add a 'native' method. But the best I can think of is trying to attach to the thread with ptrace to really know whether or not we can monitor it (ptrace can also fail when another process is already ptracing it). Cheers, Mark From mark@klomp.org Wed Jul 19 12:31:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 19 Jul 2006 12:31:00 -0000 Subject: First try of breakpoint support Message-ID: <1153312272.2527.34.camel@elsschot.wildebeest.org> Hi, Here is a first try of adding breakpointing support. It works for the attached 3 testcases which simply test that a process can be stopped, Code observers can be added (and removed) and the updateHit() method is called whenever the process hits the breakpoint address the Code Observer is interested in. It isn't integrated with the state machine yet. Which means it contains some small hacks to force the Task into the right State at times. Adding Code Observers is currently only supported in a Blocked state and removing them only in the Running state. See the various XXX comments in the patch. This also means there is no support yet for returning BLOCK from Code.updateHit(). Even though it is clearly not finished I wanted to post what I have to get some feedback. The idea is as follows: - A Proc will have a new field that holds the BreakpointAddresses. (breakpoints are shared between all Tasks of a Proc) - BreakpointAddresses keep track of the actual Code Observers interested in an breakpoint address and request to Proc to add or remove them when necessary. - A Breakpoint holds some state necessary for resetting, stepping and continuing. When you create a Breakpoint for a task on an address that is already installed you will get that instance back so it is easy to reset, step or continue it. Currently interaction between the Task/Proc is not based on the TaskState, but it obviously should. For now the process is forced to stop when necessary. This should be handled by the state machine. - There is only support for LinuxIa32 simple INT3 breakpoints for now. But it should be easy to create subclasses for other architectures. (With a little luck I will get my hands on a x86-64/em64t style machine this week and will try adding support for that then.) Currently the stepping/continuing isn't thread/Task-safe. If there is another Task running while resetting the LinuxIa32Breakpoint it might miss hitting it temporarily. Here are the ChangeLog entries: 2006-07-19 Mark Wielaard * frysk/proc/Breakpoint.java: New file. * frysk/proc/BreakpointAddresses.java: New file. * frysk/proc/DummyProc.java (removeBreakpoint): Dummy implementation. (addBreakpoint): Likewise. * frysk/proc/LinuxIa32Breakpoint.java: New file. * frysk/proc/LinuxProc.java (removeBreakpoint): New method. (addBreakpoint): New method. * frysk/proc/Proc.java (breakpoints): New field. (Proc(ProcId,Proc,Host,Task): Initialize breakpoints. (requestUpdateBreakpoints): New method. (addBreakpoint): New method. (removeBreakpoint): New method. * frysk/proc/Task.java (codeObservers): New field. (requestAddCodeObserver): New method. (requestDeleteCodeObserver): New method. (notifyCodeBreakpoint): New method. * frysk/proc/TaskObserver.java (updateHit): Update description. * frysk/proc/TaskState.java (running.handleTrappedEvent): New Method. * frysk/proc/TestBreakpoints.java: New test. 2006-07-19 Mark Wielaard * funit-breakpoints.c: New file. The testcase depends on the the ForkedProcess support I suggested: http://sourceware.org/ml/frysk/2006-q3/msg00065.html Let me know if that is a good idea to add. Otherwise I can rewrite my testcases of course. But I rather don't :) When running by hand they always PASS: $ ./TestRunner frysk.proc.TestBreakpoints Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS Running testAddLots(frysk.proc.TestBreakpoints) ...PASS Time: 1.057 OK (3 tests) But that depends on the PtraceByteBuffer vs errno patch that I suggested: http://sourceware.org/ml/frysk/2006-q3/msg00077.html Otherwise you will get some spurious interrupted system call RuntimeExceptions. When run with 'make check' they intermittently fail. I haven't tracked this down yet. But it might very well be because of timing and my failure to properly integrate this yet with the rest of the state machine. This is my next task. Comments and suggestions welcome. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: breakpoints-first.patch Type: text/x-patch Size: 43591 bytes Desc: not available URL: From pmuldoon@redhat.com Wed Jul 19 15:10:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 19 Jul 2006 15:10:00 -0000 Subject: Permission to task and proc In-Reply-To: <20060719051057.GD28727@GreenHouse.cn.ibm.com> References: <20060719051057.GD28727@GreenHouse.cn.ibm.com> Message-ID: <44BE4B71.3080806@redhat.com> > > In "Create a Frysk session" when FryskSessionDruid start up, all the > processes in "Available Process Groups" box are owned by the currenty user, > and process owned by other users are not listed. I read > frysk-gui/frysk/gui/druid/CreateFryskSessionDruid.java, but still not > know how these processes filtered. Could anybody here clarify it for > me? > > They basically use Proc.getUID() and Proc.getGID() and match it against the current users. Those apis are just a reflection of the /proc/$$/status UID and GID. I wrote this, but as I have to read status which has some supplemental information that stat does not, it was supposed to be a stop-gap measure. I don't know of a syscall to do the same thing. :( It's demand only read too (ie the status file only gets read on getUID/getGID not on refresh, so one must be careful of that). Regards Phil From swagiaal@redhat.com Wed Jul 19 15:55:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Wed, 19 Jul 2006 15:55:00 -0000 Subject: Permission to task and proc In-Reply-To: <20060719051057.GD28727@GreenHouse.cn.ibm.com> References: <20060719051057.GD28727@GreenHouse.cn.ibm.com> Message-ID: <44BE55F8.6010007@redhat.com> > In "Create a Frysk session" when FryskSessionDruid start up, all the > processes in "Available Process Groups" box are owned by the currenty user, > and process owned by other users are not listed. I read > frysk-gui/frysk/gui/druid/CreateFryskSessionDruid.java, but still not > know how these processes filtered. Could anybody here clarify it for > me? You should take a look at GuiProc.java. There is a function there called isOwned which does the filtering you described. There are a lot of data models using this function to do filtering. So you can search of references to isOwned. As for filtering at a lower level in the core. I think that a user should still be able to see a process that they do not own. This way they know to switch user or run as root to be able to debug that process. But if no one agrees then I am not against filtering in the core. From npremji@redhat.com Wed Jul 19 20:03:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Wed, 19 Jul 2006 20:03:00 -0000 Subject: EventViewer and time. Message-ID: <1153339379.27701.30.camel@to-rhaps5.toronto.redhat.com> I've been thinking about how the eventviewer represents events and I think in terms of a time-line it does this too realistically. What I mean by this is that if there is 10 seconds of time between event "a" and event "b", and 5 seconds of time between event "b" and event "c", then we will see event "a", a large gap, event "b", a smaller gap, event "c". This seems natural, however when debugging for the most part we don't really care how much time is between each pair of events, we just want to know that event "a" happened, then event "b" then event "c". (or "c" then "b" and we see the race condition that we were looking for for example.) So is anybody really set on having realistic time differences between events or can I start switching it over to have a set amount of space between each event. I don't want events to overlap, so if an event happens then each trace will move forward one space to decide where to put an event. So previously if thread A forked, then waited 10 seconds, then thread B cloned, wait 5 seconds, and thread A exited we would see: Thread A -------[]-------------* Thread B--------------------()--- I propose: Thread A -----[]-----------* Thread B -----------()----- Any thoughts? From swagiaal@redhat.com Wed Jul 19 20:37:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Wed, 19 Jul 2006 20:37:00 -0000 Subject: EventViewer and time. In-Reply-To: <1153339379.27701.30.camel@to-rhaps5.toronto.redhat.com> References: <1153339379.27701.30.camel@to-rhaps5.toronto.redhat.com> Message-ID: <44BE9815.1090500@redhat.com> Nurdin Premji wrote: > I've been thinking about how the eventviewer represents events and I > think in terms of a time-line it does this too realistically. What I > mean by this is that if there is 10 seconds of time between event "a" > and event "b", and 5 seconds of time between event "b" and event "c", > then we will see event "a", a large gap, event "b", a smaller gap, event > "c". > > This seems natural, however when debugging for the most part we don't > really care how much time is between each pair of events, we just want > to know that event "a" happened, then event "b" then event "c". (or "c" > then "b" and we see the race condition that we were looking for for > example.) > Wow... I would like to state that I have in no way influenced Nurdin :) > So is anybody really set on having realistic time differences between > events or can I start switching it over to have a set amount of space > between each event. I don't want events to overlap, so if an event > happens then each trace will move forward one space to decide where to > put an event. > > So previously if thread A forked, then waited 10 seconds, then thread B > cloned, wait 5 seconds, and thread A exited we would see: > > Thread A -------[]-------------* > Thread B--------------------()--- > > I propose: > > Thread A -----[]-----------* > Thread B -----------()----- > > Any thoughts? > My only observation is that you have to be careful to reserve the order of the events Ie. events appear in the order 1,2,3 no matter what thread they occurred on Thread A -----1----------3 Thread B -----------2----- I will try to send you a pointer to the thread where this was previously dicussed From swagiaal@redhat.com Wed Jul 19 20:41:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Wed, 19 Jul 2006 20:41:00 -0000 Subject: [Fwd: Re: Timeline widget] Message-ID: <44BE98ED.5000302@redhat.com> -------------- next part -------------- An embedded message was scrubbed... From: Sami Wagiaalla Subject: Re: Timeline widget Date: Tue, 04 Apr 2006 16:50:04 -0400 Size: 4994 URL: From cmoller@redhat.com Thu Jul 20 00:42:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 20 Jul 2006 00:42:00 -0000 Subject: EventViewer and time. In-Reply-To: <1153339379.27701.30.camel@to-rhaps5.toronto.redhat.com> References: <1153339379.27701.30.camel@to-rhaps5.toronto.redhat.com> Message-ID: <44BED17F.3090209@redhat.com> Events are stored per trace in the viewer, i.e., every trace structure contains a pointer to an array containing the events associated with that trace. Within each event array, the events are chronologically monotonic, but there's no correlation between different event arrays. What this means is that for Trace A, for example, you could have: 1. 1 sec eventA 2. 1.1 sec eventB 3. 30 sec eventC It's easy enough to plot those events at uniform sequential intervals: A B C but if Trace B has an eventD at 15 seconds, the result is A B C D i.e., you'll have to resequence Trace A to include a gap in which to put EventD on Trace B. The implication of all this is that you'll have to either recompute the global sequence every time you expose, or maintain a global chronologically monotonic event index, or some such thing. (Maybe something involving concurrent scans of all the event arrays...?) Another potential complication is that I'd left the potential to have the event timestamp accompany the event when it's stored. The current method--having the viewer generate and attach the timestamp internally--is fine as long as all the events being recorded are being generated on the same machine frysk is running on, but I seem to recall (at least I designed for the possibility) that a single frysk instance on one machine could monitor (by means TBD) events that occur remotely on other machines. If that indeed is ever actually implemented, the remote machines will have to generate its own per-event timestamps. Failing to do that will introduce unpredictably inconsistent transmission delays, potentially violating monotonicity (i.e., if it takes Machine B longer to transmit a record of the occurrence of EventA than it takes to transmit EventB and frysk generates the timestamps when it receives the events, it could appear that EventB occurred before EventA). The only way to make sure this doesn't happen is if Machine B generates its own timestamps and frysk records them rather than generating its own. (With the current method of storing events, the events need not be stored with chronological monotonicity--each event contains its own timestamp and is thus independent of every other event.) Chris Nurdin Premji mumbled something on 07/19/06 16:02: > I've been thinking about how the eventviewer represents events and I > think in terms of a time-line it does this too realistically. What I > mean by this is that if there is 10 seconds of time between event "a" > and event "b", and 5 seconds of time between event "b" and event "c", > then we will see event "a", a large gap, event "b", a smaller gap, event > "c". > > This seems natural, however when debugging for the most part we don't > really care how much time is between each pair of events, we just want > to know that event "a" happened, then event "b" then event "c". (or "c" > then "b" and we see the race condition that we were looking for for > example.) > > So is anybody really set on having realistic time differences between > events or can I start switching it over to have a set amount of space > between each event. I don't want events to overlap, so if an event > happens then each trace will move forward one space to decide where to > put an event. > > So previously if thread A forked, then waited 10 seconds, then thread B > cloned, wait 5 seconds, and thread A exited we would see: > > Thread A -------[]-------------* > Thread B--------------------()--- > > I propose: > > Thread A -----[]-----------* > Thread B -----------()----- > > Any thoughts? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cmoller@redhat.com Thu Jul 20 02:25:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 20 Jul 2006 02:25:00 -0000 Subject: EventViewer and time. In-Reply-To: <44BED17F.3090209@redhat.com> References: <1153339379.27701.30.camel@to-rhaps5.toronto.redhat.com> <44BED17F.3090209@redhat.com> Message-ID: <44BEE975.4070404@redhat.com> I just remembered another couple of considerations while I was in the shower just now: (I've always done my best thinking in the shower--I just wish my keyboards were waterproof.) First is that traces don't /have/ to represent threads, procs, or whatever. It's easily possible, and probably useful, to do something like have one trace represent clone events, another trace term events, and so on. On a single-processor machine, there's no way to have truly simultaneous events, but on an MP machine, it would be easy to have, e.g., simultaneous clone events on separate threads running on different processors. Under these circumstances, using the unit-interval approach, it would be possible have a requirement to show two events in the same time slot. Another issue is that the way the tooltip popups work is that they map the position of the pointer on the screen to a time (which was originally, of course, used to map to a screen position to display the event--a reversible transformation.) The unit-interval approach is not reversible, at least not linearly or simply, so using it would break tooltips, at least without a fair amount of work. (This, by the way, could be an issue--the popup code has to be fairly fast.) Sorry if I'm sounding thoroughly negative about all this, but these complications are why I never got around to implementing unit-interval. One thing I did consider was trying to use a reversible non-linear mapping. At the moment, the mapping from an event time to a screen x-position is a simple linear one: x = at + b, where a and b are functions of the interval and offset slider values. Nothing says that the mapping has to be that simple. Take a look at the attached image (assuming that sources.redhat.com will accept attachments). Given a hypothetical situation where you have a two widely separated clusters of points that would normally be mapped at widely separated places in the viewer, using a non-linear mapping as shown would increase the interval between the clustered points and decrease the interval between the clusters. The only requirement is that the transformation be continuous and strictly monotonic, and would therefore be unambigously reversible. It probably wouldn't be terribly difficult to compute such transformation on the fly to optimise the display of the data you have and still maintain reversibility, thereby keeping tooltips from breaking. Chris (Okay, I'll stop rambling now...) Chris Moller mumbled something on 07/19/06 20:42: > Events are stored per trace in the viewer, i.e., every trace structure > contains a pointer to an array containing the events associated with > that trace. Within each event array, the events are chronologically > monotonic, but there's no correlation between different event arrays. > What this means is that for Trace A, for example, you could have: > > 1. 1 sec eventA > 2. 1.1 sec eventB > 3. 30 sec eventC > > It's easy enough to plot those events at uniform sequential intervals: > > A B C > > but if Trace B has an eventD at 15 seconds, the result is > > A B C > D > > i.e., you'll have to resequence Trace A to include a gap in which to put > EventD on Trace B. The implication of all this is that you'll have to > either recompute the global sequence every time you expose, or maintain > a global chronologically monotonic event index, or some such thing. > (Maybe something involving concurrent scans of all the event arrays...?) > > Another potential complication is that I'd left the potential to have > the event timestamp accompany the event when it's stored. The current > method--having the viewer generate and attach the timestamp > internally--is fine as long as all the events being recorded are being > generated on the same machine frysk is running on, but I seem to recall > (at least I designed for the possibility) that a single frysk instance > on one machine could monitor (by means TBD) events that occur remotely > on other machines. If that indeed is ever actually implemented, the > remote machines will have to generate its own per-event timestamps. > Failing to do that will introduce unpredictably inconsistent > transmission delays, potentially violating monotonicity (i.e., if it > takes Machine B longer to transmit a record of the occurrence of EventA > than it takes to transmit EventB and frysk generates the timestamps when > it receives the events, it could appear that EventB occurred before > EventA). The only way to make sure this doesn't happen is if Machine B > generates its own timestamps and frysk records them rather than > generating its own. (With the current method of storing events, the > events need not be stored with chronological monotonicity--each event > contains its own timestamp and is thus independent of every other event.) > > Chris > > Nurdin Premji mumbled something on 07/19/06 16:02: > >> I've been thinking about how the eventviewer represents events and I >> think in terms of a time-line it does this too realistically. What I >> mean by this is that if there is 10 seconds of time between event "a" >> and event "b", and 5 seconds of time between event "b" and event "c", >> then we will see event "a", a large gap, event "b", a smaller gap, event >> "c". >> >> This seems natural, however when debugging for the most part we don't >> really care how much time is between each pair of events, we just want >> to know that event "a" happened, then event "b" then event "c". (or "c" >> then "b" and we see the race condition that we were looking for for >> example.) >> >> So is anybody really set on having realistic time differences between >> events or can I start switching it over to have a set amount of space >> between each event. I don't want events to overlap, so if an event >> happens then each trace will move forward one space to decide where to >> put an event. >> >> So previously if thread A forked, then waited 10 seconds, then thread B >> cloned, wait 5 seconds, and thread A exited we would see: >> >> Thread A -------[]-------------* >> Thread B--------------------()--- >> >> I propose: >> >> Thread A -----[]-----------* >> Thread B -----------()----- >> >> Any thoughts? >> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: mapping.png Type: image/png Size: 4122 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From swagiaal@redhat.com Thu Jul 20 14:18:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Thu, 20 Jul 2006 14:18:00 -0000 Subject: EventViewer and time. In-Reply-To: <44BEE975.4070404@redhat.com> References: <1153339379.27701.30.camel@to-rhaps5.toronto.redhat.com> <44BED17F.3090209@redhat.com> <44BEE975.4070404@redhat.com> Message-ID: <44BF90B3.9040503@redhat.com> Well the model I usually use to resolve issues with the interval based implementation is printf debugging. "How does printf solve this issue ?" So one thing that we could do is when a trace arrives at one trace all the traces are step one interval. All are blank but only the concerned trace gets the event. This resolves some of the issues you stated (wherever time can be replaced by this index at least). As for parallel events (multi cpu, multi host, etc), printf eventually forces an oder that is probably arbitrary. We could do the same. The truth is any assignment of time to an event is very likely to be inaccurate. The same goes for simultaneous events. If we present them as simultaneous, do we really know that for sure ? One thing that Cagney has suggested in the past is to have buckets in the timeline corresponding to iterations of the core event loop. ie every time the event loop makes a loop it provides a tick. This makes sense because that is the lowest resolution that we can actually guarantee. From zcerza@redhat.com Thu Jul 20 15:37:00 2006 From: zcerza@redhat.com (Zack Cerza) Date: Thu, 20 Jul 2006 15:37:00 -0000 Subject: About dogtail on x86 and ppc64 In-Reply-To: <17588.62608.340741.20235@localhost.redhat.com> References: <20060711214345.uxbwxsve8soog80s@imap.linux.ibm.com> <17588.62608.340741.20235@localhost.redhat.com> Message-ID: <44BFA311.2060203@redhat.com> Elena Zannoni wrote: > Wu, thanks for starting looking at this. Len is using dogtail > successfully on x86 for testing of Frysk, so I suspect something in > your setup. On ppc64, Len was going to try it today, but since that > platform is more of an unknown, I am cc-ing Zack directly as well. But > in general I think Len can offer you some pointers on how to set > things up. > > elena > > > Wu Zhou writes: > > Hello all, > > > > We can setup dogtail on x86 and ppc64 as well. > > > > On both platform, we run "python ./gedit-test-utf8-procedural-api.py". > > > > Here is the results: > > > > On x86: > > ======== > > # python ./gedit-test-utf8-procedural-api.py > > Creating logfile at > > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-093635 ... > > Detecting distribution: Red Hat/Fedora/derived distribution > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > GTK Accessibility Module initialized > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > Bonobo accessibility support initialized > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > I haven't seen those warnings so soon in a script. Can you tell me if the 'sniff' utility works? > > /tmp/dogtail/screenshot_20060712-093640.png > > Screenshot taken: /tmp/dogtail/screenshot_20060712-093640.png > > click on {child with name="Save" ("?$A4f(B(S)", "$A1#4f(B(S)", "$A1#4f(B", "?$A4f(B", )} > The above line doesn't look right at all. Can you paste the output of the 'locale' command? I'm guessing your locale is breaking dogtail's automatic runtime translation. > > Traceback (most recent call last): > > File "./gedit-test-utf8-procedural-api.py", line 56, in ? > > focus.dialog(u'Save As\u2026') > > File "/usr/lib/python2.4/site-packages/dogtail/procedural.py", line > > 78, in __call__ > > result = FocusApplication.node.findChild(predicate, > > requireResult=False, recursive = False) > > File "/usr/lib/python2.4/site-packages/dogtail/tree.py", line 769, > > in findChild > > result.debugName = pred.describeSearchResult() > > File "/usr/lib/python2.4/site-packages/dogtail/predicate.py", line > > 235, in describeSearchResult > > return '%s dialog'%self.dialogName > > File "/usr/lib/python2.4/site-packages/dogtail/i18n.py", line 144, > > in __str__ > > result = '"%s" (%s)' % (self.untranslatedString, translations) > > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position > > 8: ordinal not in range(128) > The above traceback is due to the fact that the runtime translation isn't working properly. > > On ppc64: > > ======== > > # python ./gedit-test-utf8-procedural-api.py > > Creating logfile at > > /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-133632 ... > > Detecting distribution: Red Hat/Fedora/derived distribution > > /tmp/dogtail/screenshot_20060712-133637.png > > Screenshot taken: /tmp/dogtail/screenshot_20060712-133637.png > > click on {child with name="Save"} > > activate on {child with name="Browse for other folders"} > > activate on {child with name="Desktop" roleName='table cell'} > > click on {child with name="Save"} > > click on {child with name="Quit"} > > > > ** (process:26377): WARNING **: Failed to send buffer > > > > ** (process:26377): WARNING **: Failed to send buffer > > > > ** (process:26377): WARNING **: Failed to send buffer > > > > ** (process:26377): WARNING **: Failed to send buffer > > ...... > > ** (process:26377): WARNING **: Failed to send buffer > The above warning messages are pretty benign, considering the script has already run to completion. If you ever see them in the middle of a script, I'd be worried. > > The difference I noticed is: > > > > 1. There are some warning messages there in ppc64 complaining that > > failed to send buffer > The messages appear on all architectures, just not all the time. > > 2. the gedit session quited on ppc64, don't on x86 > > I guess it work correctly on ppc64, not on x86. > It looks like the difference here is probably your locale. On ppc64 you were using some form of en_US or en_GB, correct? > > 3. on x86, it complained with some warning message: > > Warning: AT-SPI error: pre method check: add: Unknown CORBA exception > > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' I've seen those messages before (but never where you saw them) and they're generally not a good sign. The first step is telling me what locale you were using, so I can try to reproduce. > > I want to get some suggestion from you, what we need to do to test > > dogtail seriously? Thanks a lot Hopefully we can get these problems solved, so you can get some good testing done :) Zack From mark@klomp.org Fri Jul 21 11:18:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 21 Jul 2006 11:18:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <20060720155840.24856.qmail@sourceware.org> References: <20060720155840.24856.qmail@sourceware.org> Message-ID: <1153480682.22872.9.camel@elsschot.wildebeest.org> Hi Tim, On Thu, 2006-07-20 at 15:58 +0000, moore@sourceware.org wrote: > Throw a TaskException from some methods in Task. This is not a > RuntimeException, so fix all the affected callers too. I like it. Now I actually have to look and think what to do in some nasty cases where the Task can actually have "disappeared". Now scratching my head how to improve my code to better handle some things. Good stuff. One question. Why is the Exception a non-static inner class of Task? This means it does have a reference to its enclosing Task (which most likely is the Task that is in trouble), but it isn't easy to get access to it. And on the other hand you probably know very well which Task it is about because that is the Task you were just manipulating. Would it make sense to make this either static or a "stand-alone" Exception class? (/me is a bit biased against inner classes since the scoping and whether or not they have outer context are always so confusing). Cheers, Mark From mark@klomp.org Fri Jul 21 11:40:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 21 Jul 2006 11:40:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <1153480682.22872.9.camel@elsschot.wildebeest.org> References: <20060720155840.24856.qmail@sourceware.org> <1153480682.22872.9.camel@elsschot.wildebeest.org> Message-ID: <1153482017.22872.13.camel@elsschot.wildebeest.org> On Fri, 2006-07-21 at 13:18 +0200, Mark Wielaard wrote: > Hi Tim, > > On Thu, 2006-07-20 at 15:58 +0000, moore@sourceware.org wrote: > > Throw a TaskException from some methods in Task. This is not a > > RuntimeException, so fix all the affected callers too. > > I like it. Now I actually have to look and think what to do in some > nasty cases where the Task can actually have "disappeared". Now > scratching my head how to improve my code to better handle some things. > Good stuff. Another question. Should the Register getters and setters also throw TaskException? Currently only the requesting of the Isa of a Task can trigger it, but it seems any use of it can also get you in trouble if the underlying ByteBuffer for the register banks throws a fit. Cheers, Mark From cagney@redhat.com Sat Jul 22 13:25:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sat, 22 Jul 2006 13:25:00 -0000 Subject: test results Message-ID: <44C227AA.8010601@redhat.com> FYI, I've just been through all the tests marking up as broken (and creating bug reports) for all that fail. Remember, at all times all tests should be passing, so seeing a failing test is cause for immediate panic. Please don't ignore test failures, they make it a mess for everyone. Andrew From mark@klomp.org Sat Jul 22 15:47:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Sat, 22 Jul 2006 15:47:00 -0000 Subject: test results In-Reply-To: <44C227AA.8010601@redhat.com> References: <44C227AA.8010601@redhat.com> Message-ID: <1153583226.2812.45.camel@hermans.wildebeest.org> Hi Andrew, On Sat, 2006-07-22 at 09:27 -0400, Andrew Cagney wrote: > I've just been through all the tests marking up as broken (and creating > bug reports) for all that fail. Remember, at all times all tests should > be passing, so seeing a failing test is cause for immediate panic. > Please don't ignore test failures, they make it a mess for everyone. Thanks for the reminder. I replicated all the remaining failures I was seeing on a clean frysk cvs build with Fedora Core 5 plus upgrades (kernel 2.6.17-1.2145_FC5) and attached TestRunner -c FINE logs to the bug reports. All marked brokenXXX() now: - TestTaskObserverDetach.detachClone -> 2744 - StressAttachDetachRapidlyCloningMainTask.test -> 2956 - StressAttachDetachRapidlyManyTasks.test -> 2468 Cheers, Mark From cagney@redhat.com Sun Jul 23 00:14:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sun, 23 Jul 2006 00:14:00 -0000 Subject: reply-to set on frysk-cvs e-mail Message-ID: <44C2BFB8.3000800@redhat.com> Just FYI, CGF's updated the sourceware config so that Reply-to: frysk@sources.redhat.com is set on frysk-cvs e-mail - make it easier when replying to a cvs commit. Andrew From woodzltc@cn.ibm.com Sun Jul 23 11:51:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sun, 23 Jul 2006 11:51:00 -0000 Subject: About dogtail on x86 and ppc64 Message-ID: <20060723075058.ghehsdd8u0wo4kkg@imap.linux.ibm.com> Hi Zack, Thanks for your reply. See below for the answers. >> Wu Zhou writes: >> > Hello all, >> > > We can setup dogtail on x86 and ppc64 as well. >> > > On both platform, we run "python ./gedit-test-utf8-procedural-api.py". >> > > Here is the results: >> > > On x86: >> > ======== >> > # python ./gedit-test-utf8-procedural-api.py >> > Creating logfile at > >> /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-093635 ... >> > Detecting distribution: Red Hat/Fedora/derived distribution >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA >> exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > GTK Accessibility Module initialized >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA >> exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > Bonobo accessibility support initialized >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA >> exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA >> exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA >> exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' >> > > I haven't seen those warnings so soon in a script. Can you tell me if > the 'sniff' utility works? Ys. The sniff utility did worked. It can list a tree with the root being "main" and also some sub-nodes, such as gnome-panel, gnome-terminal. >> > /tmp/dogtail/screenshot_20060712-093640.png >> > Screenshot taken: /tmp/dogtail/screenshot_20060712-093640.png >> > click on {child with name="Save" ("?$A4f(B(S)", >> "$A1#4f(B(S)", "$A1#4f(B", "?$A4f(B", )} > The above line doesn't look right at all. Can you paste the output of > the 'locale' command? I'm guessing your locale is breaking dogtail's > automatic runtime translation. the locale output is like this: LANG=zh_CN.UTF-8 LC_CTYPE="zh_CN.UTF-8" LC_NUMERIC="zh_CN.UTF-8" LC_TIME="zh_CN.UTF-8" LC_COLLATE="zh_CN.UTF-8" LC_MONETARY="zh_CN.UTF-8" LC_MESSAGES="zh_CN.UTF-8" LC_PAPER="zh_CN.UTF-8" LC_NAME="zh_CN.UTF-8" LC_ADDRESS="zh_CN.UTF-8" LC_TELEPHONE="zh_CN.UTF-8" LC_MEASUREMENT="zh_CN.UTF-8" LC_IDENTIFICATION="zh_CN.UTF-8" LC_ALL= >> > Traceback (most recent call last): >> > File "./gedit-test-utf8-procedural-api.py", line 56, in ? >> > focus.dialog(u'Save As\u2026') >> > File "/usr/lib/python2.4/site-packages/dogtail/procedural.py", >> line > 78, in __call__ >> > result = FocusApplication.node.findChild(predicate, > >> requireResult=False, recursive = False) >> > File "/usr/lib/python2.4/site-packages/dogtail/tree.py", line >> 769, > in findChild >> > result.debugName = pred.describeSearchResult() >> > File "/usr/lib/python2.4/site-packages/dogtail/predicate.py", >> line > 235, in describeSearchResult >> > return '%s dialog'%self.dialogName >> > File "/usr/lib/python2.4/site-packages/dogtail/i18n.py", line >> 144, > in __str__ >> > result = '"%s" (%s)' % (self.untranslatedString, translations) >> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in >> position > 8: ordinal not in range(128) > The above traceback is due to the fact that the runtime translation > isn't working properly. Sorry, what kind of runtime translation did you mean here? the translation from english to the language setup in the locale, or anything else? >> > On ppc64: >> > ======== >> > # python ./gedit-test-utf8-procedural-api.py >> > Creating logfile at > >> /tmp/dogtail/logs/gedit-test-utf8-procedural-api_20060712-133632 ... >> > Detecting distribution: Red Hat/Fedora/derived distribution >> > /tmp/dogtail/screenshot_20060712-133637.png >> > Screenshot taken: /tmp/dogtail/screenshot_20060712-133637.png >> > click on {child with name="Save"} >> > activate on {child with name="Browse for other folders"} >> > activate on {child with name="Desktop" roleName='table cell'} >> > click on {child with name="Save"} >> > click on {child with name="Quit"} >> > > ** (process:26377): WARNING **: Failed to send buffer >> > > ** (process:26377): WARNING **: Failed to send buffer >> > > ** (process:26377): WARNING **: Failed to send buffer >> > > ** (process:26377): WARNING **: Failed to send buffer >> > ...... >> > ** (process:26377): WARNING **: Failed to send buffer > The above warning messages are pretty benign, considering the script > has already run to completion. If you ever see them in the middle of a > script, I'd be worried. That is ok. I will ignore them then. So dogtail seems to be largely ok on ppc64, only if the environment be set up correctly. But sometimes I just don't know what is the correct way to set up dogtail environment. Is there any documents about that? >> > The difference I noticed is: >> > > 1. There are some warning messages there in ppc64 >> complaining that > failed to send buffer >> > The messages appear on all architectures, just not all the time. Although it is harmless. I am still curious about what cause this warning message? >> > 2. the gedit session quited on ppc64, don't on x86 >> > I guess it work correctly on ppc64, not on x86. > It looks like the difference here is probably your locale. On ppc64 you > were using some form of en_US or en_GB, correct? Yes. This is the locale on ppc64: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= >> > 3. on x86, it complained with some warning message: >> > Warning: AT-SPI error: pre method check: add: Unknown CORBA >> exception > id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' > I've seen those messages before (but never where you saw them) and > they're generally not a good sign. The first step is telling me what > locale you were using, so I can try to reproduce. I am not very sure if this is related to locale setting. But after I re-install a FC5 and do a "yum update" and "yum install dogtail", this problem disappeared. So I guess this is related to some setup in the environment. But I am not sure which part is relevant here. Regards - Wu Zhou From woodzltc@cn.ibm.com Sun Jul 23 15:39:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sun, 23 Jul 2006 15:39:00 -0000 Subject: About the porting of libunwind Message-ID: <20060723113950.hsx69q31ookg4wc0@imap.linux.ibm.com> Hello all, We are looking into how to port libunwind to ppc64. We had done some investigation work. It seems much like what is available on x86 and x86-64. So we want to see if any of you can give us some pointers on how to do that on a new platform like ppc64. If you can share us with how you do that (it is ok to be very general ) on x86 and x86-64, that will be highly appreciated. As far as I read the code on x86, libunwind is using getcontext in glibc to get the context for unwinding. And it also need to use dwarf CFI information to know how to unwind the stack step by step. So good understanding about these two topics will be very helpful for libunwind porting. Any directions on these kind of high-level topic? There are also some nasty details too. For example, the user context and dwarf CFI are both complex data structure. Both of them have some important information about the registers. The context contain the value of each registers at some point. And the CFI tells how to save and restore registers when one function call another. How to get these register values? How are these registers ordered? The numbering sequence? How to map the register in context structure to these in CFI information? All these should be in the questions to be answered. How do you do all these for x86 and x86_64? In fact, any information about how do you port libunwind to x86/x86_64 intests me. All are welcomed! Regards - Wu Zhou From rth@redhat.com Tue Jul 25 15:48:00 2006 From: rth@redhat.com (Richard Henderson) Date: Tue, 25 Jul 2006 15:48:00 -0000 Subject: About the porting of libunwind In-Reply-To: <20060723113950.hsx69q31ookg4wc0@imap.linux.ibm.com> References: <20060723113950.hsx69q31ookg4wc0@imap.linux.ibm.com> Message-ID: <20060725154840.GA16361@redhat.com> On Sun, Jul 23, 2006 at 11:39:50AM -0400, Wu Zhou wrote: > We are looking into how to port libunwind to ppc64. We had done some > investigation work. It seems much like what is available on x86 and > x86-64. So we want to see if any of you can give us some pointers on > how to do that on a new platform like ppc64. If you can share us with > how you do that (it is ok to be very general ) on x86 and x86-64, that > will be highly appreciated. I've been working on doing just this thing, porting to ppc32/64. Unfortunately, libunwind is very poorly arranged for such cases, where two ports can share the bulk of the code. So I've been rearranging it. What I have is currently in an intermediate state that does not compile, but as soon as I have something, I will check it in to the frysk repository. > There are also some nasty details too. For example, the user context > and dwarf CFI are both complex data structure. Both of them have some > important information about the registers. The context contain the > value of each registers at some point. And the CFI tells how to save > and restore registers when one function call another. How to get these > register values? How are these registers ordered? The numbering > sequence? How to map the register in context structure to these in > CFI information? All these should be in the questions to be answered. > How do you do all these for x86 and x86_64? What is needed here is familiarity with the dwarf3 spec, and the ELF spec for ppc64. There is existing code in gcc to perform the same operations, but only within the local process. But it is still helpful for understanding. r~ From woodzltc@cn.ibm.com Wed Jul 26 04:21:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 26 Jul 2006 04:21:00 -0000 Subject: About the porting of libunwind Message-ID: <20060726002113.a0rmfyd5usogss8k@imap.linux.ibm.com> Quoting Richard Henderson : > On Sun, Jul 23, 2006 at 11:39:50AM -0400, Wu Zhou wrote: >> We are looking into how to port libunwind to ppc64. We had done some >> investigation work. It seems much like what is available on x86 and >> x86-64. So we want to see if any of you can give us some pointers on >> how to do that on a new platform like ppc64. If you can share us with >> how you do that (it is ok to be very general ) on x86 and x86-64, that >> will be highly appreciated. > > I've been working on doing just this thing, porting to ppc32/64. Richard, Very happy to know that you are working on this. Whatever I can help in this effort, please tell me. Surely we can help test your code on various platforms, including but not limited to ppc32/ppc64 platforms. :-) > Unfortunately, libunwind is very poorly arranged for such cases, > where two ports can share the bulk of the code. So I've been > rearranging it. What I have is currently in an intermediate > state that does not compile, but as soon as I have something, I > will check it in to the frysk repository. Would you please talk something about your re-arrangement work? What changes are you planning to add into the current code base? Do you think that I can be of some help in your re-arranging work? >> There are also some nasty details too. For example, the user context >> and dwarf CFI are both complex data structure. Both of them have some >> important information about the registers. The context contain the >> value of each registers at some point. And the CFI tells how to save >> and restore registers when one function call another. How to get these >> register values? How are these registers ordered? The numbering >> sequence? How to map the register in context structure to these in >> CFI information? All these should be in the questions to be answered. >> How do you do all these for x86 and x86_64? > > What is needed here is familiarity with the dwarf3 spec, and the > ELF spec for ppc64. There is existing code in gcc to perform the > same operations, but only within the local process. But it is > still helpful for understanding. Thanks for these information. I ever had some experiences in DWARF and ELF. and I am also looking at these documents right now to refresh them. But I am not that familar with gcc code (ever submitted one patch for generating better debuginfo support for Fortran main entry, don't got much feedback though. :-( ). Can you give me some pointer on which files are involved in performing these operations? The source file names are ok. Thanks a lot! Regards - Wu Zhou From qiyaoltc@cn.ibm.com Wed Jul 26 07:05:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 26 Jul 2006 07:05:00 -0000 Subject: Permission to task and proc In-Reply-To: <44BE55F8.6010007@redhat.com> References: <20060719051057.GD28727@GreenHouse.cn.ibm.com> <44BE55F8.6010007@redhat.com> Message-ID: <20060726065641.GA8035@GreenHouse.cn.ibm.com> On Wed, Jul 19, 2006 at 11:55:36AM -0400, Sami Wagiaalla wrote: > > You should take a look at GuiProc.java. There is a function there called > isOwned > which does the filtering you described. There are a lot of data models > using this function > to do filtering. So you can search of references to isOwned. > Hi, Sami, Thanks for your information. I could locate isOwned() in GuiProc.java. > As for filtering at a lower level in the core. I think that a user > should still be able > to see a process that they do not own. This way they know to switch user or > run as root to be able to debug that process. But if no one agrees then > I am not > against filtering in the core. When I try to filter processes via getUID()/getGID(), I meet another problem, that frysk-core still could not open /proc//exe, when frysk-core has the same GID with this process. Here is the detailed information for your reference, 1. Run a simple testcase, [qiyao@GreenHouse frysk-core]$ ./TestRunner frysk.proc.TestModify ERROR lib.elf.ElfException: Could not open /proc/2095/exe for reading Time: 0.059 There was 1 error: 1) testModify(frysk.proc.TestModify)lib.elf.ElfException: Could not open /proc/2095/exe for reading at lib.elf.Elf.elf_begin(TestRunner) at lib.elf.Elf.(TestRunner) at frysk.proc.IsaFactory.getIsa(TestRunner) at frysk.proc.LinuxTask.sendrecIsa(TestRunner) 2. Check the information for process 2095. [qiyao@GreenHouse frysk-core]$ cat /proc/2095/status Name: gdm-binary State: S (sleeping) SleepAVG: 97% Tgid: 2095 Pid: 2095 PPid: 2055 TracerPid: 0 Uid: 0 0 0 0 Gid: 500 42 500 42 3. Try to attach this process via GDB, [qiyao@GreenHouse frysk-core]$ LANG="en" gdb -p 2095 GNU gdb Red Hat Linux (6.3.0.0-1.122rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". Attaching to process 2095 ptrace: Operation not permitted. /home/qiyao/source/cvs/frysk-qiyao/frysk-core/2095: No such file or directory. 4. I could find this process in Druid, and select observer for it. Here are some questions or ideas to this problem, and appreciate anyone here if you could clarify them for me. Thanks in advance! a) How could frysk-core know "I" could control this process? In the case I post above, frysk-core has the same GID with this process, but frysk-core still could not open /proc//exe. b) Output from GDB tell us that current user could not attach to this process, but I could find this process in Druid, and add some observers to it. How could I verify that frysk could do some operation to this process 2095? I doubt that fryks only add its pid and executable name to Druid, and could not do some operations to this process, such as attach to it. IMO, the current uid/gid is equal to the uid/gid of the process, does not mean frysk-core has the permission to read it, or frysk-core could control this process. It is common that file could not be red by the group user. Is it a bug for isOwned() in GuiProc.java? Any comments on filtering processes? -- Yao Qi From woodzltc@cn.ibm.com Wed Jul 26 08:13:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 26 Jul 2006 08:13:00 -0000 Subject: Fwd: [Bug general/2479] the blankness of the frysk GUI on PPC64 Message-ID: <20060726041345.hm7cpl89gko0s4wg@imap.linux.ibm.com> Phil, I am forwarding this message to you. If you filter don't eat it, please ignore. ----- Forwarded message from sourceware-bugzilla@sourceware.org ----- Date: 26 Jul 2006 08:04:44 -0000 From: woodzltc at cn dot ibm dot com Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug general/2479] the blankness of the frysk GUI on PPC64 To: woodzltc@cn.ibm.com ------- Additional Comments From woodzltc at cn dot ibm dot com 2006-07-26 08:04 ------- Phil, I find a testcase in gtk2-devel: /usr/share/doc/gtk2-devel-2.8.19/examples/menu/menu.c, which can reproduce a similar problem. After building it into executable and pressing the root menu, it will show that the menu entry items are all blank. If you move the mouse to them, you can see the hidden text. But when you set the theme to Smokey-blue, it is ok. I will attache the screenshot and source code below for your reference. Thanks. -- http://sourceware.org/bugzilla/show_bug.cgi?id=2479 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. ----- End forwarded message ----- Regards - Wu Zhou From ajocksch@redhat.com Wed Jul 26 20:18:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Wed, 26 Jul 2006 20:18:00 -0000 Subject: Race condition with AckDaemonProcess Message-ID: <44C7CE23.5070202@redhat.com> I've been using AckDaemonProcess to write the test case for the stack trace work I've been doing, and I've recently stumbled upon an interesting race condition. I'm telling AckDaemonProcess to launch a program called looper2 (that I've checked the source for into frysk-core/rt/tests/) that makes a few function calls to establish some sort of meaningful context, then signals Frysk to continue and busywaits while frysk attaches to it. When I build this file outside of the build system using just -g the daemon process returns right away and the test continues as normal. However since moving looper2 into the build system I find that the AckDaemonProcess constructor times out whenever the test case is run without logging. Running the test case with logging (i.e. with -c FINE) allows the test case to run normally again, which is what leads me to believe that there is a race condition somewhere. I'll be looking into this, but if anyone has any insights they'd like to share they would be very welcome :) Adam From woodzltc@cn.ibm.com Thu Jul 27 10:35:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 27 Jul 2006 10:35:00 -0000 Subject: About building frysk on ppc64 Message-ID: <20060727063506.4imt4m9vwg4kosw0@imap.linux.ibm.com> To build frysk successfully on ppc64, some extra works are needed right now. Some of them is not that bothering: after machine is setup, doing once is ok; others are a little bothering, everytime we check out the latest code from the cvs repository, we need to do some patching to make it build on ppc64. So we want to list them here to see if we can have any remedy for them. 1. There are some missing 64-bit packages. Most of them are 64-bit libraries, including libgcj-4.1.1-3.ppc64.rpm, binutils-2.17.50.0.2-4.ppc64.rpm, libgtk-java-2.8.5-0.ppc64.rpm, cairo-java-1.0.4-0.ppc64.rpm, glib-java-0.2.5-0.ppc64.rpm, libglade-java-2.12.4-0.ppc64.rpm, libvte-java-0.12.0-0.ppc64.rpm, libgnome-java-2.12.3-0.ppc64.rpm, libgconf-java-2.12.1.0.20060301.rh1-1.ppc64.rpm. Bug 2905 was opened for this: http://sourceware.org/bugzilla/show_bug.cgi?id=2905 On PPC64, 64-bit bin-utils package is also needed. bug 2906 was opened to track this: http://sourceware.org/bugzilla/show_bug.cgi?id=2906 We are wishing that they can be fixed in a later Fedora update and RHEL release. But it is not that bothering right now. After downloading these packages and installing them, we don't be bited by them if there is no need to re-install or update system. 2. Some routines in libopcode for ppc64 have dependences on libbfd and libiberty. So to build these part of code, two extra options (-lbfd and -liberty) are needed. Yao Qi ever submitted a patch and Rick Moseley checked it in and removed it out a while later. (please refer to the mail thread: http://sources.redhat.com/ml/frysk/2006-q2/msg00098.html) According to the changelog, a long-term decision is needed to maken before we know how to proceed. Can we know what is the status of this decision? If this decision can't be maken yet, could we have a work around first. Our work around is like this: if the configure script finds that the system is ppc64, use "-lopcodes -lbfd -liberty"; if not, nothing is changed. Is this work around ok? If it is, we can submit a patch to handle this. 3. The current libunwind library doesn't support ppc64 platform (we are very happy to help in this field. :-). The current frysk configuration can also detect if the target support libunwind or not. But this information is not transfered to libunwind's java binding. So frysk will fail to build in the phase of handling libunwind's java binding. We have to remove all libunwind related code to make it build ok. This is bothering indeed, because we have to do that every time we check out the latest cvs source. So is there any chances this get improved. In our opinion, the value of "use_libunwind" can be transfer to the binding code as a macro or similar thing, if it equals no, we don't do any binding at this time; if it is "yes", we do the binding. Is this feasible and acceptable? If it is, we'd like to submit some code to handle this. Any comments are highly appreciated. Regards - Wu Zhou From mark@klomp.org Thu Jul 27 12:24:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 27 Jul 2006 12:24:00 -0000 Subject: ForkedProcess (Was: Kill and refresh) In-Reply-To: <1152881355.2529.41.camel@elsschot.wildebeest.org> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> <1152879437.2529.31.camel@elsschot.wildebeest.org> <1152881355.2529.41.camel@elsschot.wildebeest.org> Message-ID: <1154003024.2977.1.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-07-14 at 14:49 +0200, Mark Wielaard wrote: > On Fri, 2006-07-14 at 14:17 +0200, Mark Wielaard wrote: > > Yes, I actually have an addition to Fork which just gives you an > > Input/OutputStream to the process to communicate with. I found that a > > little more convenient then using signals. I'll post it to the list so > > you can see if that is something we might want to add. > > Here it is. I found it useful to write some quick tests which needed to > exchange information with the child process without needing to attach to > the process or send signals between frysk and the child process. > > 2006-07-14 Mark Wielaard > > * Fork.java (ForkedProcess): New static inner class. > (ForkedInputStream): Likewise. > (ForkedOutputStream): Likewise. > (ForkedProcess): New static method. > * cni/Fork.cxx (fork): New method. > (ForkedOutputStream::write): Likewise. > (ForkedInputStream::read(void)): Likewise. > (ForkedInputStream::read(jbyteArray,jint,jint)): Likewise. > > At first I used Runtime.exec() for this, but since that spawns a new > Thread that tries to wait() on all processes that didn't work nicely > with the rest of frysk core. > > Would it make sense to add this new functionality to Fork? Since I am using this for writing new tests I would like it to be added. OK? Cheers, Mark From mark@klomp.org Thu Jul 27 14:11:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 27 Jul 2006 14:11:00 -0000 Subject: frysk-imports broken tests on x86-64 Message-ID: <1154009461.2977.6.camel@dijkstra.wildebeest.org> Hi, To get a clean make check on x86-64 in frysk-import I marked all tests that are currently broken. When there wasn't a bugzilla report yet I created one. 2006-07-27 Mark Wielaard * tests/TestDwfl.java (testGetLine): Mark as broken bug #2965. 2006-07-27 Mark Wielaard * tests/TestElf.java (testObjectFile): Mark as broken bug #2712. Add assert descriptions. 2006-07-27 Mark Wielaard * tests/TestOpcodes.java (testDisassembler): Mark as broken, bug #2712. Since we really want a clean make check on all supported platforms it seemed appropriate, and pretty helpfull for me at least. Please let me know if someone disagrees. Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: x86-64-broken.patch Type: text/x-patch Size: 7693 bytes Desc: not available URL: From scox@redhat.com Thu Jul 27 23:30:00 2006 From: scox@redhat.com (Stan Cox) Date: Thu, 27 Jul 2006 23:30:00 -0000 Subject: [patch request] don't run ecj on auto generated files Message-ID: <44C94D19.3090803@redhat.com> antlr generates files which generate warnings from ecj, for example unreferenced variables. The current strategy is to use sed scripts to postprocess the sources. However, this is error prone and requires constant tweaking. Are there any objections to only running ecj on top_srcdir *.java files and not running ecj on top_builddir *.java files? I think this change would mostly effect antlr (Cpp*), but here is the entire list of autogenerated files: AT.java ELF.java SHF.java Build.java EM.java SHN.java Config.java ET.java SHT.java CppLexer.java EV.java Sig.java CppParser.java JUnitTests.java STB.java CppParserTokenTypes.jav NT.java STT.java CppTreeParser.java PF.java STV.java CppTreeParserTokenTypes PowerPC.java SyscallNum.java DW.java PT.java TestRunner.java EI.java Here is a patch that will only run ecj on top_srcdir. -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.rules.patch Type: text/x-patch Size: 1765 bytes Desc: not available URL: From woodzltc@cn.ibm.com Fri Jul 28 02:14:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 28 Jul 2006 02:14:00 -0000 Subject: About the license header in Frysk files Message-ID: <20060727221419.1g7uktwt8gggk84g@imap.linux.ibm.com> In each file of Frysk, there is a license header. To tell you the truth, I didn't take much notice of that before. But because we are wishing to add some new files into Frysk, so we had to consider this. Our point is not to add any exception for IBM contributed code at this time. We need some time to evaluate what these words mean (we are not legal people anyway). So what about the following text for new files initiated by IBM people. Any comments are highly appreciated! // This file is part of the program FRYSK. // // Copyright 2006, IBM Corp. // // FRYSK is free software; you can redistribute it and/or modify it // under the terms of the GNU General Public License as published by // the Free Software Foundation; version 2 of the License. // // FRYSK is distributed in the hope that it will be useful, but // WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU // General Public License for more details. // // You should have received a copy of the GNU General Public License // along with FRYSK; if not, write to the Free Software Foundation, // Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. P.S: we are planning to submit these new code with no license header at this time. This is mainly for review. When we reach agreement on both the license text and the code, we can check in the code. Is this ok? Regards - Wu Zhou From qiyaoltc@cn.ibm.com Fri Jul 28 09:41:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 28 Jul 2006 09:41:00 -0000 Subject: [patch] Factory for ISA Message-ID: <20060728093153.GB8035@GreenHouse.cn.ibm.com> Now, A Factory is needed for LinuxTask to select ISA, and I separate ISA selection from LinuxTask.java. 2006-07-28 Yao Qi * frysk/proc/LinuxTask.java: Move ISA selection to IsaFactory.java and format it via Emacs. * frysk/proc/IsaFactory.java: New file. Rebuild frysk on X86 and X86_64, and tested. OK to commit? Thanks! -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/proc/LinuxTask.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxTask.java,v retrieving revision 1.30 diff -u -r1.30 LinuxTask.java --- frysk-core/frysk/proc/LinuxTask.java 20 Jul 2006 15:58:38 -0000 1.30 +++ frysk-core/frysk/proc/LinuxTask.java 28 Jul 2006 03:55:54 -0000 @@ -44,11 +44,7 @@ import frysk.sys.PtraceByteBuffer; import frysk.sys.Sig; import frysk.sys.Signal; -import lib.elf.Elf; -import lib.elf.ElfEMachine; -import lib.elf.ElfCommand; -import lib.elf.ElfEHeader; -import lib.elf.ElfException; + import inua.eio.ByteBuffer; import inua.eio.ByteOrder; import java.util.logging.Level; @@ -60,189 +56,171 @@ public class LinuxTask extends Task { - private long ptraceOptions = 0; + private long ptraceOptions = 0; - // XXX: For moment wire in standard 32-bit little-endian memory - // map. This will be replaced by a memory map created using - // information from /proc/PID/maps. - private void setupMapsXXX () - { - // XXX: For writing at least, PTRACE must be used as /proc/mem - // cannot be written to. - memory = new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.DATA, - 0xffffffffl); - memory.order (ByteOrder.LITTLE_ENDIAN); - // XXX: For moment wire in a standard 32-bit little-endian - // register set. - registerBank = new ByteBuffer[] { - new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.USR) - }; - registerBank[0].order (ByteOrder.LITTLE_ENDIAN); - } - - /** - * Create a new unattached Task. - */ - LinuxTask (Proc proc, TaskId id) - throws Task.TaskException - { - super (proc, id); - setupMapsXXX (); - } - /** - * Create a new attached clone of Task. - */ - LinuxTask (Task task, TaskId clone) - throws TaskException - { - super (task, clone); - setupMapsXXX (); - } - /** - * Create a new attached main Task of Proc. - */ - LinuxTask (Proc proc, TaskObserver.Attached attached) - throws TaskException - { - super (proc, attached); - setupMapsXXX (); - } - - /** - * Must inject disappeared events back into the event loop so that - * they can be processed in sequence. Calling - * receiveDisappearedEvent directly would cause a recursive state - * transition. - */ - private void postDisappearedEvent (final Throwable arg) - { - logger.log (Level.FINE, "{0} postDisappearedEvent\n", this); - Manager.eventLoop.add (new TaskEvent () - { - Throwable w = arg; - public void execute () - { - processDisappearedEvent (w); + // XXX: For moment wire in standard 32-bit little-endian memory + // map. This will be replaced by a memory map created using + // information from /proc/PID/maps. + private void setupMapsXXX () + { + // XXX: For writing at least, PTRACE must be used as /proc/mem + // cannot be written to. + memory = new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.DATA, + 0xffffffffl); + memory.order (ByteOrder.LITTLE_ENDIAN); + // XXX: For moment wire in a standard 32-bit little-endian + // register set. + registerBank = new ByteBuffer[] { + new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.USR) + }; + registerBank[0].order (ByteOrder.LITTLE_ENDIAN); + } + + /** + * Create a new unattached Task. + */ + LinuxTask (Proc proc, TaskId id) + throws Task.TaskException + { + super (proc, id); + setupMapsXXX (); + } + + /** + * Create a new attached clone of Task. + */ + LinuxTask (Task task, TaskId clone) + throws TaskException + { + super (task, clone); + setupMapsXXX (); + } + + /** + * Create a new attached main Task of Proc. + */ + LinuxTask (Proc proc, TaskObserver.Attached attached) + throws TaskException + { + super (proc, attached); + setupMapsXXX (); + } + + /** + * Must inject disappeared events back into the event loop so that + * they can be processed in sequence. Calling + * receiveDisappearedEvent directly would cause a recursive state + * transition. + */ + private void postDisappearedEvent (final Throwable arg) + { + logger.log (Level.FINE, "{0} postDisappearedEvent\n", this); + Manager.eventLoop.add (new TaskEvent () + { + Throwable w = arg; + public void execute () + { + processDisappearedEvent (w); + } + }); + } + + protected void sendContinue (int sig) + { + logger.log (Level.FINE, "{0} sendContinue\n", this); + try { + Ptrace.cont (getTid (), sig); + } + catch (Errno.Esrch e) { + postDisappearedEvent (e); } - }); - } - - protected void sendContinue (int sig) - { - logger.log (Level.FINE, "{0} sendContinue\n", this); - try { - Ptrace.cont (getTid (), sig); - } - catch (Errno.Esrch e) { - postDisappearedEvent (e); - } - } - protected void sendSyscallContinue(int sig){ - logger.log(Level.FINE, "{0} sendSyscallContinue\n", this); - try { - Ptrace.sysCall (getTid (), sig); - } - catch (Errno.Esrch e) { - postDisappearedEvent (e); - } - } - protected void sendStepInstruction (int sig) - { - logger.log (Level.FINE, "{0} sendStepInstruction\n", this); - try { - Ptrace.singleStep (getTid (), sig); } - catch (Errno.Esrch e) { - postDisappearedEvent (e); + protected void sendSyscallContinue(int sig){ + logger.log(Level.FINE, "{0} sendSyscallContinue\n", this); + try { + Ptrace.sysCall (getTid (), sig); + } + catch (Errno.Esrch e) { + postDisappearedEvent (e); + } } - } - protected void sendStop () - { - logger.log (Level.FINE, "{0} sendStop\n", this); - Signal.tkill (id.hashCode (), Sig.STOP); - } - protected void sendSetOptions () - { - logger.log (Level.FINE, "{0} sendSetOptions\n", this); - try { - // XXX: Should be selecting the trace flags based on the - // contents of .observers. - ptraceOptions |= Ptrace.optionTraceClone (); - ptraceOptions |= Ptrace.optionTraceFork (); - ptraceOptions |= Ptrace.optionTraceExit (); - // ptraceOptions |= Ptrace.optionTraceSysgood (); not set by default - ptraceOptions |= Ptrace.optionTraceExec (); - Ptrace.setOptions (getTid (), ptraceOptions); + protected void sendStepInstruction (int sig) + { + logger.log (Level.FINE, "{0} sendStepInstruction\n", this); + try { + Ptrace.singleStep (getTid (), sig); + } + catch (Errno.Esrch e) { + postDisappearedEvent (e); + } } - catch (Errno.Esrch e) { - postDisappearedEvent (e); + protected void sendStop () + { + logger.log (Level.FINE, "{0} sendStop\n", this); + Signal.tkill (id.hashCode (), Sig.STOP); + } + protected void sendSetOptions () + { + logger.log (Level.FINE, "{0} sendSetOptions\n", this); + try { + // XXX: Should be selecting the trace flags based on the + // contents of .observers. + ptraceOptions |= Ptrace.optionTraceClone (); + ptraceOptions |= Ptrace.optionTraceFork (); + ptraceOptions |= Ptrace.optionTraceExit (); + // ptraceOptions |= Ptrace.optionTraceSysgood (); not set by default + ptraceOptions |= Ptrace.optionTraceExec (); + Ptrace.setOptions (getTid (), ptraceOptions); + } + catch (Errno.Esrch e) { + postDisappearedEvent (e); + } } - } - protected void sendAttach () - { - logger.log (Level.FINE, "{0} sendAttach\n", this); - try { - Ptrace.attach (getTid ()); - } - catch (Errno.Eperm e) { - logger.log (Level.FINE, "{" + e.toString () - + "} Cannot attach to process\n"); + protected void sendAttach () + { + logger.log (Level.FINE, "{0} sendAttach\n", this); + try { + Ptrace.attach (getTid ()); + } + catch (Errno.Eperm e) { + logger.log (Level.FINE, "{" + e.toString () + + "} Cannot attach to process\n"); + } + catch (Errno.Esrch e) { + postDisappearedEvent (e); + } } - catch (Errno.Esrch e) { - postDisappearedEvent (e); + protected void sendDetach (int sig) + { + logger.log (Level.FINE, "{0} sendDetach\n", this); + Ptrace.detach (getTid (), sig); } - } - protected void sendDetach (int sig) - { - logger.log (Level.FINE, "{0} sendDetach\n", this); - Ptrace.detach (getTid (), sig); - } - // Keep this around in an instance variable; it might be useful for - // diggging various things out of the executable. - private Elf elfFile; - - protected Isa sendrecIsa () - throws Task.TaskException - { - logger.log (Level.FINE, "{0} sendrecIsa\n", this); - try - { - elfFile = new Elf(getTid(), ElfCommand.ELF_C_READ); - } - catch (ElfException e) - { - throw (TaskException) - (new TaskException("getting task's executable").initCause(e)); - } - - ElfEHeader header = elfFile.getEHeader(); - // XXX hardcoded until we have a factory for producing Isa objects - if (header.machine == ElfEMachine.EM_386) - { - return LinuxIa32.isaSingleton (); - } - else if (header.machine == ElfEMachine.EM_X86_64) - { - return LinuxEMT64.isaSingleton (); - } - else - { - throw new TaskException("Unknown machine type " + header.machine); - } - } + protected Isa sendrecIsa () + throws Task.TaskException + { + logger.log (Level.FINE, "{0} sendrecIsa\n", this); + IsaFactory factory = new IsaFactory(); - protected void startTracingSyscalls() - { - logger.log(Level.FINE, "{0} startTracingSyscalls\n", this); - ptraceOptions |= Ptrace.optionTraceSysgood (); - this.sendSetOptions(); - } - protected void stopTracingSyscalls() - { - logger.log(Level.FINE, "{0} stopTracingSyscalls\n", this); - ptraceOptions &= ~(Ptrace.optionTraceSysgood ()); - this.sendSetOptions(); - } - + try { + return factory.getIsa(id.id); + } + catch (RuntimeException e) { + throw (TaskException) + (new TaskException("").initCause(e)); + } + } + + protected void startTracingSyscalls() + { + logger.log(Level.FINE, "{0} startTracingSyscalls\n", this); + ptraceOptions |= Ptrace.optionTraceSysgood (); + this.sendSetOptions(); + } + protected void stopTracingSyscalls() + { + logger.log(Level.FINE, "{0} stopTracingSyscalls\n", this); + ptraceOptions &= ~(Ptrace.optionTraceSysgood ()); + this.sendSetOptions(); + } } -------------- next part -------------- --- /dev/null 2006-07-23 15:13:00.432249250 +0800 +++ frysk-core/frysk/proc/IsaFactory.java 2006-07-28 11:14:13.000000000 +0800 @@ -0,0 +1,87 @@ +// This file is part of the program FRYSK. +// +// Copyright 2006, Red Hat Inc. +// +// FRYSK is free software; you can redistribute it and/or modify it +// under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// FRYSK is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with FRYSK; if not, write to the Free Software Foundation, +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// In addition, as a special exception, Red Hat, Inc. gives You the +// additional right to link the code of FRYSK with code not covered +// under the GNU General Public License ("Non-GPL Code") and to +// distribute linked combinations including the two, subject to the +// limitations in this paragraph. Non-GPL Code permitted under this +// exception must only link to the code of FRYSK through those well +// defined interfaces identified in the file named EXCEPTION found in +// the source code files (the "Approved Interfaces"). The files of +// Non-GPL Code may instantiate templates or use macros or inline +// functions from the Approved Interfaces without causing the +// resulting work to be covered by the GNU General Public +// License. Only Red Hat, Inc. may make changes or additions to the +// list of Approved Interfaces. You must obey the GNU General Public +// License in all respects for all of the FRYSK code and other code +// used in conjunction with FRYSK except the Non-GPL Code covered by +// this exception. If you modify this file, you may extend this +// exception to your version of the file, but you are not obligated to +// do so. If you do not wish to provide this exception without +// modification, you must delete this exception statement from your +// version and license this file solely under the GPL without +// exception. + +package frysk.proc; + +import java.util.logging.Level; +import java.util.logging.Logger; + +import lib.elf.Elf; +import lib.elf.ElfCommand; +import lib.elf.ElfEHeader; +import lib.elf.ElfEMachine; +import lib.elf.ElfException; + +import frysk.Config; + +public class IsaFactory +{ + static final Logger logger = Logger.getLogger(Config.FRYSK_LOG_ID); + + /* Obtain ISA of task via pid. + */ + public Isa getIsa(int pid) throws RuntimeException + { + Elf elfFile; + logger.log (Level.FINE, "{0} getIsa\n", this); + try { + elfFile = new Elf(pid, ElfCommand.ELF_C_READ); + } + catch (ElfException e) { + throw (RuntimeException) + (new RuntimeException("getting task's executable").initCause(e)); + } + + ElfEHeader header = elfFile.getEHeader(); + + switch (header.machine) { + case ElfEMachine.EM_386: + return LinuxIa32.isaSingleton (); + /* + case ElfEMachine.EM_PPC: + return LinuxPpc.isaSingleton (); + case ElfEMachine.EM_PPC64: + return LinuxPpc64.isaSingleton (); + */ + case ElfEMachine.EM_X86_64: + return LinuxEMT64.isaSingleton (); + default: throw new RuntimeException("Unknown machine type " + header.machine); + } + } +} From qiyaoltc@cn.ibm.com Fri Jul 28 12:01:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 28 Jul 2006 12:01:00 -0000 Subject: [patch] ISA support for ppc/ppc64 Message-ID: <20060728115328.GC8035@GreenHouse.cn.ibm.com> These four files are for supporting ppc/ppc64 ISA. Please have a look, thanks! 2006-07-27 Yao Qi Wu Zhou * frysk/proc/LinuxPpc64.java: New file for ppc64. * frysk/proc/IsaPPC64.java: Ditto. * frysk/proc/LinuxPpc.java: New file for ppc. * frysk/proc/IsaPPC.java: Ditto. Rebuild frysk on X86 and X86_64. Still could not build frysk on PPC/PPC64 since the libunwind java-binding issues(Bug#2969). OK to apply? Thanks! -- Yao Qi -------------- next part -------------- --- /dev/null 2006-07-23 15:13:00.432249250 +0800 +++ frysk-core/frysk/proc/IsaPPC.java 2006-07-28 19:05:08.000000000 +0800 @@ -0,0 +1,88 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.Iterator; +import java.util.LinkedHashMap; +import inua.eio.ByteOrder; + +class IsaPPC implements Isa +{ + static class PPCRegister extends Register + { + PPCRegister (String name, int wordOffset) + { + super (0, wordOffset * 4, 4, name); + } + } + private static PPCRegister[] gprs () + { + PPCRegister[] gprs = new PPCRegister[32]; + for (int i = 0; i < gprs.length; i++) { + gprs[i] = new PPCRegister ("gpr" + i, i); + } + return gprs; + } + private static final PPCRegister[] gpr = gprs (); + + private static final PPCRegister nip = new PPCRegister ("nip", 32); + private static final PPCRegister msr = new PPCRegister ("msr", 33); + private static final PPCRegister orig_r3 = new PPCRegister ("orig_r3", 34); + private static final PPCRegister ctr = new PPCRegister ("ctr", 35); + private static final PPCRegister lnk = new PPCRegister ("lnk", 36); + private static final PPCRegister xer = new PPCRegister ("xer", 37); + private static final PPCRegister ccr = new PPCRegister ("ccr", 38); + private static final PPCRegister mq = new PPCRegister ("mq", 39); + private static final PPCRegister trap = new PPCRegister ("trap", 40); + private static final PPCRegister dar = new PPCRegister ("dar", 41); + private static final PPCRegister dsisr = new PPCRegister ("dsisr", 42); + private static final PPCRegister result = new PPCRegister ("result", 43); + + private LinkedHashMap registerMap = new LinkedHashMap (); + + IsaPPC () + { + for (int i = 0; i < gpr.length; i++) { + registerMap.put (gpr[i].name, gpr[i]); + } + + registerMap.put (nip.name, nip); + registerMap.put (msr.name, msr); + registerMap.put (orig_r3.name, orig_r3); + registerMap.put (ctr.name, ctr); + registerMap.put (lnk.name, lnk); + registerMap.put (xer.name, xer); + registerMap.put (ccr.name, ccr); + registerMap.put (mq.name, mq); + registerMap.put (trap.name, trap); + registerMap.put (dar.name, dar); + registerMap.put (dsisr.name, dsisr); + registerMap.put (result.name, result); + } + + public Iterator RegisterIterator () + { + return registerMap.values ().iterator (); + } + + public Register getRegisterByName (String name) + { + return (Register)registerMap.get (name); + } + + public long pc (Task task) + { + return getRegisterByName ("nip").get (task); + } + + public int getWordSize () + { + return 4; + } + + public ByteOrder getByteOrder () + { + return ByteOrder.BIG_ENDIAN; + } +} + --- /dev/null 2006-07-23 15:13:00.432249250 +0800 +++ frysk-core/frysk/proc/LinuxPpc.java 2006-07-28 19:06:00.000000000 +0800 @@ -0,0 +1,62 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.logging.Level; +import java.util.logging.Logger; +import frysk.Config; + +class LinuxPpc + extends IsaPPC implements SyscallEventDecoder +{ + private static Logger logger = Logger.getLogger (Config.FRYSK_LOG_ID); + private static LinuxPpc isa; + + static LinuxPpc isaSingleton () + { + if (isa == null) + isa = new LinuxPpc (); + return isa; + } + + private SyscallEventInfo info; + + public SyscallEventInfo getSyscallEventInfo () + { + if (info == null) + info = new SyscallEventInfo () + { + public int number (Task task) + { + logger.log (Level.FINE, "Get GPR0 {0}\n", getRegisterByName("gpr0")); + return (int)getRegisterByName("gpr0").get (task); + } + public long returnCode (Task task) + { + return getRegisterByName("gpr3").get (task); + } + public long arg (Task task, int n) + { + switch (n) { + case 0: + return (long)number (task); + case 1: + return getRegisterByName("orig_r3").get (task); + case 2: + return getRegisterByName("gpr4").get (task); + case 3: + return getRegisterByName("gpr5").get (task); + case 4: + return getRegisterByName("gpr6").get (task); + case 5: + return getRegisterByName("gpr7").get (task); + case 6: + return getRegisterByName("gpr8").get (task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + }; + return info; + } +} --- /dev/null 2006-07-23 15:13:00.432249250 +0800 +++ frysk-core/frysk/proc/IsaPPC64.java 2006-07-28 19:04:57.000000000 +0800 @@ -0,0 +1,88 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.Iterator; +import java.util.LinkedHashMap; +import inua.eio.ByteOrder; + +class IsaPPC64 implements Isa +{ + static class PPC64Register extends Register + { + PPC64Register (String name, int wordOffset) + { + super (0, wordOffset * 8, 8, name); + } + } + private static PPC64Register[] gprs () + { + PPC64Register[] gprs = new PPC64Register[32]; + for (int i = 0; i < gprs.length; i++) { + gprs[i] = new PPC64Register ("gpr" + i, i); + } + return gprs; + } + private static final PPC64Register[] gpr = gprs (); + + private static final PPC64Register nip = new PPC64Register ("nip", 32); + private static final PPC64Register msr = new PPC64Register ("msr", 33); + private static final PPC64Register orig_r3 = new PPC64Register ("orig_r3", 34); + private static final PPC64Register ctr = new PPC64Register ("ctr", 35); + private static final PPC64Register lnk = new PPC64Register ("lnk", 36); + private static final PPC64Register xer = new PPC64Register ("xer", 37); + private static final PPC64Register ccr = new PPC64Register ("ccr", 38); + private static final PPC64Register mq = new PPC64Register ("mq", 39); + private static final PPC64Register trap = new PPC64Register ("trap", 40); + private static final PPC64Register dar = new PPC64Register ("dar", 41); + private static final PPC64Register dsisr = new PPC64Register ("dsisr", 42); + private static final PPC64Register result = new PPC64Register ("result", 43); + + private LinkedHashMap registerMap = new LinkedHashMap (); + + IsaPPC64 () + { + for (int i = 0; i < gpr.length; i++) { + registerMap.put (gpr[i].name, gpr[i]); + } + + registerMap.put (nip.name, nip); + registerMap.put (msr.name, msr); + registerMap.put (orig_r3.name, orig_r3); + registerMap.put (ctr.name, ctr); + registerMap.put (lnk.name, lnk); + registerMap.put (xer.name, xer); + registerMap.put (ccr.name, ccr); + registerMap.put (mq.name, mq); + registerMap.put (trap.name, trap); + registerMap.put (dar.name, dar); + registerMap.put (dsisr.name, dsisr); + registerMap.put (result.name, result); + } + + public Iterator RegisterIterator () + { + return registerMap.values ().iterator (); + } + + public Register getRegisterByName (String name) + { + return (Register)registerMap.get (name); + } + + public long pc (Task task) + { + return getRegisterByName ("nip").get (task); + } + + public int getWordSize () + { + return 4; + } + + public ByteOrder getByteOrder () + { + return ByteOrder.BIG_ENDIAN; + } +} + --- /dev/null 2006-07-23 15:13:00.432249250 +0800 +++ frysk-core/frysk/proc/LinuxPpc64.java 2006-07-28 19:06:13.000000000 +0800 @@ -0,0 +1,61 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.logging.Level; +import java.util.logging.Logger; +import frysk.Config; + +class LinuxPpc64 +extends IsaPPC64 implements SyscallEventDecoder +{ + private static Logger logger = Logger.getLogger (Config.FRYSK_LOG_ID); + private static LinuxPpc64 isa; + + static LinuxPpc64 isaSingleton () + { + if (isa == null) + isa = new LinuxPpc64 (); + return isa; + } + + private SyscallEventInfo info; + public SyscallEventInfo getSyscallEventInfo () + { + if (info == null) + info = new SyscallEventInfo () + { + public int number (Task task) + { + logger.log (Level.FINE, "Get GPR0 {0}\n", getRegisterByName("gpr0")); + return (int)getRegisterByName("gpr0").get (task); + } + public long returnCode (Task task) + { + return getRegisterByName("gpr3").get (task); + } + public long arg (Task task, int n) + { + switch (n) { + case 0: + return (long)number (task); + case 1: + return getRegisterByName("orig_r3").get (task); + case 2: + return getRegisterByName("gpr4").get (task); + case 3: + return getRegisterByName("gpr5").get (task); + case 4: + return getRegisterByName("gpr6").get (task); + case 5: + return getRegisterByName("gpr7").get (task); + case 6: + return getRegisterByName("gpr8").get (task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + }; + return info; + } +} From timoore@redhat.com Fri Jul 28 13:07:00 2006 From: timoore@redhat.com (Tim Moore) Date: Fri, 28 Jul 2006 13:07:00 -0000 Subject: [patch] Factory for ISA In-Reply-To: <20060728093153.GB8035@GreenHouse.cn.ibm.com> References: <20060728093153.GB8035@GreenHouse.cn.ibm.com> Message-ID: <44CA0BFA.6060103@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yao Qi wrote: > Now, A Factory is needed for LinuxTask to select ISA, and I separate > ISA selection from LinuxTask.java. > > 2006-07-28 Yao Qi > > * frysk/proc/LinuxTask.java: Move ISA selection to > IsaFactory.java and format it via Emacs. > * frysk/proc/IsaFactory.java: New file. > > Rebuild frysk on X86 and X86_64, and tested. > > OK to commit? Thanks! > This looks fine to me, with two comments: Please keep the GNU indentation. I couldn't tell you how to do this in Eclipse :), but there has been some mail about that recently. Your IsaFactory should probably be a singleton; no need to create a new one for each call to sendrecIsa. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEygv6eDhWHdXrDRURAsbRAKDN9usAPv+Q0zYzcioM59XGkEA/pwCg4r5w +4+a98gAP+JHwXNWufGMEeU= =+qli -----END PGP SIGNATURE----- From cagney@redhat.com Fri Jul 28 13:48:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 28 Jul 2006 13:48:00 -0000 Subject: [patch request] don't run ecj on auto generated files In-Reply-To: <44C94D19.3090803@redhat.com> References: <44C94D19.3090803@redhat.com> Message-ID: <44CA1638.2070905@redhat.com> Stan, I'm not personally warming to the idea for a number of reasons: one of the key reasons for putting the code through ECJ is that that compiler detects bad source that GCJ will accept and turn into bad code - even generated files are exposed to this risk; very shortly GCJ will switch to ECJ as it's front end and we'll be right back where we started; and too often a warning, even in generated code, indicates that there is a problem, even if it is with the generator (the other generated files don't have problems right?). Since antlr is the real concern, can something more local be done? For instance, is there a newer antlr and is it any better? Or can the antlr warnings be handled another way? Howe aware is upstream of the issues? Andrew > antlr generates files which generate warnings from ecj, for example > unreferenced variables. The current strategy is to use sed scripts to > postprocess the sources. However, this is error prone and requires > constant tweaking. Are there any objections to only running ecj on > top_srcdir *.java files and not running ecj on top_builddir *.java > files? I think this change would mostly effect antlr (Cpp*), but here > is the entire list of autogenerated files: > AT.java ELF.java SHF.java > Build.java EM.java SHN.java > Config.java ET.java SHT.java > CppLexer.java EV.java Sig.java > CppParser.java JUnitTests.java STB.java > CppParserTokenTypes.jav NT.java STT.java > CppTreeParser.java PF.java STV.java > CppTreeParserTokenTypes PowerPC.java SyscallNum.java > DW.java PT.java TestRunner.java > EI.java From mark@klomp.org Fri Jul 28 14:03:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 28 Jul 2006 14:03:00 -0000 Subject: [patch request] don't run ecj on auto generated files In-Reply-To: <44CA1638.2070905@redhat.com> References: <44C94D19.3090803@redhat.com> <44CA1638.2070905@redhat.com> Message-ID: <1154095345.2942.22.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-07-28 at 09:50 -0400, Andrew Cagney wrote: > I'm not personally warming to the idea for a number of reasons: one of > the key reasons for putting the code through ECJ is that that compiler > detects bad source that GCJ will accept and turn into bad code - even > generated files are exposed to this risk; very shortly GCJ will switch > to ECJ as it's front end and we'll be right back where we started; and > too often a warning, even in generated code, indicates that there is a > problem, even if it is with the generator (the other generated files > don't have problems right?). ECJ is really, really obnoxious in its warnings in default mode. I truly hope that when GCJ uses ECJ as byte-code generator it will turn off a couple of the really silly ones. I personally always turn off at least the following: -warn:-serial,unused and often also deprecation because lots of code uses deprecated classes and methods from the standard library anyway. Would it be an idea to do use ECJ as sanity check, but with the above warning flags turned off for generated files? Cheers, Mark From cagney@redhat.com Fri Jul 28 14:06:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 28 Jul 2006 14:06:00 -0000 Subject: About the license header in Frysk files In-Reply-To: <20060727221419.1g7uktwt8gggk84g@imap.linux.ibm.com> References: <20060727221419.1g7uktwt8gggk84g@imap.linux.ibm.com> Message-ID: <44CA1917.6030907@redhat.com> Wu, The exception clause was chosen to ensure that the code base can be used as a library with Eclipse and its GPL incompatible EPL. The clause is identical to that used by "directory server" (We've obviously also got an effort to ensure that our eventual set of libraries are also all EPL compatible). If that exception is removed then so to is the Eclipse option. Andrew Wu Zhou wrote: > In each file of Frysk, there is a license header. To tell you the > truth, I didn't take much notice of that before. But because we are > wishing to add some new files into Frysk, so we had to consider this. > > Our point is not to add any exception for IBM contributed code at this > time. We need some time to evaluate what these words mean (we are not > legal people anyway). So what about the following text for new files > initiated by IBM people. > Any comments are highly appreciated! > > // This file is part of the program FRYSK. > // > // Copyright 2006, IBM Corp. > // > // FRYSK is free software; you can redistribute it and/or modify it > // under the terms of the GNU General Public License as published by > // the Free Software Foundation; version 2 of the License. > // > // FRYSK is distributed in the hope that it will be useful, but > // WITHOUT ANY WARRANTY; without even the implied warranty of > // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > // General Public License for more details. > // > // You should have received a copy of the GNU General Public License > // along with FRYSK; if not, write to the Free Software Foundation, > // Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. > > > P.S: we are planning to submit these new code with no license header > at this time. This is mainly for review. When we reach agreement on > both the license text and the code, we can check in the code. Is this > ok? > > Regards > - Wu Zhou From scox@redhat.com Fri Jul 28 14:55:00 2006 From: scox@redhat.com (Stan Cox) Date: Fri, 28 Jul 2006 14:55:00 -0000 Subject: [patch request] don't run ecj on auto generated files In-Reply-To: <1154095345.2942.22.camel@dijkstra.wildebeest.org> References: <44C94D19.3090803@redhat.com> <44CA1638.2070905@redhat.com> <1154095345.2942.22.camel@dijkstra.wildebeest.org> Message-ID: <44CA25C1.5030007@redhat.com> Mark Wielaard wrote: > couple of the really silly ones. I personally always turn off at least > the following: -warn:-serial,unused and often also deprecation because > Would it be an idea to do use ECJ as sanity check, but with the above > warning flags turned off for generated files? unused would solve the antlr generated files problem. It creates unused states for the abstract syntax tree, especially now that the grammar is growing in complexity. Using a sed script to post process the sources just seems very wrong to me. From cagney@redhat.com Fri Jul 28 15:08:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 28 Jul 2006 15:08:00 -0000 Subject: Race condition with AckDaemonProcess In-Reply-To: <44C7CE23.5070202@redhat.com> References: <44C7CE23.5070202@redhat.com> Message-ID: <44CA2910.1040108@redhat.com> Adam Jocksch wrote: > I've been using AckDaemonProcess to write the test case for the stack > trace work I've been doing, and I've recently stumbled upon an > interesting race condition. > > I'm telling AckDaemonProcess to launch a program called looper2 (that > I've checked the source for into frysk-core/rt/tests/) that makes a > few function calls to establish some sort of meaningful context, then > signals Frysk to continue and busywaits while frysk attaches to it. > When I build this file outside of the build system using just -g the > daemon process returns right away and the test continues as normal. > However since moving looper2 into the build system I find that the > AckDaemonProcess constructor times out whenever the test case is run > without logging. Running the test case with logging (i.e. with -c > FINE) allows the test case to run normally again, which is what leads > me to believe that there is a race condition somewhere. Something must be causing it to miss or drop the ack signal :-/ Does it work when just that test is run from within the test framework? What does ftrace show? Andrew > > I'll be looking into this, but if anyone has any insights they'd like > to share they would be very welcome :) > > Adam From ajocksch@redhat.com Fri Jul 28 15:10:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Fri, 28 Jul 2006 15:10:00 -0000 Subject: Race condition with AckDaemonProcess In-Reply-To: <44CA2910.1040108@redhat.com> References: <44C7CE23.5070202@redhat.com> <44CA2910.1040108@redhat.com> Message-ID: <44CA28F4.9030501@redhat.com> Andrew Cagney wrote: > Adam Jocksch wrote: >> I've been using AckDaemonProcess to write the test case for the stack >> trace work I've been doing, and I've recently stumbled upon an >> interesting race condition. >> >> I'm telling AckDaemonProcess to launch a program called looper2 (that >> I've checked the source for into frysk-core/rt/tests/) that makes a >> few function calls to establish some sort of meaningful context, then >> signals Frysk to continue and busywaits while frysk attaches to it. >> When I build this file outside of the build system using just -g the >> daemon process returns right away and the test continues as normal. >> However since moving looper2 into the build system I find that the >> AckDaemonProcess constructor times out whenever the test case is run >> without logging. Running the test case with logging (i.e. with -c >> FINE) allows the test case to run normally again, which is what leads >> me to believe that there is a race condition somewhere. > Something must be causing it to miss or drop the ack signal :-/ Does > it work when just that test is run from within the test framework? > What does ftrace show? > > Andrew > >> >> I'll be looking into this, but if anyone has any insights they'd like >> to share they would be very welcome :) >> >> Adam > I think I've resolved this issue. The test program I was using was reaching the kill call before frysk was ready to recieve it. I've changed the test program and it seems to work now, although I'll be watching closely for it's recurrance. Adam From cagney@redhat.com Fri Jul 28 15:19:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 28 Jul 2006 15:19:00 -0000 Subject: Race condition with AckDaemonProcess In-Reply-To: <44CA28F4.9030501@redhat.com> References: <44C7CE23.5070202@redhat.com> <44CA2910.1040108@redhat.com> <44CA28F4.9030501@redhat.com> Message-ID: <44CA2B9C.7040308@redhat.com> > I think I've resolved this issue. The test program I was using was > reaching the kill call before frysk was ready to recieve it. I've > changed the test program and it seems to work now, although I'll be > watching closely for it's recurrance. Now that is a race, TestRunner should be ready to receive the signal from the moment the program is created? Andrew From tromey@redhat.com Fri Jul 28 15:44:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Fri, 28 Jul 2006 15:44:00 -0000 Subject: [patch request] don't run ecj on auto generated files Message-ID: <17610.12134.332953.663105@localhost.localdomain> I'm not on the frysk list so I just pulled this off the web site... Mark> I truly hope that when GCJ uses ECJ as byte-code generator it Mark> will turn off a couple of the really silly ones. Right now it just defaults to whatever ecj does. Could you file a request in GCC bugzilla (put '[ecj]' at the start of the synopsis) for this? I'll try to choose a more sensible set of defaults. Tom From cagney@redhat.com Fri Jul 28 18:35:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 28 Jul 2006 18:35:00 -0000 Subject: Making the run-until-ack in frysk.proc.TestLib.AckDaemon explicit Message-ID: <44CA599E.3040905@redhat.com> Hello, On IRC, a number of times, its been pointed out that the AckDaemon interface isn't very explicit about how it will run the event loop (it does it for instance when telling a process to fork). To address this, I'm thinking of changing the interface to: @@ -139,10 +139,10 @@ public class StressAttachDetachSignaledT { switch (iteration % 2) { case 0: - child.addClone (); + child.sendAddClone ().assertRunUntilAcks (); break; case 1: - child.delClone (); + child.sendDelClone ().assertRunUntilAcks (); break; } } I.e., both the "send" and need to run the event loop are very explicit. Yes, the down side is that it is more verbose, I think clarity trumps verbosity :-) thoughts? Andrew From mark@klomp.org Fri Jul 28 19:22:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 28 Jul 2006 19:22:00 -0000 Subject: Making alll sys and core tests pass on x86-64 Message-ID: <1154114537.2942.36.camel@dijkstra.wildebeest.org> Hi, This tiny little patch finally makes all frysk-sys and frysk-core tests PASS (/me dances around). Double checked that x86 also still pass. Hope this also helps for other platforms. 2006-07-28 Mark Wielaard * Ptrace.java (poke): Change data parameter from int to long. * cni/Ptrace.cxx (poke): Likewise. Together with the last Ptrace patch from Tim this also seems to fix http://sourceware.org/bugzilla/show_bug.cgi?id=1547 if I understood that report correctly. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 1321 bytes Desc: not available URL: From scox@redhat.com Fri Jul 28 21:48:00 2006 From: scox@redhat.com (Stan Cox) Date: Fri, 28 Jul 2006 21:48:00 -0000 Subject: [patch request] don't run ecj on auto generated files In-Reply-To: <44CA1638.2070905@redhat.com> References: <44C94D19.3090803@redhat.com> <44CA1638.2070905@redhat.com> Message-ID: <44CA8697.60806@redhat.com> Andrew Cagney wrote: > Since antlr is the real concern, can something more local be done? > Or can the antlr warnings be handled another way? How about this narrower in scope approach? If prune-ecj is defined then those files will be pruned so ecj is not run on them. This narrows down to not running ecj on CppParser.java and CppTreeParser.java. Index: frysk-core/Makefile.am @@ -54,6 +54,9 @@ EXTRA_DIST += \ ANTLR = $(JAVA) -classpath ../frysk-imports/antlr.jar antlr.Tool +# Prune files.list so these antlr generated files are not run through ecj +prune_ecj = /CppParser /CppTreeParser + # Add dejagnu, remember to clean up. AUTOMAKE_OPTIONS = dejagnu Index: common/Makefile.rules @@ -541,6 +541,13 @@ ecj/checked: files.list $(GEN_DIRNAME).j rm -rf ecj mkdir -p ecj if HAVE_ECJ + $(if $(prune_ecj), \ + cp files.list files.list.tmp1; \ + for g in $(prune_ecj) ; do \ + grep -v $$g files.list.tmp1 > files.list.tmp2; \ + mv files.list.tmp2 files.list.tmp1; \ + done; \ + mv files.list.tmp1 files.list) $(GIJ) \ --classpath $(ECJ_JAR):$(CLASSPATH) \ org.eclipse.jdt.internal.compiler.batch.Main \ multics:/home/scox/accu/src From mark@klomp.org Sat Jul 29 15:01:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Sat, 29 Jul 2006 15:01:00 -0000 Subject: [patch request] don't run ecj on auto generated files In-Reply-To: <17610.12134.332953.663105@localhost.localdomain> References: <17610.12134.332953.663105@localhost.localdomain> Message-ID: <1154185290.5929.24.camel@dijkstra.wildebeest.org> Hi Tom, On Fri, 2006-07-28 at 11:38 -0400, Tom Tromey wrote: > Mark> I truly hope that when GCJ uses ECJ as byte-code generator it > Mark> will turn off a couple of the really silly ones. > > Right now it just defaults to whatever ecj does. > > Could you file a request in GCC bugzilla (put '[ecj]' at the start of > the synopsis) for this? I'll try to choose a more sensible set of > defaults. This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28533 Thanks, Mark From zhengy@linux.ibm.com Mon Jul 31 03:09:00 2006 From: zhengy@linux.ibm.com (Yong Zheng) Date: Mon, 31 Jul 2006 03:09:00 -0000 Subject: Test results of dogtail on PPC64. Thanks! Message-ID: <1154315076.3913.13.camel@YZ_X86_64> hi all, We are using the example scripts in dogtail's rpm package to test dogtail on ppc64. The test results seems to be good, although we need to make some modification to these scripts here and there. We summarize what we have tested as follows, wishing that this can be helpful for you to get a big picture of how dogtail works on ppc64. Software environment: dogtail-0.5.1 pyspi-0.5.4(required by dogtail) at-spi-1.7.7(required by dogtail) rpm-python-4.4.2(required by dogtail) Fedora Core 5(kernel:2.6.17-1.2139_FC5) Hardware platform: PPC64 Summary of the test result: Total scripts: 22 Succeeding scripts: 18 (all run well, we make some modification to the test scripts though) Failing scripts: 2 (recorder.py and test-events.py) Skipped scripts: 2 (the tested applications are not available on PPC64) P.S: If anyone think the modification might be helpful, we're willing to send the modification as one patch to you. Thanks & best regards! Yong Zheng Linux on POWER toolchain, Linux Technology Center, China Systems & Technology Lab China Development Labs, Beijing. Email: zhengyzy@cn.ibm.com From woodzltc@cn.ibm.com Mon Jul 31 04:12:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 31 Jul 2006 04:12:00 -0000 Subject: debugging an existing process Message-ID: <20060731001217.26o0l7io04cc00kg@imap.linux.ibm.com> I see that debugging existing process can be used now. So I give it some try. I am very happy to see that register/memory window work ok. The source window can also be opened in some situation. But I also have some comments/questions for this: 1. If the process has no debug information, you will see nothing in the source window; if the process is executing into some library function, you will also see nothing in the source window. So is it better for us to have some mechanism to differentiate these two different situation? My suggestion is like this: if the current stack frame has no debuginfo, but the current process does have, we can show some message like this: "no debug information for this stack, but we do have debug information for this process, would you like to see the source for the process?". This can give the user more choice to see the source code. 2. When the current stack frame has no debug information available, the current frysk view will display "unknown file: unknown function". In my opinion, it might be better to display the instruction address of the current stack. 3. In the register view, if we can copy the value of some or all the registers' value, that will be helpful. 4. The menu items in program tab are all disabled. Did this mean we can't control the process at this time? Regards - Wu Zhou From qiyaoltc@cn.ibm.com Mon Jul 31 07:44:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 31 Jul 2006 07:44:00 -0000 Subject: fix for bug 2969 Message-ID: <20060731054339.GB29289@GreenHouse.cn.ibm.com> libunwind is not supported on ppc/ppc64, so libuwind and its java bindings could be skipped when build frysk on ppc/ppc64. 2006-07-31 Yao Qi * frysk-imports/bootstrap.sh: Build libunwind if it is supported. Run bootstrap.sh on X86 and PPC64 to verify its output(Makefile.gen), and libunwind and its java bindings are only built on X86. OK to apply? Thanks. -- Yao Qi Index: frysk-imports/bootstrap.sh =================================================================== RCS file: /cvs/frysk/frysk-imports/bootstrap.sh,v retrieving revision 1.8 diff -u -r1.8 bootstrap.sh --- frysk-imports/bootstrap.sh 13 Jul 2006 11:13:12 -0000 1.8 +++ frysk-imports/bootstrap.sh 31 Jul 2006 05:31:14 -0000 @@ -38,8 +38,7 @@ # version and license this file solely under the GPL without # exception. -./common/Makefile.gen.sh \ - frysk \ +FILE_LIST="frysk \ inua \ junit/junit.jar \ ANTLR_JAR \ @@ -47,8 +46,31 @@ JDOM_JAR \ jline/jline.jar \ jargs/jargs.jar \ - lib - + lib/dw \ + lib/elf \ + lib/opcodes " + +target_cpu=`uname -a` + +case "${target_cpu}" in + *86*) + # libunwind is supported on X86 and X86_64 now, so buildlibunwind + # java binding. When libunwind is supported on PPC/PPC64, libuwind + # and its java bindings could be built unconditionally. + FILE_LIST+=lib/unwind + # Now run a separate aclocal/autoconf/automake for libunwind + cd libunwind + echo "Running aclocal ... for libunwind" + aclocal + echo "Running autoconf ... for libunwind" + autoconf -f + echo "Running autoheader ... for libunwind" + autoheader + cd .. + ;; +esac + +./common/Makefile.gen.sh $FILE_LIST # Generate everything (always run with --add-missing). @@ -76,17 +98,3 @@ autoconf -f cd .. -target_cpu=`uname -a` - -case "${target_cpu}" in - *86*) - # Now run a separate aclocal/autoconf/automake for libunwind - cd libunwind - echo "Running aclocal ... for libunwind" - aclocal - echo "Running autoconf ... for libunwind" - autoconf -f - echo "Running autoheader ... for libunwind" - autoheader - ;; -esac From qiyaoltc@cn.ibm.com Mon Jul 31 11:34:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 31 Jul 2006 11:34:00 -0000 Subject: [patch] ISA support for ppc/ppc64 In-Reply-To: <20060728115328.GC8035@GreenHouse.cn.ibm.com> References: <20060728115328.GC8035@GreenHouse.cn.ibm.com> Message-ID: <20060731112558.GD29289@GreenHouse.cn.ibm.com> On Fri, Jul 28, 2006 at 07:53:30PM +0800, Yao Qi wrote: > These four files are for supporting ppc/ppc64 ISA. Please have a > look, thanks! > > 2006-07-27 Yao Qi > Wu Zhou > > * frysk/proc/LinuxPpc64.java: New file for ppc64. > * frysk/proc/IsaPPC64.java: Ditto. > * frysk/proc/LinuxPpc.java: New file for ppc. > * frysk/proc/IsaPPC.java: Ditto. > > Rebuild frysk on X86 and X86_64. Still could not build frysk on > PPC/PPC64 since the libunwind java-binding issues(Bug#2969). Polish the code per Tim's suggestion to keep GNU indentation, and here is the patch again. Could you have a look? Thanks! -- Yao Qi -------------- next part -------------- --- /dev/null 2006-07-28 20:41:40.430451000 +0800 +++ frysk-core/frysk/proc/IsaPPC.java 2006-07-31 16:55:18.000000000 +0800 @@ -0,0 +1,94 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.Iterator; +import java.util.LinkedHashMap; + +import inua.eio.ByteOrder; + +class IsaPPC + implements Isa +{ + static class PPCRegister + extends Register + { + PPCRegister (String name, int wordOffset) + { + super (0, wordOffset * 4, 4, name); + } + } + + private static PPCRegister[] gprs () + { + PPCRegister[] gprs = new PPCRegister[32]; + for (int i = 0; i < gprs.length; i++) + { + gprs[i] = new PPCRegister ("gpr" + i, i); + } + return gprs; + } + + private static final PPCRegister[] gpr = gprs(); + + private static final PPCRegister nip = new PPCRegister("nip", 32); + private static final PPCRegister msr = new PPCRegister("msr", 33); + private static final PPCRegister orig_r3 = new PPCRegister("orig_r3", 34); + private static final PPCRegister ctr = new PPCRegister("ctr", 35); + private static final PPCRegister lnk = new PPCRegister("lnk", 36); + private static final PPCRegister xer = new PPCRegister("xer", 37); + private static final PPCRegister ccr = new PPCRegister("ccr", 38); + private static final PPCRegister mq = new PPCRegister("mq", 39); + private static final PPCRegister trap = new PPCRegister("trap", 40); + private static final PPCRegister dar = new PPCRegister("dar", 41); + private static final PPCRegister dsisr = new PPCRegister("dsisr", 42); + private static final PPCRegister result = new PPCRegister("result", 43); + + private LinkedHashMap registerMap = new LinkedHashMap (); + + IsaPPC () + { + for (int i = 0; i < gpr.length; i++) + { + registerMap.put (gpr[i].name, gpr[i]); + } + + registerMap.put(nip.name, nip); + registerMap.put(msr.name, msr); + registerMap.put(orig_r3.name, orig_r3); + registerMap.put(ctr.name, ctr); + registerMap.put(lnk.name, lnk); + registerMap.put(xer.name, xer); + registerMap.put(ccr.name, ccr); + registerMap.put(mq.name, mq); + registerMap.put(trap.name, trap); + registerMap.put(dar.name, dar); + registerMap.put(dsisr.name, dsisr); + registerMap.put(result.name, result); + } + + public Iterator RegisterIterator () + { + return registerMap.values().iterator(); + } + + public Register getRegisterByName (String name) + { + return (Register)registerMap.get(name); + } + + public long pc (Task task) + { + return getRegisterByName("nip").get(task); + } + + public int getWordSize () + { + return 4; + } + + public ByteOrder getByteOrder () + { + return ByteOrder.BIG_ENDIAN; + } +} --- /dev/null 2006-07-28 20:41:40.430451000 +0800 +++ frysk-core/frysk/proc/IsaPPC64.java 2006-07-31 16:35:18.000000000 +0800 @@ -0,0 +1,94 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.Iterator; +import java.util.LinkedHashMap; + +import inua.eio.ByteOrder; + +class IsaPPC64 + implements Isa +{ + static class PPC64Register + extends Register + { + PPC64Register(String name, int wordOffset) + { + super (0, wordOffset * 8, 8, name); + } + } + + private static PPC64Register[] gprs() + { + PPC64Register[] gprs = new PPC64Register[32]; + for (int i = 0; i < gprs.length; i++) + { + gprs[i] = new PPC64Register ("gpr" + i, i); + } + return gprs; + } + + private static final PPC64Register[] gpr = gprs(); + + private static final PPC64Register nip = new PPC64Register("nip", 32); + private static final PPC64Register msr = new PPC64Register("msr", 33); + private static final PPC64Register orig_r3 = new PPC64Register("orig_r3", 34); + private static final PPC64Register ctr = new PPC64Register("ctr", 35); + private static final PPC64Register lnk = new PPC64Register("lnk", 36); + private static final PPC64Register xer = new PPC64Register("xer", 37); + private static final PPC64Register ccr = new PPC64Register("ccr", 38); + private static final PPC64Register mq = new PPC64Register("mq", 39); + private static final PPC64Register trap = new PPC64Register("trap", 40); + private static final PPC64Register dar = new PPC64Register("dar", 41); + private static final PPC64Register dsisr = new PPC64Register("dsisr", 42); + private static final PPC64Register result = new PPC64Register("result", 43); + + private LinkedHashMap registerMap = new LinkedHashMap(); + + IsaPPC64() + { + for (int i = 0; i < gpr.length; i++) + { + registerMap.put (gpr[i].name, gpr[i]); + } + + registerMap.put(nip.name, nip); + registerMap.put(msr.name, msr); + registerMap.put(orig_r3.name, orig_r3); + registerMap.put(ctr.name, ctr); + registerMap.put(lnk.name, lnk); + registerMap.put(xer.name, xer); + registerMap.put(ccr.name, ccr); + registerMap.put(mq.name, mq); + registerMap.put(trap.name, trap); + registerMap.put(dar.name, dar); + registerMap.put(dsisr.name, dsisr); + registerMap.put(result.name, result); + } + + public Iterator RegisterIterator () + { + return registerMap.values().iterator(); + } + + public Register getRegisterByName (String name) + { + return (Register)registerMap.get(name); + } + + public long pc (Task task) + { + return getRegisterByName("nip").get(task); + } + + public int getWordSize () + { + return 4; + } + + public ByteOrder getByteOrder () + { + return ByteOrder.BIG_ENDIAN; + } +} --- /dev/null 2006-07-28 20:41:40.430451000 +0800 +++ frysk-core/frysk/proc/LinuxPpc.java 2006-07-31 16:51:50.000000000 +0800 @@ -0,0 +1,64 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.logging.Level; +import java.util.logging.Logger; + +import frysk.Config; + +class LinuxPpc + extends IsaPPC implements SyscallEventDecoder +{ + private static Logger logger = Logger.getLogger(Config.FRYSK_LOG_ID); + private static LinuxPpc isa; + + static LinuxPpc isaSingleton () + { + if (isa == null) + isa = new LinuxPpc (); + return isa; + } + + private SyscallEventInfo info; + + public SyscallEventInfo getSyscallEventInfo () + { + if (info == null) + info = new SyscallEventInfo () + { + public int number (Task task) + { + logger.log (Level.FINE, "Get GPR0 {0}\n", getRegisterByName("gpr0")); + return (int)getRegisterByName("gpr0").get(task); + } + public long returnCode (Task task) + { + return getRegisterByName("gpr3").get(task); + } + public long arg (Task task, int n) + { + switch (n) + { + case 0: + return (long)number(task); + case 1: + return getRegisterByName("orig_r3").get(task); + case 2: + return getRegisterByName("gpr4").get(task); + case 3: + return getRegisterByName("gpr5").get(task); + case 4: + return getRegisterByName("gpr6").get(task); + case 5: + return getRegisterByName("gpr7").get(task); + case 6: + return getRegisterByName("gpr8").get(task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + }; + return info; + } +} \ No newline at end of file --- /dev/null 2006-07-28 20:41:40.430451000 +0800 +++ frysk-core/frysk/proc/LinuxPpc64.java 2006-07-31 16:43:08.000000000 +0800 @@ -0,0 +1,63 @@ +// This file is part of the program FRYSK. + +package frysk.proc; + +import java.util.logging.Level; +import java.util.logging.Logger; + +import frysk.Config; + +class LinuxPpc64 + extends IsaPPC64 implements SyscallEventDecoder +{ + private static Logger logger = Logger.getLogger(Config.FRYSK_LOG_ID); + private static LinuxPpc64 isa; + + static LinuxPpc64 isaSingleton () + { + if (isa == null) + isa = new LinuxPpc64 (); + return isa; + } + + private SyscallEventInfo info; + public SyscallEventInfo getSyscallEventInfo () + { + if (info == null) + info = new SyscallEventInfo () + { + public int number (Task task) + { + logger.log (Level.FINE, "Get GPR0 {0}\n",getRegisterByName("gpr0")); + return (int)getRegisterByName("gpr0").get(task); + } + public long returnCode (Task task) + { + return getRegisterByName("gpr3").get(task); + } + public long arg (Task task, int n) + { + switch (n) + { + case 0: + return (long)number (task); + case 1: + return getRegisterByName("orig_r3").get(task); + case 2: + return getRegisterByName("gpr4").get(task); + case 3: + return getRegisterByName("gpr5").get(task); + case 4: + return getRegisterByName("gpr6").get(task); + case 5: + return getRegisterByName("gpr7").get(task); + case 6: + return getRegisterByName("gpr8").get(task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + }; + return info; + } +} From qiyaoltc@cn.ibm.com Mon Jul 31 12:27:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 31 Jul 2006 12:27:00 -0000 Subject: fix for bug 2969 In-Reply-To: <20060731054339.GB29289@GreenHouse.cn.ibm.com> References: <20060731054339.GB29289@GreenHouse.cn.ibm.com> Message-ID: <20060731121724.GE29289@GreenHouse.cn.ibm.com> On Mon, Jul 31, 2006 at 01:43:41PM +0800, Yao Qi wrote: > libunwind is not supported on ppc/ppc64, so libuwind and its java > bindings could be skipped when build frysk on ppc/ppc64. > > 2006-07-31 Yao Qi > > * frysk-imports/bootstrap.sh: Build libunwind if it is supported. > > Run bootstrap.sh on X86 and PPC64 to verify its output(Makefile.gen), > and libunwind and its java bindings are only built on X86. > > OK to apply? Thanks. > Files in frysk-core/frysk/rt/ also do some java bindings for libunwind, and this patch could not cover it. Could we put these libunwind java bindings together in the same place? such as frysk-import/lib/unwind. That would be easy to organize and maintain the code about libunwind. Code in frysk-core/frysk/rt only need to call the methods provided by libunwind java-bindings. Any comments? Thanks! -- Yao Qi From ezannoni@redhat.com Mon Jul 31 13:52:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Mon, 31 Jul 2006 13:52:00 -0000 Subject: testing utrace Message-ID: <17614.2633.572726.888779@localhost.redhat.com> Hi, please focus on testing utrace in the rawhide kernel. It supports all the RHEL arches except ia64. Use any kernel >= 1.2466. Let Roland know of any regressions. As you find problems, please file a Redhat bugzilla against Fedora. http://bugzilla.redhat.com/bugzilla/ From mark@klomp.org Mon Jul 31 14:20:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 31 Jul 2006 14:20:00 -0000 Subject: testing utrace In-Reply-To: <17614.2633.572726.888779@localhost.redhat.com> References: <17614.2633.572726.888779@localhost.redhat.com> Message-ID: <1154355595.2983.43.camel@dijkstra.wildebeest.org> Hi, On Mon, 2006-07-31 at 09:48 -0400, Elena Zannoni wrote: > please focus on testing utrace in the rawhide kernel. > It supports all the RHEL arches except ia64. > Use any kernel >= 1.2466. > > Let Roland know of any regressions. As you find problems, please file > a Redhat bugzilla against Fedora. The biggest issue I know of, and the reason I don't use any rawhide/fc6test kernels is that it is pretty easy to completely freeze your machine using frysk: http://sourceware.org/bugzilla/show_bug.cgi?id=2959 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200605 Cheers, Mark From ajocksch@redhat.com Mon Jul 31 14:46:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Mon, 31 Jul 2006 14:46:00 -0000 Subject: debugging an existing process In-Reply-To: <20060731001217.26o0l7io04cc00kg@imap.linux.ibm.com> References: <20060731001217.26o0l7io04cc00kg@imap.linux.ibm.com> Message-ID: <44CE17AA.2010806@redhat.com> Wu Zhou wrote: > I see that debugging existing process can be used now. So I give it > some try. I am very happy to see that register/memory window work ok. > The source window can also be opened in some situation. But I also > have some comments/questions for this: > > 1. If the process has no debug information, you will see nothing in > the source window; if the process is executing into some library > function, you will also see nothing in the source window. So is it > better for us to have some mechanism to differentiate these two > different situation? > > My suggestion is like this: if the current stack frame has no > debuginfo, but the current process does have, we can show some message > like this: "no debug information for this stack, but we do have debug > information for this process, would you like to see the source for the > process?". > > This can give the user more choice to see the source code. I agree, making a distinction between these two cases is an excellent idea. However we have no way of distinguishing between these cases at the moment. As soon as we can obtain a full stack backtrace we will be able to tell if there is a stack frame with debug information or not. > 2. When the current stack frame has no debug information available, > the current frysk view will display "unknown file: unknown function". > In my opinion, it might be better to display the instruction address > of the current stack. > Something to consider. I'll look into this > 3. In the register view, if we can copy the value of some or all the > registers' value, that will be helpful. Again, something to consider. > > 4. The menu items in program tab are all disabled. Did this mean we > can't control the process at this time? Correct :) Adam From npremji@redhat.com Mon Jul 31 19:05:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Mon, 31 Jul 2006 19:05:00 -0000 Subject: Dogtail testing EventViewer: Introducing markers. Message-ID: <1154372718.20228.2.camel@to-rhaps5.toronto.redhat.com> I have just committed code which should allow dogtail to be able to see markers/observers (at least sniff does). I will be writing a few test cases to make sure that observers are added when they should be, and not added when they shouldn't be. After that I will start working on getting traces and events seen as well. From mcvet@redhat.com Mon Jul 31 19:21:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Mon, 31 Jul 2006 19:21:00 -0000 Subject: Actions and Filters Message-ID: <1154373709.1992.11.camel@towel.toronto.redhat.com> Hey all, I've been working Frysk's Actions and Filters packages for the past couple days. So far, this has resulted in the ability to raise multiple Memory and Register windows independently of the SourceWindow via any number of event Filters (new and old) available in custom observers. To summarize; the available Filters are... Filter by (for both Tasks and Processes, fork()ers and fork()ed): Name Name of parent Command-line options Executable path Exit value Resulting in Actions: Log custom event Show source code Add observer Print current state Show register values Show memory space values Currently I am working on allowing the user to execute an external script or binary as a further Action. If anyone has any suggestions for more Filters or Actions, please let me know. Mike From pmuldoon@redhat.com Mon Jul 31 19:35:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 31 Jul 2006 19:35:00 -0000 Subject: Actions and Filters In-Reply-To: <1154373709.1992.11.camel@towel.toronto.redhat.com> References: <1154373709.1992.11.camel@towel.toronto.redhat.com> Message-ID: <44CE5B7C.809@redhat.com> The big action I'd like to see (we've talked about this on irc) is to run an external executable on observer fire. This requires thought on: 1) any security issues? 2) executable environment issues? (Or should we, like gnome-panel's just "run" the executable)? The other thing we need to think about with custom actions, it how to throttle the action to X per Y over time (once per hour for example, lest we page a sysadmin a thousand times in 10 minutes ;) Regards Phil Mike Cvet wrote: > Hey all, > > I've been working Frysk's Actions and Filters packages for the past > couple days. So far, this has resulted in the ability to raise multiple > Memory and Register windows independently of the SourceWindow via any > number of event Filters (new and old) available in custom observers. > > To summarize; the available Filters are... > Filter by (for both Tasks and Processes, fork()ers and fork()ed): > > Name > Name of parent > Command-line options > Executable path > Exit value > > Resulting in Actions: > > Log custom event > Show source code > Add observer > Print current state > Show register values > Show memory space values > > Currently I am working on allowing the user to execute an external > script or binary as a further Action. > > If anyone has any suggestions for more Filters or Actions, please let me > know. > > Mike > > > From mcvet@redhat.com Mon Jul 31 20:06:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Mon, 31 Jul 2006 20:06:00 -0000 Subject: Actions and Filters In-Reply-To: <44CE5B7C.809@redhat.com> References: <1154373709.1992.11.camel@towel.toronto.redhat.com> <44CE5B7C.809@redhat.com> Message-ID: <1154376366.1992.25.camel@towel.toronto.redhat.com> On Mon, 2006-07-31 at 14:35 -0500, Phil Muldoon wrote: > The big action I'd like to see (we've talked about this on irc) is to > run an external executable on observer fire. > > This requires thought on: > > 1) any security issues? > 2) executable environment issues? (Or should we, like gnome-panel's just > "run" the executable)? > > The other thing we need to think about with custom actions, it how to > throttle the action to X per Y over time (once per hour for example, > lest we page a sysadmin a thousand times in 10 minutes ;) > > Regards > > Phil Excellent points. The security issue is something I suspect we'll have to talk about as an encompassing project goal anyways. I can't think of anything of anything being done (off of the top of my head) which would be worse running through this Action than anything else through the CLI or Frysk to begin with. But that's how vulnerabilities begin, isn't it? =) As far as the shell environment goes... this has led me to wonder about integration with our Frysk Terminal. Its very likely we'll need a way for the user to set environment variables, or even manipulate the output from their custom script or binary. The fact that output is expected in the first place is an indication that a terminal might be needed somewhere in here. Mike From qiyaoltc@cn.ibm.com Mon Jul 31 20:11:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 31 Jul 2006 20:11:00 -0000 Subject: [patch] Factory for ISA In-Reply-To: <44CA0BFA.6060103@redhat.com> References: <20060728093153.GB8035@GreenHouse.cn.ibm.com> <44CA0BFA.6060103@redhat.com> Message-ID: <20060731111359.GC29289@GreenHouse.cn.ibm.com> On Fri, Jul 28, 2006 at 03:07:06PM +0200, Tim Moore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yao Qi wrote: > > Now, A Factory is needed for LinuxTask to select ISA, and I separate > > ISA selection from LinuxTask.java. > > > > 2006-07-28 Yao Qi > > > > * frysk/proc/LinuxTask.java: Move ISA selection to > > IsaFactory.java and format it via Emacs. > > * frysk/proc/IsaFactory.java: New file. > > > > Rebuild frysk on X86 and X86_64, and tested. > > > > OK to commit? Thanks! > > > This looks fine to me, with two comments: > Please keep the GNU indentation. I couldn't tell you how to do this in > Eclipse :), but there has been some mail about that recently. In Emacs, M-x c-set-stylegnu makes sence. Thanks Tim for reminding me this, :) > > Your IsaFactory should probably be a singleton; no need to create a new > one for each call to sendrecIsa. Yes, you are right! IsaFactory is another singleton. Here are two patches modified per your comments above. Could you have a look? Thanks! -- Yao Qi -------------- next part -------------- --- /dev/null 2006-07-28 20:41:40.430451000 +0800 +++ frysk-core/frysk/proc/IsaFactory.java 2006-07-31 17:06:24.000000000 +0800 @@ -0,0 +1,101 @@ +// This file is part of the program FRYSK. +// +// Copyright 2006, Red Hat Inc. +// +// FRYSK is free software; you can redistribute it and/or modify it +// under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// FRYSK is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with FRYSK; if not, write to the Free Software Foundation, +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// In addition, as a special exception, Red Hat, Inc. gives You the +// additional right to link the code of FRYSK with code not covered +// under the GNU General Public License ("Non-GPL Code") and to +// distribute linked combinations including the two, subject to the +// limitations in this paragraph. Non-GPL Code permitted under this +// exception must only link to the code of FRYSK through those well +// defined interfaces identified in the file named EXCEPTION found in +// the source code files (the "Approved Interfaces"). The files of +// Non-GPL Code may instantiate templates or use macros or inline +// functions from the Approved Interfaces without causing the +// resulting work to be covered by the GNU General Public +// License. Only Red Hat, Inc. may make changes or additions to the +// list of Approved Interfaces. You must obey the GNU General Public +// License in all respects for all of the FRYSK code and other code +// used in conjunction with FRYSK except the Non-GPL Code covered by +// this exception. If you modify this file, you may extend this +// exception to your version of the file, but you are not obligated to +// do so. If you do not wish to provide this exception without +// modification, you must delete this exception statement from your +// version and license this file solely under the GPL without +// exception. + +package frysk.proc; + +import java.util.logging.Level; +import java.util.logging.Logger; + +import lib.elf.Elf; +import lib.elf.ElfCommand; +import lib.elf.ElfEHeader; +import lib.elf.ElfEMachine; +import lib.elf.ElfException; + +import frysk.Config; + +public class IsaFactory +{ + private static IsaFactory factory; + static final Logger logger = Logger.getLogger(Config.FRYSK_LOG_ID); + + static IsaFactory getFactory() + { + if (factory == null) + factory = new IsaFactory (); + return factory; + } + + /** Obtain ISA of task via pid. + */ + public Isa getIsa(int pid) + throws RuntimeException + { + Elf elfFile; + logger.log (Level.FINE, "{0} getIsa\n", this); + + try + { + elfFile = new Elf(pid, ElfCommand.ELF_C_READ); + } + catch (ElfException e) + { + throw (RuntimeException) + (new RuntimeException("getting task's executable").initCause(e)); + } + + ElfEHeader header = elfFile.getEHeader(); + + switch (header.machine) + { + case ElfEMachine.EM_386: + return LinuxIa32.isaSingleton (); + /* + case ElfEMachine.EM_PPC: + return LinuxPpc.isaSingleton (); + case ElfEMachine.EM_PPC64: + return LinuxPpc64.isaSingleton (); + */ + case ElfEMachine.EM_X86_64: + return LinuxEMT64.isaSingleton (); + default: + throw new RuntimeException("Unknown machine type " + header.machine); + } + } +} -------------- next part -------------- Index: frysk-core/frysk/proc/LinuxTask.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxTask.java,v retrieving revision 1.30 diff -u -r1.30 LinuxTask.java --- frysk-core/frysk/proc/LinuxTask.java 20 Jul 2006 15:58:38 -0000 1.30 +++ frysk-core/frysk/proc/LinuxTask.java 31 Jul 2006 09:14:48 -0000 @@ -44,11 +44,7 @@ import frysk.sys.PtraceByteBuffer; import frysk.sys.Sig; import frysk.sys.Signal; -import lib.elf.Elf; -import lib.elf.ElfEMachine; -import lib.elf.ElfCommand; -import lib.elf.ElfEHeader; -import lib.elf.ElfException; + import inua.eio.ByteBuffer; import inua.eio.ByteOrder; import java.util.logging.Level; @@ -57,11 +53,10 @@ * Linux implementation of Task. */ -public class LinuxTask - extends Task +public class LinuxTask extends Task { private long ptraceOptions = 0; - + // XXX: For moment wire in standard 32-bit little-endian memory // map. This will be replaced by a memory map created using // information from /proc/PID/maps. @@ -70,25 +65,27 @@ // XXX: For writing at least, PTRACE must be used as /proc/mem // cannot be written to. memory = new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.DATA, - 0xffffffffl); + 0xffffffffl); memory.order (ByteOrder.LITTLE_ENDIAN); // XXX: For moment wire in a standard 32-bit little-endian // register set. - registerBank = new ByteBuffer[] { - new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.USR) - }; + registerBank = new ByteBuffer[] + { + new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.USR) + }; + registerBank[0].order (ByteOrder.LITTLE_ENDIAN); } - + /** * Create a new unattached Task. */ - LinuxTask (Proc proc, TaskId id) - throws Task.TaskException + LinuxTask (Proc proc, TaskId id) throws Task.TaskException { super (proc, id); setupMapsXXX (); } + /** * Create a new attached clone of Task. */ @@ -98,6 +95,7 @@ super (task, clone); setupMapsXXX (); } + /** * Create a new attached main Task of Proc. */ @@ -107,7 +105,7 @@ super (proc, attached); setupMapsXXX (); } - + /** * Must inject disappeared events back into the event loop so that * they can be processed in sequence. Calling @@ -117,44 +115,52 @@ private void postDisappearedEvent (final Throwable arg) { logger.log (Level.FINE, "{0} postDisappearedEvent\n", this); - Manager.eventLoop.add (new TaskEvent () + Manager.eventLoop.add (new TaskEvent () { - Throwable w = arg; - public void execute () - { - processDisappearedEvent (w); - } + Throwable w = arg; + public void execute () + { + processDisappearedEvent (w); + } }); } - + protected void sendContinue (int sig) { logger.log (Level.FINE, "{0} sendContinue\n", this); - try { - Ptrace.cont (getTid (), sig); - } - catch (Errno.Esrch e) { - postDisappearedEvent (e); - } + try + { + Ptrace.cont (getTid (), sig); + } + catch (Errno.Esrch e) + { + postDisappearedEvent (e); + } } - protected void sendSyscallContinue(int sig){ + + protected void sendSyscallContinue(int sig) + { logger.log(Level.FINE, "{0} sendSyscallContinue\n", this); - try { - Ptrace.sysCall (getTid (), sig); - } - catch (Errno.Esrch e) { - postDisappearedEvent (e); - } + try + { + Ptrace.sysCall (getTid (), sig); + } + catch (Errno.Esrch e) + { + postDisappearedEvent (e); + } } protected void sendStepInstruction (int sig) { logger.log (Level.FINE, "{0} sendStepInstruction\n", this); - try { - Ptrace.singleStep (getTid (), sig); - } - catch (Errno.Esrch e) { - postDisappearedEvent (e); - } + try + { + Ptrace.singleStep (getTid (), sig); + } + catch (Errno.Esrch e) + { + postDisappearedEvent (e); + } } protected void sendStop () { @@ -164,33 +170,38 @@ protected void sendSetOptions () { logger.log (Level.FINE, "{0} sendSetOptions\n", this); - try { - // XXX: Should be selecting the trace flags based on the - // contents of .observers. - ptraceOptions |= Ptrace.optionTraceClone (); - ptraceOptions |= Ptrace.optionTraceFork (); - ptraceOptions |= Ptrace.optionTraceExit (); - // ptraceOptions |= Ptrace.optionTraceSysgood (); not set by default - ptraceOptions |= Ptrace.optionTraceExec (); - Ptrace.setOptions (getTid (), ptraceOptions); - } - catch (Errno.Esrch e) { - postDisappearedEvent (e); - } + try + { + // XXX: Should be selecting the trace flags based on the + // contents of .observers. + ptraceOptions |= Ptrace.optionTraceClone (); + ptraceOptions |= Ptrace.optionTraceFork (); + ptraceOptions |= Ptrace.optionTraceExit (); + // ptraceOptions |= Ptrace.optionTraceSysgood (); not set by default + ptraceOptions |= Ptrace.optionTraceExec (); + Ptrace.setOptions (getTid (), ptraceOptions); + } + catch (Errno.Esrch e) + { + postDisappearedEvent (e); + } } protected void sendAttach () { logger.log (Level.FINE, "{0} sendAttach\n", this); - try { - Ptrace.attach (getTid ()); - } - catch (Errno.Eperm e) { - logger.log (Level.FINE, "{" + e.toString () - + "} Cannot attach to process\n"); - } - catch (Errno.Esrch e) { - postDisappearedEvent (e); - } + try + { + Ptrace.attach (getTid ()); + } + catch (Errno.Eperm e) + { + logger.log (Level.FINE, "{" + e.toString () + + "} Cannot attach to process\n"); + } + catch (Errno.Esrch e) + { + postDisappearedEvent (e); + } } protected void sendDetach (int sig) { @@ -198,37 +209,18 @@ Ptrace.detach (getTid (), sig); } - // Keep this around in an instance variable; it might be useful for - // diggging various things out of the executable. - private Elf elfFile; - - protected Isa sendrecIsa () - throws Task.TaskException + protected Isa sendrecIsa () throws Task.TaskException { logger.log (Level.FINE, "{0} sendrecIsa\n", this); - try - { - elfFile = new Elf(getTid(), ElfCommand.ELF_C_READ); - } - catch (ElfException e) - { - throw (TaskException) - (new TaskException("getting task's executable").initCause(e)); - } - - ElfEHeader header = elfFile.getEHeader(); - // XXX hardcoded until we have a factory for producing Isa objects - if (header.machine == ElfEMachine.EM_386) - { - return LinuxIa32.isaSingleton (); - } - else if (header.machine == ElfEMachine.EM_X86_64) + IsaFactory factory = IsaFactory.getFactory(); + + try { - return LinuxEMT64.isaSingleton (); + return factory.getIsa(id.id); } - else + catch (RuntimeException e) { - throw new TaskException("Unknown machine type " + header.machine); + throw (TaskException) (new TaskException("").initCause(e)); } } @@ -244,5 +236,4 @@ ptraceOptions &= ~(Ptrace.optionTraceSysgood ()); this.sendSetOptions(); } - } From qiyaoltc@cn.ibm.com Tue Aug 1 01:25:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 01 Aug 2006 01:25:00 -0000 Subject: Actions and Filters In-Reply-To: <1154373709.1992.11.camel@towel.toronto.redhat.com> References: <1154373709.1992.11.camel@towel.toronto.redhat.com> Message-ID: <20060801011718.GF29289@GreenHouse.cn.ibm.com> On Mon, Jul 31, 2006 at 03:21:49PM -0400, Mike Cvet wrote: > Hey all, > > I've been working Frysk's Actions and Filters packages for the past > couple days. So far, this has resulted in the ability to raise multiple > Memory and Register windows independently of the SourceWindow via any > number of event Filters (new and old) available in custom observers. > Hi, Mike, it sounds great! Here are some comments about Filters or Actions, and hope they are useful to you. > To summarize; the available Filters are... > Filter by (for both Tasks and Processes, fork()ers and fork()ed): > > Name > Name of parent > Command-line options > Executable path > Exit value descendence of a certain parent. If A forks B, B forks C, system admin would like to see what happened when A start up, so all the descendence of A should be checked. > > Resulting in Actions: > > Log custom event > Show source code > Add observer > Print current state > Show register values > Show memory space values Backtrace the current call stack. > > Currently I am working on allowing the user to execute an external > script or binary as a further Action. > > If anyone has any suggestions for more Filters or Actions, please let me > know. Filters and Actions vary from person to person, and actually, I am still not sure what kind of Filters and Actions are most important to myself. :) However, we could build Actions and Filters framework as scalable as possible, so that new Filters and Actions could be added into easily. -- Yao Qi From npremji@redhat.com Tue Aug 1 17:25:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Tue, 01 Aug 2006 17:25:00 -0000 Subject: Howto add dogtail accessibility to GTK+ widgets. Message-ID: <1154453149.2478.10.camel@to-rhaps5.toronto.redhat.com> Here is how to set up standard widgets so that they can be seen by dogtail. All Gtk widgets have associated accessibility objects. What dogtail needs is for these widgets to be given names so they can be more easily accessed. In order to do this in Gtk C code do the following (assuming the widget you are looking at is called myWidget: GtkWidget * widget = myWidget; AtkObject *myAccessibility = gtk_widget_get_accessibility(widget); atk_object_set_name(myAccessibility, _("My Name")); atk_object_set_description(myAccessibility, _("My Description.")); _("") is for internationalization purposes if you so choose. and that is all dogtail needs to be able to access this widget by name. In terms of java-gnome, the easiest thing to do is to open up the glade file and click on the accessibility tab (far right) and give a name and description. In java-gnome there is also a class called AtkObject under org.gnu.atk. The constructor takes a handle, and it also has setName and setDescription methods. While I have not actually tested this I'm sure the code will look something like this: AtkObject obj = new AtkObject(widget.getHandle()); obj.setName("My Name"); obj.setDescription("My Description"); This should give you accessibility for all standard widgets. From mcvet@redhat.com Tue Aug 1 19:17:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 01 Aug 2006 19:17:00 -0000 Subject: Actions and Filters In-Reply-To: <20060801011718.GF29289@GreenHouse.cn.ibm.com> References: <1154373709.1992.11.camel@towel.toronto.redhat.com> <20060801011718.GF29289@GreenHouse.cn.ibm.com> Message-ID: <1154459827.1992.39.camel@towel.toronto.redhat.com> On Tue, 2006-08-01 at 09:17 +0800, Yao Qi wrote: > Hi, Mike, it sounds great! > Here are some comments about Filters or Actions, and hope they are > useful to you. > > To summarize; the available Filters are... > > Filter by (for both Tasks and Processes, fork()ers and fork()ed): > > > > Name > > Name of parent > > Command-line options > > Executable path > > Exit value > descendence of a certain parent. > If A forks B, B forks C, system admin would like to see what happened > when A start up, so all the descendence of A should be checked. > > Not a bad idea; since filters already exist for the direct parent of a process, checking ancestry as well shouldn't be too much of an extension. I'll generalize for any ancestor older than the direct parent. > > Resulting in Actions: > > > > Log custom event > > Show source code > > Add observer > > Print current state > > Show register values > > Show memory space values > Backtrace the current call stack. > > Good idea! Missed that one completely. I'll be hounding Adam for his backtrace work over the next couple weeks. > Filters and Actions vary from person to person, and actually, I am > still not sure what kind of Filters and Actions are most important to > myself. :) > > However, we could build Actions and Filters framework as scalable as > possible, so that new Filters and Actions could be added into easily. > The scalability of Actions should multiply once the execute-external-binary/script Action is put in place. Then, the user will be able to instantiate any number of custom events via a script they write themselves - however, external to Frysk. As far as adding more Actions and Filters as developers, the interface is fairly straightforward. All that is needed is a new class overriding a couple methods - especially the filter() and execute() methods. From mcvet@redhat.com Tue Aug 1 19:36:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 01 Aug 2006 19:36:00 -0000 Subject: New Session Instantiation Message-ID: <1154460976.1992.54.camel@towel.toronto.redhat.com> An issue that has come up recently is that of a single user being able to run multiple simultaneous session of Frysk. Currently, a second invocation of Frysk when there is already a running instance results in an error message printed to the terminal (or into the abyss, if run from menu) informing the user that Frysk is already running. The currently running session has its MainWindow brought to the foreground. Ideally at some future juncture, this will instead result in a new session of Frysk being run by the same Frysk process. A somewhat more detailed and graphical explanation can be found in this workflow on the Frysk website: http://sourceware.org/frysk/workflow/new_sessions/ This will require a major refactor in the GUI code, since the vast majority of current windows are static singletons - these will require their own factories to be dynamically created. Furthermore, there are likely other issues inherent with running multiple sessions at the same time. There isn't yet a plan or timeframe for this move, but likely within the next couple months. From rmoseley@redhat.com Tue Aug 1 19:40:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Tue, 01 Aug 2006 19:40:00 -0000 Subject: fix for bug 2969 In-Reply-To: <20060731054339.GB29289@GreenHouse.cn.ibm.com> References: <20060731054339.GB29289@GreenHouse.cn.ibm.com> Message-ID: <44CFAE29.7060602@redhat.com> Looks good Yao. I have applied the patch. Thanks a lot. We will look into moving the tests from core around or fixing them some other way. Rick Yao Qi wrote: > libunwind is not supported on ppc/ppc64, so libuwind and its java > bindings could be skipped when build frysk on ppc/ppc64. > > 2006-07-31 Yao Qi > > * frysk-imports/bootstrap.sh: Build libunwind if it is supported. > > Run bootstrap.sh on X86 and PPC64 to verify its output(Makefile.gen), > and libunwind and its java bindings are only built on X86. > > OK to apply? Thanks. > > From npremji@redhat.com Tue Aug 1 20:46:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Tue, 01 Aug 2006 20:46:00 -0000 Subject: Howto add dogtail accessibility to GTK+ widgets. In-Reply-To: <1154453149.2478.10.camel@to-rhaps5.toronto.redhat.com> References: <1154453149.2478.10.camel@to-rhaps5.toronto.redhat.com> Message-ID: <1154465187.2478.13.camel@to-rhaps5.toronto.redhat.com> On Tue, 2006-08-01 at 13:25 -0400, Nurdin Premji wrote: > > In java-gnome there is also a class called AtkObject under org.gnu.atk. > The constructor takes a handle, and it also has setName and > setDescription methods. While I have not actually tested this I'm sure > the code will look something like this: > > AtkObject obj = new AtkObject(widget.getHandle()); > obj.setName("My Name"); > obj.setDescription("My Description"); Sorry that was wrong, you don't use the constructor, instead you use the widgets getAccessible() method. So the code looks like: AtkObject obj = widget.getAccessible(); obj.setName("My Name"); I am in the process of putting this all up on the website, should be up shortly. From pmuldoon@redhat.com Tue Aug 1 20:55:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 01 Aug 2006 20:55:00 -0000 Subject: Howto add dogtail accessibility to GTK+ widgets. In-Reply-To: <1154465187.2478.13.camel@to-rhaps5.toronto.redhat.com> References: <1154453149.2478.10.camel@to-rhaps5.toronto.redhat.com> <1154465187.2478.13.camel@to-rhaps5.toronto.redhat.com> Message-ID: <44CFBFB5.6070008@redhat.com> Do you have to keep reference of the ATK object as long as you keep reference to the Widget object? (I assume so). Regards Phil Nurdin Premji wrote: > On Tue, 2006-08-01 at 13:25 -0400, Nurdin Premji wrote: > > >> In java-gnome there is also a class called AtkObject under org.gnu.atk. >> The constructor takes a handle, and it also has setName and >> setDescription methods. While I have not actually tested this I'm sure >> the code will look something like this: >> >> AtkObject obj = new AtkObject(widget.getHandle()); >> obj.setName("My Name"); >> obj.setDescription("My Description"); >> > > > Sorry that was wrong, you don't use the constructor, instead you use the > widgets getAccessible() method. > > So the code looks like: > > AtkObject obj = widget.getAccessible(); > obj.setName("My Name"); > > I am in the process of putting this all up on the website, should be up > shortly. > > From qiyaoltc@cn.ibm.com Wed Aug 2 05:36:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 02 Aug 2006 05:36:00 -0000 Subject: [patch] Add "-lbfd -liberty" for "-lopcode" only on ppc/ppc64 Message-ID: <20060802052811.GG29289@GreenHouse.cn.ibm.com> As mentioned by Wu in http://sources.redhat.com/ml/frysk/2006-q3/msg00102.html item 2, the workaround for libopcode on ppc/ppc64 is that check the target platform, and add "-lbfd -liberty" for "-lopcode" if the target is ppc or ppc64; if not, nothing changed. 2006-08-02 Yao Qi * m4/frysk_libopcode.m4: New file and define FRYSK_LIBOPCODE. * acinclude.m4: Call FRYSK_LIBOPCODE. * frysk-core/Makefile.am: Append "-lbfd -liberty" per macro USE_LIBOPCODES. * frysk-gui/Makefile.am: Likewise. * frysk-gtk/Makefile.am: Likewise. * frysk-imports/Makefile.am: Likewise. * frysk-sys/Makefile.am: Likewise. We are pleased to make contributions to elfutils to replace binutils/bfd here, but currently, this patch could ensure that frsysk could be built on ppc/ppc64 without applying any our local patches again. Test this patch on PPC64 and X86, OK to commit? Thanks a lot! -- Yao Qi -------------- next part -------------- Index: acinclude.m4 =================================================================== RCS file: /cvs/frysk/frysk-common/acinclude.m4,v retrieving revision 1.52 diff -u -r1.52 acinclude.m4 --- acinclude.m4 30 Jun 2006 17:04:58 -0000 1.52 +++ acinclude.m4 2 Aug 2006 04:59:32 -0000 @@ -133,3 +133,4 @@ test $UUDECODE = no && AC_ERROR([no uudecode program found, please install sharutils package]) FRYSK_USE_LIBUNWIND +FRYSK_LIBOPCODE --- /dev/null 2006-07-28 20:41:40.430451000 +0800 +++ m4/frysk_libopcode.m4 2006-08-02 10:02:26.000000000 +0800 @@ -0,0 +1,48 @@ +# This file is part of the program FRYSK. +# +# Copyright 2006, Red Hat Inc. +# +# FRYSK is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# FRYSK is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with FRYSK; if not, write to the Free Software Foundation, +# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +# +# In addition, as a special exception, Red Hat, Inc. gives You the +# additional right to link the code of FRYSK with code not covered +# under the GNU General Public License ("Non-GPL Code") and to +# distribute linked combinations including the two, subject to the +# limitations in this paragraph. Non-GPL Code permitted under this +# exception must only link to the code of FRYSK through those well +# defined interfaces identified in the file named EXCEPTION found in +# the source code files (the "Approved Interfaces"). The files of +# Non-GPL Code may instantiate templates or use macros or inline +# functions from the Approved Interfaces without causing the +# resulting work to be covered by the GNU General Public +# License. Only Red Hat, Inc. may make changes or additions to the +# list of Approved Interfaces. You must obey the GNU General Public +# License in all respects for all of the FRYSK code and other code +# used in conjunction with FRYSK except the Non-GPL Code covered by +# this exception. If you modify this file, you may extend this +# exception to your version of the file, but you are not obligated to +# do so. If you do not wish to provide this exception without +# modification, you must delete this exception statement from your +# version and license this file solely under the GPL without +# exception. + +AC_DEFUN([FRYSK_LIBOPCODE], [ +AC_REQUIRE([AC_CANONICAL_TARGET]) +case $target_cpu in +i?86|x86_64|ia64) + libopcodes=no;; +*) libopcodes=yes;; +esac +AM_CONDITIONAL([USE_LIBOPCODES], [test $libopcodes = yes]) +]) -------------- next part -------------- Index: frysk-core/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-core/Makefile.am,v retrieving revision 1.57 diff -u -r1.57 Makefile.am --- frysk-core/Makefile.am 13 Jul 2006 01:26:41 -0000 1.57 +++ frysk-core/Makefile.am 2 Aug 2006 05:02:52 -0000 @@ -85,7 +85,11 @@ if USE_LIBUNWIND GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a endif +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -lbfd -liberty +else GEN_GCJ_LDADD += -lopcodes +endif # XXX: This needs to be make less-architecture independant. Index: frysk-gtk/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-gtk/Makefile.am,v retrieving revision 1.18 diff -u -r1.18 Makefile.am --- frysk-gtk/Makefile.am 13 Jul 2006 01:26:42 -0000 1.18 +++ frysk-gtk/Makefile.am 2 Aug 2006 05:02:52 -0000 @@ -61,7 +61,11 @@ if USE_LIBUNWIND GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a endif +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -lbfd -liberty +else GEN_GCJ_LDADD += -lopcodes +endif # Hack, need to compile this entire sub-tree with JNI. AM_GCJFLAGS += -fjni Index: frysk-gui/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-gui/Makefile.am,v retrieving revision 1.62 diff -u -r1.62 Makefile.am --- frysk-gui/Makefile.am 13 Jul 2006 01:26:42 -0000 1.62 +++ frysk-gui/Makefile.am 2 Aug 2006 05:02:53 -0000 @@ -81,8 +81,11 @@ GEN_GCJ_LDADD += -L../frysk-gtk/EggTrayIcon GEN_GCJ_LDADD += -L../frysk-gtk/tlwidgets GEN_GCJ_LDADD += $(FRYSK_GUI_LIBS) +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -lbfd -liberty +else GEN_GCJ_LDADD += -lopcodes - +endif # Skip tests (exit with status 77) when there is no display. TESTS_ENVIRONMENT = ( test x"$$DISPLAY" != x || sh -c "exit 77" ) && Index: frysk-imports/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-imports/Makefile.am,v retrieving revision 1.62 diff -u -r1.62 Makefile.am --- frysk-imports/Makefile.am 13 Jul 2006 01:26:41 -0000 1.62 +++ frysk-imports/Makefile.am 2 Aug 2006 05:02:54 -0000 @@ -85,7 +85,11 @@ GEN_GCJ_LDADD += ./libunwind/src/libunwind-$(libunwind_cpu).a endif +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -lbfd -liberty +else GEN_GCJ_LDADD += -lopcodes +endif all-local: lib/elf/tests/test-core lib/elf/tests/helloworld.o Index: frysk-sys/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-sys/Makefile.am,v retrieving revision 1.27 diff -u -r1.27 Makefile.am --- frysk-sys/Makefile.am 13 Jul 2006 01:26:41 -0000 1.27 +++ frysk-sys/Makefile.am 2 Aug 2006 05:02:54 -0000 @@ -59,4 +59,8 @@ if USE_LIBUNWIND GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a endif +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -lbfd -liberty +else GEN_GCJ_LDADD += -lopcodes +endif From npremji@redhat.com Wed Aug 2 14:29:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Wed, 02 Aug 2006 14:29:00 -0000 Subject: Howto add dogtail accessibility to GTK+ widgets. In-Reply-To: <44CFBFB5.6070008@redhat.com> References: <1154453149.2478.10.camel@to-rhaps5.toronto.redhat.com> <1154465187.2478.13.camel@to-rhaps5.toronto.redhat.com> <44CFBFB5.6070008@redhat.com> Message-ID: <1154528962.2465.5.camel@to-rhaps5.toronto.redhat.com> On Tue, 2006-08-01 at 15:55 -0500, Phil Muldoon wrote: > Do you have to keep reference of the ATK object as long as you keep > reference to the Widget object? (I assume so). > > Regards > > Phil >From what I understand the widgets already have a reference to their own accessibility object. All you are doing is accessing the widgets ally object and setting a new name. So the AtkObject obj is just a second reference that you can discard after you've set the name. From npremji@redhat.com Wed Aug 2 15:24:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Wed, 02 Aug 2006 15:24:00 -0000 Subject: Eventviewer refactors. Message-ID: <1154532287.2465.36.camel@to-rhaps5.toronto.redhat.com> A number of refactoring ideas for the eventviewer and the frysk monitor have come up from yesterdays status meeting. Here is a break down of these ideas and options. 1. Having an "all" processes view, so that users can see the interactions between different processes. Easiest method is to add an "all" selection to the process tree. (Assuming more than one process) I believe I did some work on this before. One minor issue is that I have no idea what to put for the PID column. Ideally I would leave it blank, but I don't think I can do that (it defaults to 0? Which would just be lying). 2.0 Removing the proc/thread tree and just having the eventviewer and main log. This would look something like the attachment frysk-monitor-no-tree-view.png. This would be a large refactor as I would have to implement selecting traces in the eventviewer in order to add right-click (secondary-click for us left-handed people) menus to the traces themselves rather than in the tree-views. In order to do this, we need some method of viewing individual processes as well as the "big picture". Option A is to have tabs, since the status widget is enclosed in a notebook anyway, we can have multiple tabs, one for each process and one for the "all" process mentioned above. Option B is a little more complicated. We create just one status widget with all of the processes, and allow the user to zoom in and re-arrange processes, adjusting the size of each trace (and the number shown on screen) and the order they are shown. 2.1 Removing just the thread tree view, would look like frysk-monitor-proc-tree-view.png So now for a show of opinions: 1. "All" process in process tree view: Yes or No, If no is there a better way of showing the "big picture"? 2. Removing proc/thread view: Yes or No: If yes, replace with: A) Tabs B) Zooms If no, should we go with 2.1? And my opinions: 1. Yes 2. Yes, replace with tabs at first, then zooms. -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-monitor-no-tree-view.png Type: image/png Size: 28704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-monitor-with-tree-view.png Type: image/png Size: 43684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-monitor-proc-tree-view.png Type: image/png Size: 43829 bytes Desc: not available URL: From pmuldoon@redhat.com Wed Aug 2 16:20:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 02 Aug 2006 16:20:00 -0000 Subject: Eventviewer refactors. In-Reply-To: <1154532287.2465.36.camel@to-rhaps5.toronto.redhat.com> References: <1154532287.2465.36.camel@to-rhaps5.toronto.redhat.com> Message-ID: <44D0D0AB.90602@redhat.com> Thanks Nurdin for these viewpoints. They illustrate some great examples of lateral thinking in terms of presentation, and how we can change that presentation to the user. However, first we need to answer: what is the identified need for these work-flows, and justification? User? Personal thoughts? Meeting of minds somewhere? We have to get our story straight on why we need these changes. Why do we need to get rid of the process view? Why do we need to mix thread and processes together? And so on. So without further ado, my comments: > 1. Having an "all" processes view, so that users can see the > interactions between different processes. Easiest method is to add an > "all" selection to the process tree. (Assuming more than one process) I > believe I did some work on this before. One minor issue is that I have > no idea what to put for the PID column. Ideally I would leave it blank, > but I don't think I can do that (it defaults to 0? Which would just be > lying). > I feel we might as well get rid of sessions entirely then, because it basically defeats that work-flow. What's the point of going through a session at all? To perhaps answer this question myself, I could see a toggle where you flipped between full process view and session targeted view. But I'm worried we have been spending a lot of time evolving sessions so that user can narrow down their focus on a directed UI, and now we are just blowing it open. Question to answer: 1) Why do we need this? 2) What purpose will an all process view serve? Add things back into a session view? 3) If 2 is correct, do we save any changes? Are they session bound? 4) Given the whole process view, do you anticipate mixing in threads? 5) if 4) what additional value will mixing in thread serve over having them separate 6) in 4) how will we handle large thread producing programs? If we can answer these questions, then I think this work-flow might work pretty well. However ... > > 2.0 Removing the proc/thread tree and just having the eventviewer and > main log. This would look something like the attachment > frysk-monitor-no-tree-view.png. > > This would be a large refactor as I would have to implement selecting > traces in the eventviewer in order to add right-click (secondary-click > for us left-handed people) menus to the traces themselves rather than > in the tree-views. > I find the screen-shot non-intuitive, and confusing. I completely disagree with this. Arguments have been made that sessions should have PIDs because engineers are used to working with PIDS. In this scenario we remove PIDS and existing process names. How do we switch between processes? When the user is presented with this view, what are they supposed to do? 1) What would removing the process tree achieve? 2) The thread view will soon have more information that it does now. I'd say remove the thread view until then. Perhaps to better answer my objections some further thoughts. Personally right now I think we should be spending our effort making the event-viewer better. Perhaps then we can address these questions. Things like: 1) Grid 2) Selecting traces 3) Orientation vertical/horizontal 4) Scalability and zoom during a user defined time period I think then, we can answer these work-flow questions more clearly because then we have a clearer picture on how we want to display the data that is being presented. I think these refactor's are a bit premature, especially in light of the others we are looking at detailed below. There are already several thoughts in place, and I think we should answer these first. Also it's been my practice to integrate choices in the UI. When I rewrote the Debug Single Process launcher, I had feedback that people wanted PIDs right aligned, that sorting was suspect, and column order was wrong. I designed the next UI with those flaws in mind and came up with: 1) A separate column for PIDs 2) Columns you can drag and order as you like 3) Ascending and Descending sort on any column. Ideally, in presentation, I'm moving toward giving the user a choice. Ultimately I think we should allow the user to hide the process tree-view, or hide the thread tree-view, and maximize the event-viewer. Or size them and place them as they wish. The issues I am looking at right now. 1) Multiple sessions running at once (WindowManager rewrite) 2) Workflow disconnect between launch a session and monitor With 2) Right now we dump the user in the monitor from the session with no hint as to what to do next? Where to go? What to click on? Where should we go? Regards Phil > 2.1 Removing just the thread tree view, would look like > frysk-monitor-proc-tree-view.png > > > So now for a show of opinions: > > 1. "All" process in process tree view: Yes or No, If no is there a > better way of showing the "big picture"? > > 2. Removing proc/thread view: Yes or No: > If yes, replace with: > A) Tabs > B) Zooms > If no, should we go with 2.1? > > And my opinions: > 1. Yes > 2. Yes, replace with tabs at first, then zooms. > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > From woodzltc@cn.ibm.com Thu Aug 3 02:21:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 03 Aug 2006 02:21:00 -0000 Subject: Fwd: Re: [libunwind] status of x86_64 Message-ID: <20060802221915.t276ok0tgkk0sckw@imap.linux.ibm.com> Some information about libunwind. It seems that they are working on improving libunwind, in different branches though. Do we have any plan to merge with their changes? Just be curious. :-) ----- Forwarded message from arun.sharma@google.com ----- Date: Wed, 02 Aug 2006 12:23:25 -0700 From: Arun Sharma Reply-To: Arun Sharma Subject: Re: [libunwind] status of x86_64 To: George Lowe Cc: libunwind@napali.hpl.hp.com George Lowe wrote: > What is the current state of support for x86_64? > > I note that the most recent version is 0.98.5, > from April 2005. If I understand correctly, > some patches for x86_64 have been proposed. > I have the following additional questions: > > What is the state of these patches? > How are they bundled? > Does one need to apply a series of patches, > or have the patches been collected into one > large patch? They're currently in this mercurial repository. http://www.serpentine.com/~arun/ http://www.serpentine.com/~arun/libunwind/releases/libunwind-0.98.6-test1.tar.gz > Will these patches be integrated into > the libunwind code? davidm has reviewed most of them. There are a couple that are still under review. > Can the x86_64 version be built as a > static library to be used by a program > for introspective purposes? Yes. I would suggest compiling them with libatomic ops, for better performance. http://goog-perftools.sourceforge.net/ has a tool called pprof which does basically this. > Does the x86_64 version work with statically > linked programs? Not yet. With glibc_2.3.3 we're a step closer (dl_iterate_phdr works for statically linked programs). But libunwind can't get to the .eh_frame section needed to get the dwarf unwinding information. I'm trying to work out an interface with the gcc folks so libunwind can get to this info. -Arun _______________________________________________ libunwind mailing list libunwind@linux.hpl.hp.com http://www.hpl.hp.com/hosted/linux/mail-archives/libunwind/ ----- End forwarded message ----- Regards - Wu Zhou From woodzltc@cn.ibm.com Thu Aug 3 02:28:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 03 Aug 2006 02:28:00 -0000 Subject: fix for bug 2969 In-Reply-To: <44CFAE29.7060602@redhat.com> References: <20060731054339.GB29289@GreenHouse.cn.ibm.com> <44CFAE29.7060602@redhat.com> Message-ID: <20060802222822.nocdr4q6q888skwc@imap.linux.ibm.com> Quoting Rick Moseley : > Looks good Yao. I have applied the patch. Thanks a lot. > > We will look into moving the tests from core around or fixing them some > other way. Hi Rick, Did you work out any available ways right now? In our opinion, it is easiest to merge these libunwind dependent code into a same directory, to say, frysk-imports/lib/unwind. In this way, you can continue to do anything you like on x86 and x86_64. and don't impact the building of frysk on ppc64. And I also believe it is easy to re-arrange these code when libunwind is ready for ppc64. What is your thought? Eager to know your thought on this. > Rick > > Yao Qi wrote: >> libunwind is not supported on ppc/ppc64, so libuwind and its java >> bindings could be skipped when build frysk on ppc/ppc64. >> >> 2006-07-31 Yao Qi >> >> * frysk-imports/bootstrap.sh: Build libunwind if it is supported. >> >> Run bootstrap.sh on X86 and PPC64 to verify its output(Makefile.gen), >> and libunwind and its java bindings are only built on X86. >> >> OK to apply? Thanks. >> >> Regards - Wu Zhou From woodzltc@cn.ibm.com Thu Aug 3 02:35:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 03 Aug 2006 02:35:00 -0000 Subject: [patch] Add "-lbfd -liberty" for "-lopcode" only on ppc/ppc64 In-Reply-To: <20060802052811.GG29289@GreenHouse.cn.ibm.com> References: <20060802052811.GG29289@GreenHouse.cn.ibm.com> Message-ID: <20060802223519.qya6lygxs0cg8g8c@imap.linux.ibm.com> Any comments on this patch? It is frustrated to find that we can't build frysk on our platforms each time we check out the cvs tree. :-) We believe this is a general solution at this time, if we are still planning to use opcode in frysk. Any long term dicision made on this? Thanks. Quoting Yao Qi : > As mentioned by Wu in > http://sources.redhat.com/ml/frysk/2006-q3/msg00102.html > item 2, the workaround for libopcode on ppc/ppc64 is that check the > target platform, and add "-lbfd -liberty" for "-lopcode" if the target > is ppc or ppc64; if not, nothing changed. > > 2006-08-02 Yao Qi > > * m4/frysk_libopcode.m4: New file and define FRYSK_LIBOPCODE. > * acinclude.m4: Call FRYSK_LIBOPCODE. > > * frysk-core/Makefile.am: Append "-lbfd -liberty" per macro USE_LIBOPCODES. > * frysk-gui/Makefile.am: Likewise. > * frysk-gtk/Makefile.am: Likewise. > * frysk-imports/Makefile.am: Likewise. > * frysk-sys/Makefile.am: Likewise. > > We are pleased to make contributions to elfutils to replace > binutils/bfd here, but currently, this patch could ensure that frsysk > could be built on ppc/ppc64 without applying any our local patches > again. > > Test this patch on PPC64 and X86, OK to commit? Thanks a lot! > > -- > Yao Qi > Regards - Wu Zhou From timoore@redhat.com Thu Aug 3 10:20:00 2006 From: timoore@redhat.com (Tim Moore) Date: Thu, 03 Aug 2006 10:20:00 -0000 Subject: NullPointerException in LinuxHost.PollWaitOnSigChld..terminated Message-ID: <44D1CE05.9070909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In my new test TestX8664Regs I was getting a null pointer exception in the above method. I've added an explicit test for the null pointer and ignoring it doesn't seem to break anything, but I'm wondering about the implications. Does the test not initialize the event loop properly? Is it expected that we could get events for tasks that we don't "know" about? Thanks, Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE0c4FeDhWHdXrDRURAnOOAKCri7UHVCa5MXebZQXgbak5PcErogCgjsQf XEAhCap6+7etsWb830PtXLc= =B2OO -----END PGP SIGNATURE----- From cagney@redhat.com Thu Aug 3 14:15:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 03 Aug 2006 14:15:00 -0000 Subject: NullPointerException in LinuxHost.PollWaitOnSigChld..terminated In-Reply-To: <44D1CE05.9070909@redhat.com> References: <44D1CE05.9070909@redhat.com> Message-ID: <44D204F2.2090005@redhat.com> As far as I know it shouldn't get a null pointer, do you know where it is coming from? Tim Moore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > In my new test TestX8664Regs I was getting a null pointer exception in > the above method. I've added an explicit test for the null pointer and > ignoring it doesn't seem to break anything, but I'm wondering about the > implications. Does the test not initialize the event loop properly? Is > it expected that we could get events for tasks that we don't "know" about? > > Thanks, > Tim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.4 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFE0c4FeDhWHdXrDRURAnOOAKCri7UHVCa5MXebZQXgbak5PcErogCgjsQf > XEAhCap6+7etsWb830PtXLc= > =B2OO > -----END PGP SIGNATURE----- > From cagney@redhat.com Thu Aug 3 14:24:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 03 Aug 2006 14:24:00 -0000 Subject: ForkedProcess (Was: Kill and refresh) In-Reply-To: <1154003024.2977.1.camel@dijkstra.wildebeest.org> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> <1152879437.2529.31.camel@elsschot.wildebeest.org> <1152881355.2529.41.camel@elsschot.wildebeest.org> <1154003024.2977.1.camel@dijkstra.wildebeest.org> Message-ID: <44D20733.5000406@redhat.com> Mark Wielaard wrote: > Hi, > > On Fri, 2006-07-14 at 14:49 +0200, Mark Wielaard wrote: > >> On Fri, 2006-07-14 at 14:17 +0200, Mark Wielaard wrote: >> >>> Yes, I actually have an addition to Fork which just gives you an >>> Input/OutputStream to the process to communicate with. I found that a >>> little more convenient then using signals. I'll post it to the list so >>> you can see if that is something we might want to add. >>> >> Here it is. I found it useful to write some quick tests which needed to >> exchange information with the child process without needing to attach to >> the process or send signals between frysk and the child process. >> Two thoughts come to mind: - we've a mechanism for communicating between frysk and a debug process using signals, rather than introducing custom mechanisms, can something based or following the existing technique be used? - since it is only intended for testing and testing fork, can this live in TestLib - keeps frysk.sys's interfaces as close as possible to the underlying mechanism? This code can't be plugged into frysk's event loop (I/O Stream can't be integrated into frysk.sys.Poll) so really isn't part of the core. Andrew >> 2006-07-14 Mark Wielaard >> >> * Fork.java (ForkedProcess): New static inner class. >> (ForkedInputStream): Likewise. >> (ForkedOutputStream): Likewise. >> (ForkedProcess): New static method. >> * cni/Fork.cxx (fork): New method. >> (ForkedOutputStream::write): Likewise. >> (ForkedInputStream::read(void)): Likewise. >> (ForkedInputStream::read(jbyteArray,jint,jint)): Likewise. >> >> At first I used Runtime.exec() for this, but since that spawns a new >> Thread that tries to wait() on all processes that didn't work nicely >> with the rest of frysk core. >> >> Would it make sense to add this new functionality to Fork? >> > > Since I am using this for writing new tests I would like it to be added. > OK? > > Cheers, > > Mark > > From cagney@redhat.com Thu Aug 3 14:35:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 03 Aug 2006 14:35:00 -0000 Subject: logger domain name change Message-ID: <44D209B8.3080808@redhat.com> Just a heads up. I'm about to go through the loggers, fixing a long standing bug, giving them a proper name space structure. For instance, log messages from frysk.proc will be moved to the "frysk.proc" domain, similarly for "frysk.gui". The "-l FINE" TestRunner option will then just manipulate the "frysk" domain getting expected behavior. Andrew From cagney@redhat.com Thu Aug 3 14:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 03 Aug 2006 14:38:00 -0000 Subject: PTraceByteBuffer vs errno In-Reply-To: <1153234389.2531.20.camel@elsschot.wildebeest.org> References: <1153234389.2531.20.camel@elsschot.wildebeest.org> Message-ID: <44D20A52.1000501@redhat.com> Mark Wielaard wrote: > Hi, > > While investigating some strange RuntimeExceptions (indicating > interrupted system calls) coming from PTraceByteBuffer I noticed that it > does its own errno handling when calling the Ptrace class. This seems > incorrect since Ptrace a) does its own errno handling and will throw the > appropriate exception when errno is set and b) Ptrace is not just a > simple call, but a complex chaining of calls through multiple threads so > the errno value set might not be related at all to the original errno > call. So I propose to remove all errno handling from PtraceByteBuffer. > This also made my local breakpoint tests become more predictable. > I'm draining my mail backlog. Mark, yes definitely, good catch (I'm assuming this was committed). Andrew From cagney@redhat.com Thu Aug 3 15:05:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 03 Aug 2006 15:05:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <1153480682.22872.9.camel@elsschot.wildebeest.org> References: <20060720155840.24856.qmail@sourceware.org> <1153480682.22872.9.camel@elsschot.wildebeest.org> Message-ID: <44D210A7.5090501@redhat.com> Mark Wielaard wrote: > Hi Tim, > > On Thu, 2006-07-20 at 15:58 +0000, moore@sourceware.org wrote: > >> Throw a TaskException from some methods in Task. This is not a >> RuntimeException, so fix all the affected callers too. >> FYI, frysk has been intentionally using RuntimeExceptions. Test coverage is responsible for demonstrating that potential exceptions are correctly handled and that they can occur. <> discusses this: First, it??s worth noting that Java effectively invented the checked exception (clearly inspired by C++ exception specifications and the fact that C++ programmers typically don??t bother with them). It has been an experiment, which no language since has chosen to duplicate. Andrew > > I like it. Now I actually have to look and think what to do in some > nasty cases where the Task can actually have "disappeared". Now > scratching my head how to improve my code to better handle some things. > Good stuff. > > One question. Why is the Exception a non-static inner class of Task? > This means it does have a reference to its enclosing Task (which most > likely is the Task that is in trouble), but it isn't easy to get access > to it. And on the other hand you probably know very well which Task it > is about because that is the Task you were just manipulating. Would it > make sense to make this either static or a "stand-alone" Exception > class? (/me is a bit biased against inner classes since the scoping and > whether or not they have outer context are always so confusing). > > Cheers, > > Mark > > > From npremji@redhat.com Thu Aug 3 20:07:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Thu, 03 Aug 2006 20:07:00 -0000 Subject: EventViewer accessibility part 2: Traces Message-ID: <1154635653.14021.9.camel@to-rhaps5.toronto.redhat.com> Dogtail and sniff can now see both markers and traces. The final (?) step is to get events to be seen, although that seems a little more complicated as I try to figure out how to parent events to traces rather than the eventviewer. For now however I think there is quite a bit of accessibility for testing purposes and I'm going to move on to getting a "google finance" like scrollbar widget for the eventviewer, unless people really need event testing support. Anyhow here is a nice screenshot of what sniff sees: -------------- next part -------------- A non-text attachment was scrubbed... Name: sniff3markers Type: image/png Size: 27496 bytes Desc: not available URL: From timoore@redhat.com Fri Aug 4 06:53:00 2006 From: timoore@redhat.com (Tim Moore) Date: Fri, 04 Aug 2006 06:53:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <44D210A7.5090501@redhat.com> References: <20060720155840.24856.qmail@sourceware.org> <1153480682.22872.9.camel@elsschot.wildebeest.org> <44D210A7.5090501@redhat.com> Message-ID: <44D2EEE5.8000504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Cagney wrote: > Mark Wielaard wrote: >> Hi Tim, >> >> On Thu, 2006-07-20 at 15:58 +0000, moore@sourceware.org wrote: >> >>> Throw a TaskException from some methods in Task. This is not a >>> RuntimeException, so fix all the affected callers too. >>> > FYI, frysk has been intentionally using RuntimeExceptions. Test coverage > is responsible for demonstrating that potential exceptions are correctly > handled and that they can occur. > > < Perspectives>> discusses this: > First, it??s worth noting that Java effectively invented the checked > exception (clearly inspired by C++ exception specifications and the fact > that C++ programmers typically don??t bother with them). It has been an > experiment, which no language since has chosen to duplicate. > > Andrew When I introduced TaskException I made a fairly conscious choice to derive it from Exception and RuntimeException. My reasoning went like this: reading a task's Elf file can provoke various errors, all of which prevent the creation of the proper ISA object for the task and therefore prevent the creation of a valid task object; this is a serious error and needs to be recognized by whoever is trying to create the task, but it is certainly not so serious that Frysk needs to die. Since the Frysk code base is becoming fairly complex, using a checked exception here allowed me to discover what methods should be handling this condition by using the compiler (I suppose "grep" could be an option also). If callers above the level of task creation want to swallow the error or turn it into a runtime exception, that's there choice, but at least I've given them a tool to do something more rigorous. I'm sensitive to concerns about verbosity in the code dealing with errors; my favorite language has a rich condition / error system and doesn't have checked exceptions either. However, it seems to me that the TIJ argument focuses on exploding try/catch clauses and ignores the alternative: design a reasonable object model for the application's exceptions and use the throws declarations for methods intelligently to both document possible exception conditions and pass responsibility up the call chain. This enforced documentation of possible error conditions would seem useful in a system where documentation is pretty scanty, but if a harried developer doesn't want to think about it he can just write "throws FryskCoreException" or whatever and move on. As far as using tests to ensure proper exception handling, how's that going? (Note: this isn't meant to be sarcastic :) I just want to learn more about the Frysk testing strategy). Without thinking about it too much or knowing the technology, these kinds of tests would seem to require an large amount of programmer discipline and time. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE0u7leDhWHdXrDRURAiaVAJ0dzJlt7nwyS18lzI4fEMDiz07oFACcDVkQ c+/RjvdZ+wk0NQtunWGCPac= =VHoh -----END PGP SIGNATURE----- From zhengyzy@cn.ibm.com Fri Aug 4 09:28:00 2006 From: zhengyzy@cn.ibm.com (Yong Zheng) Date: Fri, 04 Aug 2006 09:28:00 -0000 Subject: Fw: NullPointerException in LinuxHost.PollWaitOnSigChld..terminated In-Reply-To: References: Message-ID: <1154683380.17254.7.camel@YZ_X86_64> It's strange. The new test TestX8664Regs runs ok in our X86-64 machine. The following is the test result: Running testX8664Regs(frysk.proc.TestX8664Regs) ...29700.29700: argv[0]=/rtos/source/frysk/build_cvs/frysk-core/frysk/pkglibexecdir/funit-child 29700.29700: argv[1]=--wait=suspend 29700.29700: argv[2]=10 29700.29700: argv[3]=28766 29700.29700: argv[4]=/rtos/source/frysk/build_cvs/frysk-core/frysk/pkglibexecdir/funit-x8664-regs 29700.29700: starting 29700 29700.29700: new thread 29700.29700 29700.29700: notify 28766 with 10 (User defined signal 1) -- new thread 29700.29700 29700.29700: received signal 30 (Power failure) 29700.29700: exec 29700.29700: execing /rtos/source/frysk/build_cvs/frysk-core/frysk/pkglibexecdir/funit-x8664-regs argv[0]=/rtos/source/frysk/build_cvs/frysk-core/frysk/pkglibexecdir/funit-x8664-regs ... PASS PS: the frysk code is checked out today. On Fri, 2006-08-04 at 17:17 +0800, Tim wrote: > > Hi, > In my new test TestX8664Regs I was getting a null pointer exception in > the above method. I've added an explicit test for the null pointer > and > ignoring it doesn't seem to break anything, but I'm wondering about > the > implications. Does the test not initialize the event loop properly? Is > it expected that we could get events for tasks that we don't "know" > about? > > Thanks, > Tim From qiyaoltc@cn.ibm.com Fri Aug 4 10:14:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 04 Aug 2006 10:14:00 -0000 Subject: [small patch] Replace "ppc" with "powerpc" in TestOpcodes.java Message-ID: <20060804100447.GA2347@GreenHouse.cn.ibm.com> When verify Bug#2712, I find TestOpcodes fail on ppc64. This small patch replace "ppc" with "powerpc" to match Build.BUILD_ARCH, and TestOpcodes could be skipped if this patch applied on ppc64. 2006-08-04 Yao Qi * lib/opcodes/tests/TestOpcodes.java: Replace "ppc" with "powerpc" to match Build.BUILD_ARCH. OK to apply? Thanks! -- Yao Qi Index: frysk-imports/lib/opcodes/tests/TestOpcodes.java =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/opcodes/tests/TestOpcodes.java,v retrieving revision 1.8 diff -u -r1.8 TestOpcodes.java --- frysk-imports/lib/opcodes/tests/TestOpcodes.java 31 Jul 2006 20:40:24 -0000 1.8 +++ frysk-imports/lib/opcodes/tests/TestOpcodes.java 4 Aug 2006 09:09:27 -0000 @@ -88,7 +88,7 @@ public void testDisassembler () { - if (Build.BUILD_ARCH.indexOf("ppc") != - 1) + if (Build.BUILD_ARCH.indexOf("powerpc") != - 1) { if (brokenPpcXXX(2712)) return; From mark@klomp.org Fri Aug 4 12:11:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 04 Aug 2006 12:11:00 -0000 Subject: ForkedProcess (Was: Kill and refresh) In-Reply-To: <44D20733.5000406@redhat.com> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> <1152879437.2529.31.camel@elsschot.wildebeest.org> <1152881355.2529.41.camel@elsschot.wildebeest.org> <1154003024.2977.1.camel@dijkstra.wildebeest.org> <44D20733.5000406@redhat.com> Message-ID: <1154693489.2982.38.camel@dijkstra.wildebeest.org> Hi Andrew, On Thu, 2006-08-03 at 10:24 -0400, Andrew Cagney wrote: > >> Here it is. I found it useful to write some quick tests which needed to > >> exchange information with the child process without needing to attach to > >> the process or send signals between frysk and the child process. > >> > Two thoughts come to mind: > > - we've a mechanism for communicating between frysk and a debug process > using signals, rather than introducing custom mechanisms, can something > based or following the existing technique be used? Sure, I just found it a lot simpler to just use stdin/out. The passing back and forth of signals feels a little awkward and means you have to be careful that it doesn't interfere with the main frysk event loop. It seems you keep starting/stopping/draining the event queue in that scheme. Using stdin/out with the test programs makes it a little easier to write tests in one flow with the core frysk event loop just running. > - since it is only intended for testing and testing fork, can this live > in TestLib - keeps frysk.sys's interfaces as close as possible to the > underlying mechanism? Can do. Will move it to TestLib. It was just so similar to the rest of the Fork class that it seemed natural to put it there. > This code can't be plugged into frysk's event loop (I/O Stream can't be > integrated into frysk.sys.Poll) so really isn't part of the core. OK. For the tests the idea was indeed to have it explicitly not be part of the event loop so it doesn't interfere with it. Cheers, Mark From mark@klomp.org Fri Aug 4 13:04:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 04 Aug 2006 13:04:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog StressMapRead.ja ... In-Reply-To: <20060802182624.29409.qmail@sourceware.org> References: <20060802182624.29409.qmail@sourceware.org> Message-ID: <1154696667.2982.51.camel@dijkstra.wildebeest.org> Hi Adam, On Wed, 2006-08-02 at 18:26 +0000, ajocksch@sourceware.org wrote: > 2006-08-02 Adam Jocksch > > * StressMapRead.java: Renamed from TestMapRead since the test > is very cpu-intensive, also enabled test. It is a very thorough test. But it really takes ages to run. On my machine it tries to get every single byte in a couple of process maps with addresses like: Lowest : 2aaaaaac9000 Highest: 2aaaade98000 There are multiple maps like that. And getting all these through ptrace is just incredibly slow (around 0x10000 bytes per second). I let it run for half an hour but then just gave up. Is there any way to test the functionality you are after without having to push such an enormous amount of memory through ptrace? Thanks, Mark From mark@klomp.org Fri Aug 4 13:06:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 04 Aug 2006 13:06:00 -0000 Subject: PTraceByteBuffer vs errno In-Reply-To: <44D20A52.1000501@redhat.com> References: <1153234389.2531.20.camel@elsschot.wildebeest.org> <44D20A52.1000501@redhat.com> Message-ID: <1154696790.2982.52.camel@dijkstra.wildebeest.org> On Thu, 2006-08-03 at 10:38 -0400, Andrew Cagney wrote: > Mark, yes definitely, good catch (I'm assuming this was committed). It is committed now. Thanks for the review. Cheers, Mark From mark@klomp.org Fri Aug 4 13:28:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 04 Aug 2006 13:28:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <44D2EEE5.8000504@redhat.com> References: <20060720155840.24856.qmail@sourceware.org> <1153480682.22872.9.camel@elsschot.wildebeest.org> <44D210A7.5090501@redhat.com> <44D2EEE5.8000504@redhat.com> Message-ID: <1154698065.2982.64.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-08-04 at 08:53 +0200, Tim Moore wrote: > I'm sensitive to concerns about verbosity in the code dealing with > errors; my favorite language has a rich condition / error system and > doesn't have checked exceptions either. However, it seems to me that the > TIJ argument focuses on exploding try/catch clauses and ignores the > alternative: design a reasonable object model for the application's > exceptions and use the throws declarations for methods intelligently to > both document possible exception conditions and pass responsibility up > the call chain. This enforced documentation of possible error conditions > would seem useful in a system where documentation is pretty scanty, but > if a harried developer doesn't want to think about it he can just write > "throws FryskCoreException" or whatever and move on. The documentation aspect and the fact that the compiler can help me when writing new code in a large existing framework is why I am a fan of Checked Exceptions. The main problem I am encountering when trying to grok and hack on frysk is that there is no clear distinction between unrecoverable or programming errors and recoverable errors. Since both of these map onto unchecked exceptions I am often at a loss whether I made an error, supplied wrong parameters somewhere, or there was are real error, the process we tried to investigate disappeared. I do appreciate that the verbosity of the code goes up a little. But the argument that "a lazy programmer" might just throw away an checked exception and then it is "gone" doesn't sit well with me. That is why we have code reviews "heay! why do you just throw away that exception there?". And the documentation value and compiler helping me detect error handling conditions do seem to outweigh the disadvantage of a little extra code for exception handling. Since we have exception chaining it is even easy to wrap a exception from one domain to another if it really needs to cross module boundaries. All that said I do see why introducing checked exceptions is a bit of a pain. I am currently working in the state machine, and whenever I need access to the Isa now I need to handle the error condition since none of the state machine interfaces handle the new TaskException. Refactoring all interfaces to pass these through is not hard, but does mean a large change to a lot of the proc code. I am not sure we want that at this time when multiple people are hacking on it. The alternative is as Eckle suggest to just turn them all into RuntimeExceptions whenever you don't know how to handle them. But then we immediately loose all advantages again. Cheers, Mark From scox@redhat.com Fri Aug 4 14:51:00 2006 From: scox@redhat.com (Stan Cox) Date: Fri, 04 Aug 2006 14:51:00 -0000 Subject: [patch request] don't run ecj on auto generated files In-Reply-To: <44CA8697.60806@redhat.com> References: <44C94D19.3090803@redhat.com> <44CA1638.2070905@redhat.com> <44CA8697.60806@redhat.com> Message-ID: <44D35F6D.2040605@redhat.com> I just stuck with the sed approach. I rewrote CppParser.sed and CppTreeParser.sed so that they are hopefully easier to understand, assuming of course that sed scripts can be understood. Tested with a clean build, but if you encounter a problem ping me on irc so I can tweak the sed scripts. From rmoseley@redhat.com Fri Aug 4 14:55:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Fri, 04 Aug 2006 14:55:00 -0000 Subject: fix for bug 2969 In-Reply-To: <20060731121724.GE29289@GreenHouse.cn.ibm.com> References: <20060731054339.GB29289@GreenHouse.cn.ibm.com> <20060731121724.GE29289@GreenHouse.cn.ibm.com> Message-ID: <44D35FE6.5020602@redhat.com> Yao Qi wrote: > On Mon, Jul 31, 2006 at 01:43:41PM +0800, Yao Qi wrote: > >> libunwind is not supported on ppc/ppc64, so libuwind and its java >> bindings could be skipped when build frysk on ppc/ppc64. >> >> 2006-07-31 Yao Qi >> >> * frysk-imports/bootstrap.sh: Build libunwind if it is supported. >> >> Run bootstrap.sh on X86 and PPC64 to verify its output(Makefile.gen), >> and libunwind and its java bindings are only built on X86. >> >> OK to apply? Thanks. >> >> > > Files in frysk-core/frysk/rt/ also do some java bindings for libunwind, > and this patch could not cover it. > > Could we put these libunwind java bindings together in the same place? > such as frysk-import/lib/unwind. That would be easy to organize and > maintain the code about libunwind. Code in frysk-core/frysk/rt only > need to call the methods provided by libunwind java-bindings. > > Any comments? Thanks! > Yao, I saw the exchange on IRC last evening between Wu and Andrew and it appears they have come to a resolution on these issues. For the rest of the world and myself, here is my understanding of the resolutions: files in frysk-core/frysk/rt cause the ppc/ppc64 build to fail: Resolution: IBM will write stubs for libunwind to fake ppc/ppc64 capabilities until such time as those arches are supported leaving the code where it is for right now libiberty/libbfd issue: Resolution: Red Hat will provide new "cleanroom" code for this to be incorporated into Frysk next week Please correct me if I have any of this wrong. Rick From ipantuye@redhat.com Fri Aug 4 23:49:00 2006 From: ipantuye@redhat.com (Ivan Pantuyev) Date: Fri, 04 Aug 2006 23:49:00 -0000 Subject: pty doesn't get closed when a shell is attached Message-ID: <44D3DC83.7070004@redhat.com> So I create a Pty class and make vte it's master. Everything works fine. But when I do Manager.host.requestCreateAttachedProc(ptyname, ptyname, ptyname, new String[] {"/bin/sh"}, new TaskObserver.Attached() {.... and exit frysk, the pty just hangs there (as does the shell, but that's not surprising). I don't see how something using a pty from the slave end could keep it alive... Something I'm doing wrong in that line? Ideas? thanks From qiyaoltc@cn.ibm.com Mon Aug 7 07:03:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 07 Aug 2006 07:03:00 -0000 Subject: Fix for bug#2999 Message-ID: <20060807065508.GC2347@GreenHouse.cn.ibm.com> In frysk-import/lib/dw/tests/cni/TestLib.cxx, getFuncAddr() wants to get the function address via its function name in source code, but it is not true on PPC64. According to PowerPC 64-bit ABI, function name is only a function descriptor, not entry address, and the first doubleword of function descriptor contains the address of the entry point of the function. 2006-08-07 Yao Qi * lib/dw/tests/cni/TestLib.cxx (getFuncAddr): Return function address instead of function descriptor on PPC64. * lib/dw/tests/TestDwfl.java: Take powerpc into account, and change the expected line numbers. Rebuild frysk on X86, X86_64, and PPC64, and no FAIL any more in lib.dw.tests.TestDwfl after this patch applied. OK to commit? Thanks! -- Yao Qi -------------- next part -------------- Index: frysk-imports/lib/dw/tests/TestDwfl.java =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/dw/tests/TestDwfl.java,v retrieving revision 1.10 diff -u -r1.10 TestDwfl.java --- frysk-imports/lib/dw/tests/TestDwfl.java 31 Jul 2006 19:05:13 -0000 1.10 +++ frysk-imports/lib/dw/tests/TestDwfl.java 7 Aug 2006 06:51:09 -0000 @@ -78,10 +78,14 @@ String filename = line.getSourceFile(); assertEquals("TestLib.cxx", filename.substring(filename.lastIndexOf("/") + 1)); - if(Build.BUILD_ARCH.indexOf("_64") == -1) - assertEquals(51, line.getLineNum()); + + if(Build.BUILD_ARCH.indexOf("x86_64") != -1) + assertEquals(55, line.getLineNum()); + else if (Build.BUILD_ARCH.indexOf("powerpc") != -1) + assertEquals(53, line.getLineNum()); else - assertEquals(52, line.getLineNum()); + assertEquals(51, line.getLineNum()); + assertEquals(0, line.getColumn()); } Index: frysk-imports/lib/dw/tests/cni/TestLib.cxx =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/dw/tests/cni/TestLib.cxx,v retrieving revision 1.2 diff -u -r1.2 TestLib.cxx --- frysk-imports/lib/dw/tests/cni/TestLib.cxx 6 Jun 2006 18:35:11 -0000 1.2 +++ frysk-imports/lib/dw/tests/cni/TestLib.cxx 7 Aug 2006 06:51:09 -0000 @@ -44,10 +44,14 @@ jint lib::dw::tests::TestLib::getPid(){ - return (jint) getpid(); + return (jint) getpid(); } jlong lib::dw::tests::TestLib::getFuncAddr(){ - return (jlong) &getFuncAddr; +#ifdef __powerpc64__ + return *((jlong*) &getFuncAddr); +#else + return (jlong) &getFuncAddr; +#endif } From rmoseley@redhat.com Mon Aug 7 14:14:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Mon, 07 Aug 2006 14:14:00 -0000 Subject: Fix for bug#2999 In-Reply-To: <20060807065508.GC2347@GreenHouse.cn.ibm.com> References: <20060807065508.GC2347@GreenHouse.cn.ibm.com> Message-ID: <44D74AA9.1020003@redhat.com> Checked in. Thanks for the patch!! Rick Yao Qi wrote: > In frysk-import/lib/dw/tests/cni/TestLib.cxx, getFuncAddr() wants > to get the function address via its function name in source code, > but it is not true on PPC64. According to PowerPC 64-bit ABI, > function name is only a function descriptor, not entry address, > and the first doubleword of function descriptor contains the > address of the entry point of the function. > > 2006-08-07 Yao Qi > > * lib/dw/tests/cni/TestLib.cxx (getFuncAddr): Return function > address instead of function descriptor on PPC64. > * lib/dw/tests/TestDwfl.java: Take powerpc into account, and > change the expected line numbers. > > Rebuild frysk on X86, X86_64, and PPC64, and no FAIL any more in > lib.dw.tests.TestDwfl after this patch applied. > > OK to commit? Thanks! > > ------------------------------------------------------------------------ > > Index: frysk-imports/lib/dw/tests/TestDwfl.java > =================================================================== > RCS file: /cvs/frysk/frysk-imports/lib/dw/tests/TestDwfl.java,v > retrieving revision 1.10 > diff -u -r1.10 TestDwfl.java > --- frysk-imports/lib/dw/tests/TestDwfl.java 31 Jul 2006 19:05:13 -0000 1.10 > +++ frysk-imports/lib/dw/tests/TestDwfl.java 7 Aug 2006 06:51:09 -0000 > @@ -78,10 +78,14 @@ > String filename = line.getSourceFile(); > assertEquals("TestLib.cxx", > filename.substring(filename.lastIndexOf("/") + 1)); > - if(Build.BUILD_ARCH.indexOf("_64") == -1) > - assertEquals(51, line.getLineNum()); > + > + if(Build.BUILD_ARCH.indexOf("x86_64") != -1) > + assertEquals(55, line.getLineNum()); > + else if (Build.BUILD_ARCH.indexOf("powerpc") != -1) > + assertEquals(53, line.getLineNum()); > else > - assertEquals(52, line.getLineNum()); > + assertEquals(51, line.getLineNum()); > + > assertEquals(0, line.getColumn()); > } > > Index: frysk-imports/lib/dw/tests/cni/TestLib.cxx > =================================================================== > RCS file: /cvs/frysk/frysk-imports/lib/dw/tests/cni/TestLib.cxx,v > retrieving revision 1.2 > diff -u -r1.2 TestLib.cxx > --- frysk-imports/lib/dw/tests/cni/TestLib.cxx 6 Jun 2006 18:35:11 -0000 1.2 > +++ frysk-imports/lib/dw/tests/cni/TestLib.cxx 7 Aug 2006 06:51:09 -0000 > @@ -44,10 +44,14 @@ > > jint > lib::dw::tests::TestLib::getPid(){ > - return (jint) getpid(); > + return (jint) getpid(); > } > > jlong > lib::dw::tests::TestLib::getFuncAddr(){ > - return (jlong) &getFuncAddr; > +#ifdef __powerpc64__ > + return *((jlong*) &getFuncAddr); > +#else > + return (jlong) &getFuncAddr; > +#endif > } > From rmoseley@redhat.com Mon Aug 7 14:23:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Mon, 07 Aug 2006 14:23:00 -0000 Subject: [small patch] Replace "ppc" with "powerpc" in TestOpcodes.java In-Reply-To: <20060804100447.GA2347@GreenHouse.cn.ibm.com> References: <20060804100447.GA2347@GreenHouse.cn.ibm.com> Message-ID: <44D74CC2.8010403@redhat.com> Patch applied. Thanks again for your contributions. Rick Yao Qi wrote: > When verify Bug#2712, I find TestOpcodes fail on ppc64. This small patch > replace "ppc" with "powerpc" to match Build.BUILD_ARCH, and > TestOpcodes could be skipped if this patch applied on ppc64. > > 2006-08-04 Yao Qi > > * lib/opcodes/tests/TestOpcodes.java: Replace "ppc" with > "powerpc" to match Build.BUILD_ARCH. > > OK to apply? Thanks! > > From mark@klomp.org Mon Aug 7 14:37:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 07 Aug 2006 14:37:00 -0000 Subject: Fix for bug#2999 In-Reply-To: <20060807065508.GC2347@GreenHouse.cn.ibm.com> References: <20060807065508.GC2347@GreenHouse.cn.ibm.com> Message-ID: <1154961421.3491.11.camel@dijkstra.wildebeest.org> Hi, On Mon, 2006-08-07 at 14:55 +0800, Yao Qi wrote: > In frysk-import/lib/dw/tests/cni/TestLib.cxx, getFuncAddr() wants > to get the function address via its function name in source code, > but it is not true on PPC64. According to PowerPC 64-bit ABI, > function name is only a function descriptor, not entry address, > and the first doubleword of function descriptor contains the > address of the entry point of the function. Thanks. I have used the same thing in TestPtraceByteBuffer and for my new breakpoint tests. I made a note to add a ppc check there, but if you happen to test and fix it before I do, I won't complain :) Cheers, Mark From ipantuye@redhat.com Mon Aug 7 20:17:00 2006 From: ipantuye@redhat.com (Ivan Pantuyev) Date: Mon, 07 Aug 2006 20:17:00 -0000 Subject: pty doesn't get closed when a shell is attached In-Reply-To: <44D3DC83.7070004@redhat.com> References: <44D3DC83.7070004@redhat.com> Message-ID: <44D79F48.6090305@redhat.com> And yeah, the shell also says "sh: no job control in this shell", if that is of any use (a problem on it's own though) Ivan Pantuyev wrote: > So I create a Pty class and make vte it's master. Everything works fine. > But when I do > Manager.host.requestCreateAttachedProc(ptyname, ptyname, ptyname, new > String[] {"/bin/sh"}, > new > TaskObserver.Attached() > {.... > and exit frysk, the pty just hangs there (as does the shell, but > that's not surprising). I don't see how something using a pty from the > slave end could keep it alive... Something I'm doing wrong in that > line? Ideas? > thanks From qiyaoltc@cn.ibm.com Tue Aug 8 05:07:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 08 Aug 2006 05:07:00 -0000 Subject: [patch] Do not assume little endian in setupMapsXXX Message-ID: <20060808045931.GE2347@GreenHouse.cn.ibm.com> Some test cases will fail on PPC64 if we assume byteorder to LITTLE_ENDIAN on, and here is a patch against this problem. 2006-08-08 Yao Qi * frysk/proc/LinuxTask.java: Do not assume little endian any more. Rebuild frysk on PPC64 and X86, OK to commit? Thanks! -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/proc/LinuxTask.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxTask.java,v retrieving revision 1.32 diff -u -r1.32 LinuxTask.java --- frysk-core/frysk/proc/LinuxTask.java 7 Aug 2006 20:22:15 -0000 1.32 +++ frysk-core/frysk/proc/LinuxTask.java 8 Aug 2006 04:53:40 -0000 @@ -46,7 +46,6 @@ import frysk.sys.Signal; import inua.eio.ByteBuffer; -import inua.eio.ByteOrder; import java.util.logging.Level; /** @@ -57,24 +56,24 @@ { private long ptraceOptions = 0; - // XXX: For moment wire in standard 32-bit little-endian memory - // map. This will be replaced by a memory map created using + // XXX: For moment wire in standard 32-bit memory map. + // This will be replaced by a memory map created using // information from /proc/PID/maps. private void setupMapsXXX () + throws Task.TaskException { // XXX: For writing at least, PTRACE must be used as /proc/mem // cannot be written to. memory = new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.DATA, 0xffffffffl); - memory.order (ByteOrder.LITTLE_ENDIAN); - // XXX: For moment wire in a standard 32-bit little-endian - // register set. + memory.order(getIsa().getByteOrder()); + // XXX: For moment wire in a standard 32-bit register set. registerBank = new ByteBuffer[] { new PtraceByteBuffer (id.id, PtraceByteBuffer.Area.USR) }; - registerBank[0].order (ByteOrder.LITTLE_ENDIAN); + registerBank[0].order (getIsa().getByteOrder()); } /** From woodzltc@cn.ibm.com Tue Aug 8 06:16:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 08 Aug 2006 06:16:00 -0000 Subject: [patch] fix returnCode in LinuxPPC64.java Message-ID: <20060808021628.dd3efxqww4ks4gcg@imap.linux.ibm.com> On ppc64, the gpr3 is used to store the return code of a system call. But its value is unsigned. Another register, CCR, is used to indicate the return code is negative or not. Current code of LinuxPPC64.java doesn't know that. This patch will fix that. It can also fix the failure of testSyscallOpen (http://sources.redhat.com/bugzilla/show_bug.cgi?id=3011). Tested on PPC64, OK to commit? Regards - Wu Zhou -------------- next part -------------- A non-text attachment was scrubbed... Name: returnCode.patch Type: text/x-patch Size: 726 bytes Desc: not available URL: From woodzltc@cn.ibm.com Wed Aug 9 03:07:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 09 Aug 2006 03:07:00 -0000 Subject: Fwd: [Bug general/3014] New: TestRunner hang at testTaskForkedObserver, after some ERRORs and FAILs Message-ID: <20060808230708.h14wmtu31cksw4gg@imap.linux.ibm.com> ----- Forwarded message from sourceware-bugzilla@sourceware.org ----- Date: 9 Aug 2006 03:04:51 -0000 From: woodzltc at cn dot ibm dot com Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug general/3014] New: TestRunner hang at testTaskForkedObserver, after some ERRORs and FAILs To: woodzltc@cn.ibm.com I am using a script to check out the cvs, build frysk and run the testsuite. One hour after I started the script, I see it hang at testTaskForkedObserver: Here is the output: =================== Running testTaskForkedObserver(frysk.proc.TestTaskForkedObserver) ...execvp: Too many open files Error upon logging: OPEN_FAILURE java.io.FileNotFoundException: /home/woodzltc/.frysk/logs/frysk_core_event.log.2 (Too many open files) at gnu.java.nio.channels.FileChannelImpl.open(libgcj.so.7) at gnu.java.nio.channels.FileChannelImpl.(libgcj.so.7) at java.io.FileOutputStream.(libgcj.so.7) at java.util.logging.FileHandler.createFileStream(libgcj.so.7) at java.util.logging.FileHandler.rotate(libgcj.so.7) at java.util.logging.FileHandler.publish(libgcj.so.7) at java.util.logging.Logger.log(libgcj.so.7) at java.util.logging.Logger.logImpl(libgcj.so.7) at java.util.logging.Logger.logp(libgcj.so.7) at java.util.logging.Logger.logp(libgcj.so.7) at java.util.logging.Logger.log(libgcj.so.7) at frysk.event.EventLoop.runPolling(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib$AckHandler.assertAwait(TestRunner) at frysk.proc.TestLib$AckHandler.await(TestRunner) at frysk.proc.TestLib$Child.(TestRunner) at frysk.proc.TestLib$AckProcess.(TestRunner) at frysk.proc.TestLib$AckProcess.(TestRunner) at frysk.proc.TestLib$DetachedAckProcess.(TestRunner) at frysk.proc.TestLib$AttachedDaemonProcess.(TestRunner) at frysk.proc.TestTaskForkedObserver.testTaskForkedObserver(TestRunner) at java.lang.reflect.Method.invoke(libgcj.so.7) at junit.framework.TestCase.runTest(TestRunner) at junit.framework.TestCase.runBare(TestRunner) at junit.framework.TestResult$1.protect(TestRunner) at junit.framework.TestResult.runProtected(TestRunner) at junit.framework.TestResult.run(TestRunner) at junit.framework.TestCase.run(TestRunner) at junit.framework.TestSuite.runTest(TestRunner) at junit.framework.TestSuite.run(TestRunner) at junit.framework.TestSuite.runTest(TestRunner) at junit.framework.TestSuite.run(TestRunner) at junit.textui.TestRunner.doRun(TestRunner) at junit.textui.TestRunner.doRun(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) When I look back, I found quite a lot of FAILs, with a similar message: junit.framework.AssertionFailedError: event loop run explictly stopped (startChild (Sig_USR1)) These fails start with an ERROR report at testDoCloneAttached: java.lang.RuntimeException: {frysk.proc.LinuxTask@e1f900,pid=8463,tid=8463,state=StartMainTask.wantToAttach} in state "StartMainTask.wantToAttach" did not handle handleRemoval Before testDoCloneAttached, there are 51 PASSes. Additional information: 1. I talked this with Phil on IRC, he confirm similar errors. 2. I am running on FC5. I ever run the same testsuite against the cvs code I checked out at 08-05. no errors found, 100% pass for 137 tests in frysk-core -- Summary: TestRunner hang at testTaskForkedObserver, after some ERRORs and FAILs Product: frysk Version: unspecified Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: cagney at redhat dot com ReportedBy: woodzltc at cn dot ibm dot com CC: pmuldoon at redhat dot com,qiyaoltc at cn dot ibm dot com,zhengyzy at cn dot ibm dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://sourceware.org/bugzilla/show_bug.cgi?id=3014 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. ----- End forwarded message ----- Regards - Wu Zhou From mark@klomp.org Thu Aug 10 13:02:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 10 Aug 2006 13:02:00 -0000 Subject: cvs head has lots of test failures Message-ID: <1155214946.5279.41.camel@dijkstra.wildebeest.org> Hi, We discussed this already a bit on irc, but I thought I would warn people explicitly about the latest cvs head version. Something seems to have broken lots of tests recently. This is a bit of a problem for upgrading and integrating new work. Does anybody know when and what broke things? We really need an autobuilder to catch such things early. Cheers, Mark From ezannoni@redhat.com Thu Aug 10 13:09:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Thu, 10 Aug 2006 13:09:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <1155214946.5279.41.camel@dijkstra.wildebeest.org> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> Message-ID: <17627.12098.758731.327893@localhost.redhat.com> Mark Wielaard writes: > > We really need an autobuilder to catch such things early. We really need people to run make check before checking stuff in. Please folks be considerate to your fellow coders... From mark@klomp.org Thu Aug 10 13:57:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 10 Aug 2006 13:57:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <17627.12098.758731.327893@localhost.redhat.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> Message-ID: <1155218243.5279.56.camel@dijkstra.wildebeest.org> On Thu, 2006-08-10 at 09:06 -0400, Elena Zannoni wrote: > Mark Wielaard writes: > > > > We really need an autobuilder to catch such things early. > > We really need people to run make check before checking stuff in. > Please folks be considerate to your fellow coders... Unfortunately make check is not always very reliable. We are working on some very different platforms. It can be that you are not seeing failures on your platform, but others do see them on theirs. And it seems make check is often randomly broken :{ Making it hard to see if some failure was already there or that it was introduced by your new code. I would love to have a zero make check fails checkin policy. Although the fact that some tests take more than half an hour to run make that a little hard in practise. http://sources.redhat.com/ml/frysk/2006-q3/msg00160.html Having an autobuilder on some canonical platform with public test results would make comparing results between days/checkins easier at least. Cheers, Mark From pmuldoon@redhat.com Thu Aug 10 15:49:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 10 Aug 2006 15:49:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <1155218243.5279.56.camel@dijkstra.wildebeest.org> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <1155218243.5279.56.camel@dijkstra.wildebeest.org> Message-ID: <44DB556C.3040407@redhat.com> I checked out each day from August 5th. The test-suite works on 08/05, 08/06, 08/07 with cvs co corresponding to those dates. It fails on 08/08 (ie cvs co -D "2 days ago"). So it looks like something changed on that date that caused some issues. So people who checked in on that day, should double check their patches and look for gotchas Thanks Phil Mark Wielaard wrote: > On Thu, 2006-08-10 at 09:06 -0400, Elena Zannoni wrote: > >> Mark Wielaard writes: >> > >> > We really need an autobuilder to catch such things early. >> >> We really need people to run make check before checking stuff in. >> Please folks be considerate to your fellow coders... >> > > Unfortunately make check is not always very reliable. We are working on > some very different platforms. It can be that you are not seeing > failures on your platform, but others do see them on theirs. And it > seems make check is often randomly broken :{ Making it hard to see if > some failure was already there or that it was introduced by your new > code. I would love to have a zero make check fails checkin policy. > > Although the fact that some tests take more than half an hour to run > make that a little hard in practise. > http://sources.redhat.com/ml/frysk/2006-q3/msg00160.html > > Having an autobuilder on some canonical platform with public test > results would make comparing results between days/checkins easier at > least. > > Cheers, > > Mark > > From pmuldoon@redhat.com Thu Aug 10 17:49:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 10 Aug 2006 17:49:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <44DB556C.3040407@redhat.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <1155218243.5279.56.camel@dijkstra.wildebeest.org> <44DB556C.3040407@redhat.com> Message-ID: <44DB718B.609@redhat.com> I looked at this a little further, and I don't feel comfortable yanking patches as my knowledge in this area is slight, and does vary wildly. So you don't have to, I trawled the frysk-cvs mailing list to get a list of patches on the 8th, with their owner. ;) Please take a look, as it is right now head is busted. The list of patches I could find on the 8th belong to Tim, Mike, Sami, Stepan and Len/ Tim's patches: 2006-08-08 Tim Moore * TestI386Modify.java: (TestI386ModifyInternals.update): Change Task.TaskException to TaskException. Patches from IBM. 2006-08-08 Wu Zhou * LinuxPPC64.java (returnCode): When the 29th bit of register CCR is set, return the negation of register GPR3. 2006-08-08 Yao Qi * frysk/proc/LinuxTask.java: Do not assume little endian any more. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ChangeLog.diff?cvsroot=frysk&r1=1.384&r2=1.385 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/LinuxPPC64.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/LinuxTask.java.diff?cvsroot=frysk&r1=1.32&r2=1.33 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/TestI386Modify.java.diff?cvsroot=frysk&r1=1.39&r2=1.40 Modified files: frysk/proc : ChangeLog Isa.java IsaEMT64.java IsaIA32.java Log message: * Isa.java: GNU indentation. * IsaIA32.java: ditto. * IsaEMT64.java: ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ChangeLog.diff?cvsroot=frysk&r1=1.385&r2=1.386 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/Isa.java.diff?cvsroot=frysk&r1=1.9&r2=1.10 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/IsaEMT64.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/IsaIA32.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 ********************************************************************************************************************* Mike's patches: Modified files: frysk/gui : ChangeLog Gui.java Log message: 2006-08-08 Mike Cvet * Gui.java (createDummyTagsets): Commented out for now, not being used but still being initialized. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.336&r2=1.337 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/Gui.java.diff?cvsroot=frysk&r1=1.53&r2=1.54 Modified files: frysk/gui/monitor: ChangeLog frysk/gui/monitor/actions: RunExternal.java Log message: 2006-08-08 Mike Cvet * actions/RunExternal.java (RunExBlocker): Added. (TaskTerminatedObserver.updateTerminated): Updated to unblock the examined task when finished. (AttachedObserver.updateAttached): Requests a Terminating Observer on the external process. (execute): Creates a new RunExBlocker and requests it to attach to the incoming Task. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ChangeLog.diff?cvsroot=frysk&r1=1.326&r2=1.327 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/actions/RunExternal.java.diff?cvsroot=frysk&r1=1.4&r2=1.5 Modified files: frysk/gui : ChangeLog frysk/gui/glade: procpop.glade Log message: 2006-08-08 Mike Cvet * glade/procpop.glade: Added pidColumnDialog. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.340&r2=1.341 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/glade/procpop.glade.diff?cvsroot=frysk&r1=1.87&r2=1.88 Modified files: frysk/gui/glade: procpop.glade Log message: Fixed an empty dialog oops Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/glade/procpop.glade.diff?cvsroot=frysk&r1=1.88&r2=1.89 ********************************************************************************************************************* Sami's patches: Modified files: frysk/proc : ChangeLog ProcState.java TestTaskObserverBlocked.java frysk/gui : ChangeLog Gui.java SessionManagerGui.java frysk/gui/druid: CreateFryskSessionDruid.java frysk/gui/glade: procpop.glade frysk/gui/monitor: ChangeLog CheckedListView.java GuiProc.java ListView.java MenuBar.java SessionProcDataModel.java WindowManager.java frysk/gui/monitor/observers: ObserverManager.java TaskCloneObserver.java TaskExecObserver.java TaskForkedObserver.java TaskObserverRoot.java TaskSyscallObserver.java TaskTerminatingObserver.java frysk/gui/sessions: DebugProcess.java Added files: frysk/gui/monitor: ProgramObserverDialog.java frysk/gui/monitor/observers: ProgramObserver.java Removed files: frysk/gui/monitor: PickProcsDialog.java Log message: 2006-08-08 Sami Wagiaalla * ProcState.java: Added handling of DetachComplete to Attaching.toMainTask. * TestTaskObserverBlocked.java (testAddObserverAfterUnblock): Enabled test. 2006-08-08 Sami Wagiaalla * sessions/DebugProcess.java: Added listining to programObserver. * glade/procpop.glade: Added program observer menu item. Added quit menu item. * druid/CreateFryskSessionDruid.java (filterDatainSession): changed getProcessies() to getProcessies().iterator. * SessionManagerGui.java: used Gui.quitFrysk insteaf of Gtk.mainQuit(). 2006-08-08 Sami Wagiaalla * observers/TaskObserverRoot.java: Added unapply(Proc). added abstrace unapply(Task). * observers/TaskCloneObserver.java: Implemented unapply(Task). * observers/TaskTerminatingObserver.java: Ditto. * observers/TaskSyscallObserver.java: Ditto. * observers/TaskForkedObserver.java: Ditto. * observers/TaskExecObserver.java: Ditto. * WindowManager.java: Added programObserver dialog to the list of windows and to save/load. * SessionProcDataModel.java: Added handling for updating the list when new procs are added to the underlying DebugProcess. * MenuBar.java: Added quitFryk menu item. Removed editCustomObservers menu item. * GuiProc.java (isOwned): Added explicit check for getExec. * CheckedListView.java: Added getCheckedByName. Added getCheckObjects. * ListView (getSelectedObjects): Changed it to return a list instead of iterator. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ChangeLog.diff?cvsroot=frysk&r1=1.386&r2=1.387 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ProcState.java.diff?cvsroot=frysk&r1=1.57&r2=1.58 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/TestTaskObserverBlocked.java.diff?cvsroot=frysk&r1=1.18&r2=1.19 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.337&r2=1.338 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/Gui.java.diff?cvsroot=frysk&r1=1.54&r2=1.55 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/SessionManagerGui.java.diff?cvsroot=frysk&r1=1.24&r2=1.25 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/druid/CreateFryskSessionDruid.java.diff?cvsroot=frysk&r1=1.46&r2=1.47 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/glade/procpop.glade.diff?cvsroot=frysk&r1=1.86&r2=1.87 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ProgramObserverDialog.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ChangeLog.diff?cvsroot=frysk&r1=1.325&r2=1.326 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/CheckedListView.java.diff?cvsroot=frysk&r1=1.11&r2=1.12 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/GuiProc.java.diff?cvsroot=frysk&r1=1.8&r2=1.9 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ListView.java.diff?cvsroot=frysk&r1=1.25&r2=1.26 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/MenuBar.java.diff?cvsroot=frysk&r1=1.14&r2=1.15 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/SessionProcDataModel.java.diff?cvsroot=frysk&r1=1.19&r2=1.20 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/WindowManager.java.diff?cvsroot=frysk&r1=1.29&r2=1.30 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/PickProcsDialog.java.diff?cvsroot=frysk&r1=1.1&r2=NONE http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/ProgramObserver.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/ObserverManager.java.diff?cvsroot=frysk&r1=1.39&r2=1.40 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskCloneObserver.java.diff?cvsroot=frysk&r1=1.15&r2=1.16 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskExecObserver.java.diff?cvsroot=frysk&r1=1.22&r2=1.23 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskForkedObserver.java.diff?cvsroot=frysk&r1=1.38&r2=1.39 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskObserverRoot.java.diff?cvsroot=frysk&r1=1.13&r2=1.14 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskSyscallObserver.java.diff?cvsroot=frysk&r1=1.10&r2=1.11 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskTerminatingObserver.java.diff?cvsroot=frysk&r1=1.14&r2=1.15 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/sessions/DebugProcess.java.diff?cvsroot=frysk&r1=1.17&r2=1.18 ********************************************************************************************************************* Stepan's patches: Modified files: elfutils/backends: ChangeLog Makefile.am elfutils/tests : ChangeLog line2addr.c Log message: Restore our local changes to elfutils. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/backends/ChangeLog.diff?cvsroot=frysk&r1=1.4&r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/backends/Makefile.am.diff?cvsroot=frysk&r1=1.4&r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/ChangeLog.diff?cvsroot=frysk&r1=1.3&r2=1.4 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/line2addr.c.diff?cvsroot=frysk&r1=1.3&r2=1.4 Modified files: tests : ChangeLog Makefile.am Log message: * Makefile.am: Move frysk2130/strace-clone-exec.sh to XFAIL_TESTS. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/tests/ChangeLog.diff?cvsroot=frysk&r1=1.76&r2=1.77 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/tests/Makefile.am.diff?cvsroot=frysk&r1=1.71&r2=1.72 Modified files: elfutils/tests : ChangeLog Makefile.am Log message: * Makefile.am: Add XFAIL_TEST = run-elflint-self.sh Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/ChangeLog.diff?cvsroot=frysk&r1=1.4&r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/Makefile.am.diff?cvsroot=frysk&r1=1.1.1.1&r2=1.2 Modified files: elfutils/tests : ChangeLog Makefile.am Log message: * Makefile.am: Add XFAIL_TEST = run-elflint-self.sh (frysk #2947) Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/ChangeLog.diff?cvsroot=frysk&r1=1.5&r2=1.6 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/Makefile.am.diff?cvsroot=frysk&r1=1.2&r2=1.3 Modified files: frysk/gui : ChangeLog frysk/gui/test/dogtail_scripts: frysk_suite.in Log message: * test/dogtail_scripts/frysk_suite.in: Use "dogtail-run-headless -n". Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.338&r2=1.339 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/frysk_suite.in.diff?cvsroot=frysk&r1=1.11&r2=1.12 Modified files: frysk/gui : ChangeLog frysk/gui/test/dogtail_scripts: frysk_suite.in Log message: * test/dogtail_scripts/frysk_suite.in: Use "dogtail-run-headless -n". And do not check whether the accessibility is on; dogtail-run-headless should temporarily switch it on, if necessary. Modified files: . : ChangeLog Makefile.am Log message: * Makefile.am (TESTS_ENVIRONMENT): Add a comment. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/ChangeLog.diff?cvsroot=frysk&r1=1.78&r2=1.79 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/Makefile.am.diff?cvsroot=frysk&r1=1.62&r2=1.63 ********************************************************************************************************************* Len's Patches: Modified files: frysk/gui/test/dogtail_scripts: FryskHelpers.py ObserverHandler.py TestCreateObserversfromDataModel.py new_exec_custom_observer.xml Log message: Corrected logic errors - kept code in synch with GUIs. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/FryskHelpers.py.diff?cvsroot=frysk&r1=1.41&r2=1.42 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/ObserverHandler.py.diff?cvsroot=frysk&r1=1.13&r2=1.14 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/TestCreateObserversfromDataModel.py.diff?cvsroot=frysk&r1=1.27&r2=1.28 http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/new_exec_custom_observer.xml.diff?cvsroot=frysk&r1=1.3&r2=1.4 Phil Muldoon wrote: > I checked out each day from August 5th. > > The test-suite works on 08/05, 08/06, 08/07 with cvs co corresponding > to those dates. > > It fails on 08/08 (ie cvs co -D "2 days ago"). So it looks like > something changed on that date that caused some issues. So people who > checked in on that day, should double check their patches and look for > gotchas > > Thanks > > Phil > > Mark Wielaard wrote: >> On Thu, 2006-08-10 at 09:06 -0400, Elena Zannoni wrote: >> >>> Mark Wielaard writes: >>> > > We really need an autobuilder to catch such things early. >>> >>> We really need people to run make check before checking stuff in. >>> Please folks be considerate to your fellow coders... >>> >> >> Unfortunately make check is not always very reliable. We are working on >> some very different platforms. It can be that you are not seeing >> failures on your platform, but others do see them on theirs. And it >> seems make check is often randomly broken :{ Making it hard to see if >> some failure was already there or that it was introduced by your new >> code. I would love to have a zero make check fails checkin policy. >> >> Although the fact that some tests take more than half an hour to run >> make that a little hard in practise. >> http://sources.redhat.com/ml/frysk/2006-q3/msg00160.html >> >> Having an autobuilder on some canonical platform with public test >> results would make comparing results between days/checkins easier at >> least. >> >> Cheers, >> >> Mark >> >> > From cagney@redhat.com Thu Aug 10 18:20:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 10 Aug 2006 18:20:00 -0000 Subject: frysk-imports/elfutils/tests ChangeLog In-Reply-To: <20060809192538.31913.qmail@sourceware.org> References: <20060809192538.31913.qmail@sourceware.org> Message-ID: <44DB7902.3040406@redhat.com> Stephan, please remember to include the ChangeLog entry in the CVS commit log. The below is blank. kasal@sourceware.org wrote: > CVSROOT: /cvs/frysk > Module name: frysk-imports > Changes by: kasal@sourceware.org 2006-08-09 19:25:38 > > Modified files: > elfutils/tests : ChangeLog > > Log message: > . > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/ChangeLog.diff?cvsroot=frysk&r1=1.7&r2=1.8 > > From cagney@redhat.com Thu Aug 10 18:22:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 10 Aug 2006 18:22:00 -0000 Subject: frysk-imports/tests ChangeLog Makefile.am In-Reply-To: <20060808171842.6879.qmail@sourceware.org> References: <20060808171842.6879.qmail@sourceware.org> Message-ID: <44DB794B.7090100@redhat.com> Stepan, just fyi, I reverted this; should the test fail then there's a problem with the systems kernel that needs to be fixed. Andrew kasal@sourceware.org wrote: > CVSROOT: /cvs/frysk > Module name: frysk-imports > Changes by: kasal@sourceware.org 2006-08-08 17:18:42 > > Modified files: > tests : ChangeLog Makefile.am > > Log message: > * Makefile.am: Move frysk2130/strace-clone-exec.sh to XFAIL_TESTS. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/tests/ChangeLog.diff?cvsroot=frysk&r1=1.76&r2=1.77 > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/tests/Makefile.am.diff?cvsroot=frysk&r1=1.71&r2=1.72 > > From pmuldoon@redhat.com Thu Aug 10 19:48:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 10 Aug 2006 19:48:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <44DB718B.609@redhat.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <1155218243.5279.56.camel@dijkstra.wildebeest.org> <44DB556C.3040407@redhat.com> <44DB718B.609@redhat.com> Message-ID: <44DB8D63.7030204@redhat.com> I reverted LinuxTask.hava from 1.32. The endian patch was causing a few issues. Perhaps the ultimate issue is in getIsa() using an elfFile which uses a file handle. The theory is these handles are being queued for Garbage Collection along with the object when the object is destroyed, but the system is running out of handles before the Garbage Collection is happening. Hopefully I have not totally mangled that explanation though that people worked through on irc today. ;) Regards Phil [2006-08-10 10:45] pmuldoon, one question about Java's syntax: elfFile is a local variable in getIsa, when getIsa() exits, will Elf's destructor be called? Phil Muldoon wrote: > I looked at this a little further, and I don't feel comfortable > yanking patches as my knowledge in this area is slight, and does vary > wildly. So you don't have to, I trawled the frysk-cvs mailing list to > get a list of patches on the 8th, with their owner. ;) Please take a > look, as it is right now head is busted. The list of patches I could > find on the 8th belong to Tim, Mike, Sami, Stepan and Len/ > > Tim's patches: > > 2006-08-08 Tim Moore > > * TestI386Modify.java: (TestI386ModifyInternals.update): Change > Task.TaskException to TaskException. > > Patches from IBM. > 2006-08-08 Wu Zhou > > * LinuxPPC64.java (returnCode): When the 29th bit of > register CCR is set, return the negation of register GPR3. > > 2006-08-08 Yao Qi > > * frysk/proc/LinuxTask.java: Do not assume little endian any > more. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ChangeLog.diff?cvsroot=frysk&r1=1.384&r2=1.385 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/LinuxPPC64.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/LinuxTask.java.diff?cvsroot=frysk&r1=1.32&r2=1.33 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/TestI386Modify.java.diff?cvsroot=frysk&r1=1.39&r2=1.40 > > > > Modified files: > frysk/proc : ChangeLog Isa.java IsaEMT64.java IsaIA32.java > Log message: > * Isa.java: GNU indentation. > * IsaIA32.java: ditto. > * IsaEMT64.java: ditto. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ChangeLog.diff?cvsroot=frysk&r1=1.385&r2=1.386 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/Isa.java.diff?cvsroot=frysk&r1=1.9&r2=1.10 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/IsaEMT64.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/IsaIA32.java.diff?cvsroot=frysk&r1=1.1&r2=1.2 > > > > ********************************************************************************************************************* > > > Mike's patches: > > Modified files: > frysk/gui : ChangeLog Gui.java > Log message: > 2006-08-08 Mike Cvet > > * Gui.java (createDummyTagsets): Commented out for now, not > being used but still being initialized. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.336&r2=1.337 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/Gui.java.diff?cvsroot=frysk&r1=1.53&r2=1.54 > > > Modified files: > frysk/gui/monitor: ChangeLog frysk/gui/monitor/actions: > RunExternal.java > Log message: > 2006-08-08 Mike Cvet > > * actions/RunExternal.java (RunExBlocker): Added. > (TaskTerminatedObserver.updateTerminated): Updated to unblock the > examined task when finished. > (AttachedObserver.updateAttached): Requests a Terminating Observer > on the external process. > (execute): Creates a new RunExBlocker and requests it to attach to > the incoming Task. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ChangeLog.diff?cvsroot=frysk&r1=1.326&r2=1.327 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/actions/RunExternal.java.diff?cvsroot=frysk&r1=1.4&r2=1.5 > > > Modified files: > frysk/gui : ChangeLog frysk/gui/glade: procpop.glade > Log message: > 2006-08-08 Mike Cvet > > * glade/procpop.glade: Added pidColumnDialog. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.340&r2=1.341 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/glade/procpop.glade.diff?cvsroot=frysk&r1=1.87&r2=1.88 > > > Modified files: > frysk/gui/glade: procpop.glade > Log message: > Fixed an empty dialog oops > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/glade/procpop.glade.diff?cvsroot=frysk&r1=1.88&r2=1.89 > > > ********************************************************************************************************************* > > > > Sami's patches: > > Modified files: > frysk/proc : ChangeLog ProcState.java > TestTaskObserverBlocked.java frysk/gui : ChangeLog Gui.java > SessionManagerGui.java frysk/gui/druid: > CreateFryskSessionDruid.java frysk/gui/glade: procpop.glade > frysk/gui/monitor: ChangeLog CheckedListView.java GuiProc.java > ListView.java MenuBar.java > SessionProcDataModel.java WindowManager.java > frysk/gui/monitor/observers: ObserverManager.java > TaskCloneObserver.java > TaskExecObserver.java > TaskForkedObserver.java > TaskObserverRoot.java > TaskSyscallObserver.java > TaskTerminatingObserver.java > frysk/gui/sessions: DebugProcess.java Added files: > frysk/gui/monitor: ProgramObserverDialog.java > frysk/gui/monitor/observers: ProgramObserver.java Removed files: > frysk/gui/monitor: PickProcsDialog.java > Log message: > 2006-08-08 Sami Wagiaalla > > * ProcState.java: Added handling of DetachComplete to > Attaching.toMainTask. > * TestTaskObserverBlocked.java (testAddObserverAfterUnblock): > Enabled test. > > 2006-08-08 Sami Wagiaalla > > * sessions/DebugProcess.java: Added listining to programObserver. > * glade/procpop.glade: Added program observer menu item. > Added quit menu item. > * druid/CreateFryskSessionDruid.java (filterDatainSession): changed > getProcessies() to getProcessies().iterator. > * SessionManagerGui.java: used Gui.quitFrysk insteaf > of Gtk.mainQuit(). > > 2006-08-08 Sami Wagiaalla > > * observers/TaskObserverRoot.java: Added unapply(Proc). > added abstrace unapply(Task). > * observers/TaskCloneObserver.java: Implemented unapply(Task). > * observers/TaskTerminatingObserver.java: Ditto. > * observers/TaskSyscallObserver.java: Ditto. > * observers/TaskForkedObserver.java: Ditto. > * observers/TaskExecObserver.java: Ditto. > * WindowManager.java: Added programObserver dialog to the list > of windows and to save/load. > * SessionProcDataModel.java: Added handling for updating > the list when new procs are added to the underlying DebugProcess. > * MenuBar.java: Added quitFryk menu item. > Removed editCustomObservers menu item. > * GuiProc.java (isOwned): Added explicit check for getExec. > * CheckedListView.java: Added getCheckedByName. > Added getCheckObjects. > * ListView (getSelectedObjects): Changed it to return a list > instead of iterator. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ChangeLog.diff?cvsroot=frysk&r1=1.386&r2=1.387 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/ProcState.java.diff?cvsroot=frysk&r1=1.57&r2=1.58 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/proc/TestTaskObserverBlocked.java.diff?cvsroot=frysk&r1=1.18&r2=1.19 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.337&r2=1.338 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/Gui.java.diff?cvsroot=frysk&r1=1.54&r2=1.55 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/SessionManagerGui.java.diff?cvsroot=frysk&r1=1.24&r2=1.25 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/druid/CreateFryskSessionDruid.java.diff?cvsroot=frysk&r1=1.46&r2=1.47 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/glade/procpop.glade.diff?cvsroot=frysk&r1=1.86&r2=1.87 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ProgramObserverDialog.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ChangeLog.diff?cvsroot=frysk&r1=1.325&r2=1.326 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/CheckedListView.java.diff?cvsroot=frysk&r1=1.11&r2=1.12 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/GuiProc.java.diff?cvsroot=frysk&r1=1.8&r2=1.9 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/ListView.java.diff?cvsroot=frysk&r1=1.25&r2=1.26 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/MenuBar.java.diff?cvsroot=frysk&r1=1.14&r2=1.15 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/SessionProcDataModel.java.diff?cvsroot=frysk&r1=1.19&r2=1.20 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/WindowManager.java.diff?cvsroot=frysk&r1=1.29&r2=1.30 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/PickProcsDialog.java.diff?cvsroot=frysk&r1=1.1&r2=NONE > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/ProgramObserver.java.diff?cvsroot=frysk&r1=NONE&r2=1.1 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/ObserverManager.java.diff?cvsroot=frysk&r1=1.39&r2=1.40 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskCloneObserver.java.diff?cvsroot=frysk&r1=1.15&r2=1.16 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskExecObserver.java.diff?cvsroot=frysk&r1=1.22&r2=1.23 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskForkedObserver.java.diff?cvsroot=frysk&r1=1.38&r2=1.39 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskObserverRoot.java.diff?cvsroot=frysk&r1=1.13&r2=1.14 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskSyscallObserver.java.diff?cvsroot=frysk&r1=1.10&r2=1.11 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/monitor/observers/TaskTerminatingObserver.java.diff?cvsroot=frysk&r1=1.14&r2=1.15 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/sessions/DebugProcess.java.diff?cvsroot=frysk&r1=1.17&r2=1.18 > > > ********************************************************************************************************************* > > > Stepan's patches: > > Modified files: > elfutils/backends: ChangeLog Makefile.am elfutils/tests : > ChangeLog line2addr.c > Log message: > Restore our local changes to elfutils. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/backends/ChangeLog.diff?cvsroot=frysk&r1=1.4&r2=1.5 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/backends/Makefile.am.diff?cvsroot=frysk&r1=1.4&r2=1.5 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/ChangeLog.diff?cvsroot=frysk&r1=1.3&r2=1.4 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/line2addr.c.diff?cvsroot=frysk&r1=1.3&r2=1.4 > > > Modified files: > tests : ChangeLog Makefile.am > Log message: > * Makefile.am: Move frysk2130/strace-clone-exec.sh to XFAIL_TESTS. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/tests/ChangeLog.diff?cvsroot=frysk&r1=1.76&r2=1.77 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/tests/Makefile.am.diff?cvsroot=frysk&r1=1.71&r2=1.72 > > > Modified files: > elfutils/tests : ChangeLog Makefile.am > Log message: > * Makefile.am: Add XFAIL_TEST = run-elflint-self.sh > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/ChangeLog.diff?cvsroot=frysk&r1=1.4&r2=1.5 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/Makefile.am.diff?cvsroot=frysk&r1=1.1.1.1&r2=1.2 > > > > Modified files: > elfutils/tests : ChangeLog Makefile.am > Log message: > * Makefile.am: Add XFAIL_TEST = run-elflint-self.sh (frysk #2947) > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/ChangeLog.diff?cvsroot=frysk&r1=1.5&r2=1.6 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-imports/elfutils/tests/Makefile.am.diff?cvsroot=frysk&r1=1.2&r2=1.3 > > > Modified files: > frysk/gui : ChangeLog frysk/gui/test/dogtail_scripts: > frysk_suite.in > Log message: > * test/dogtail_scripts/frysk_suite.in: Use "dogtail-run-headless -n". > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/ChangeLog.diff?cvsroot=frysk&r1=1.338&r2=1.339 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/frysk_suite.in.diff?cvsroot=frysk&r1=1.11&r2=1.12 > > > Modified files: > frysk/gui : ChangeLog frysk/gui/test/dogtail_scripts: > frysk_suite.in > Log message: > * test/dogtail_scripts/frysk_suite.in: Use "dogtail-run-headless -n". > And do not check whether the accessibility is on; > dogtail-run-headless should temporarily switch it on, if necessary. > > Modified files: > . : ChangeLog Makefile.am > Log message: > * Makefile.am (TESTS_ENVIRONMENT): Add a comment. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/ChangeLog.diff?cvsroot=frysk&r1=1.78&r2=1.79 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/Makefile.am.diff?cvsroot=frysk&r1=1.62&r2=1.63 > > > ********************************************************************************************************************* > > > Len's Patches: > > Modified files: > frysk/gui/test/dogtail_scripts: FryskHelpers.py > ObserverHandler.py > > TestCreateObserversfromDataModel.py > new_exec_custom_observer.xml > Log message: > Corrected logic errors - kept code in synch with GUIs. > > Patches: > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/FryskHelpers.py.diff?cvsroot=frysk&r1=1.41&r2=1.42 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/ObserverHandler.py.diff?cvsroot=frysk&r1=1.13&r2=1.14 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/TestCreateObserversfromDataModel.py.diff?cvsroot=frysk&r1=1.27&r2=1.28 > > http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-gui/frysk/gui/test/dogtail_scripts/new_exec_custom_observer.xml.diff?cvsroot=frysk&r1=1.3&r2=1.4 > > > > > Phil Muldoon wrote: >> I checked out each day from August 5th. >> >> The test-suite works on 08/05, 08/06, 08/07 with cvs co corresponding >> to those dates. >> >> It fails on 08/08 (ie cvs co -D "2 days ago"). So it looks like >> something changed on that date that caused some issues. So people who >> checked in on that day, should double check their patches and look >> for gotchas >> >> Thanks >> >> Phil >> >> Mark Wielaard wrote: >>> On Thu, 2006-08-10 at 09:06 -0400, Elena Zannoni wrote: >>> >>>> Mark Wielaard writes: >>>> > > We really need an autobuilder to catch such things early. >>>> >>>> We really need people to run make check before checking stuff in. >>>> Please folks be considerate to your fellow coders... >>>> >>> >>> Unfortunately make check is not always very reliable. We are working on >>> some very different platforms. It can be that you are not seeing >>> failures on your platform, but others do see them on theirs. And it >>> seems make check is often randomly broken :{ Making it hard to see if >>> some failure was already there or that it was introduced by your new >>> code. I would love to have a zero make check fails checkin policy. >>> >>> Although the fact that some tests take more than half an hour to run >>> make that a little hard in practise. >>> http://sources.redhat.com/ml/frysk/2006-q3/msg00160.html >>> >>> Having an autobuilder on some canonical platform with public test >>> results would make comparing results between days/checkins easier at >>> least. >>> >>> Cheers, >>> >>> Mark >>> >>> >> > From timoore@redhat.com Thu Aug 10 22:34:00 2006 From: timoore@redhat.com (Tim Moore) Date: Thu, 10 Aug 2006 22:34:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <44DB8D63.7030204@redhat.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <1155218243.5279.56.camel@dijkstra.wildebeest.org> <44DB556C.3040407@redhat.com> <44DB718B.609@redhat.com> <44DB8D63.7030204@redhat.com> Message-ID: <44DBB4A5.2060304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phil Muldoon wrote: > I reverted LinuxTask.hava from 1.32. The endian patch was causing a few > issues. Perhaps the ultimate issue is in getIsa() using an elfFile which > uses a file handle. The theory is these handles are being queued for > Garbage Collection along with the object when the object is destroyed, > but the system is running out of handles before the Garbage Collection > is happening. Hopefully I have not totally mangled that explanation > though that people worked through on irc today. ;) > The problem is that the file descriptor passed to libelf is *never* closed, whether or not the Elf Java object is garbage collected. I've added an explicit close() method for the Elf object so that getIsa() can release the file descriptor right away, and of course added the code to close the file descriptor. frysk-core TestRunner tests run now, but I'm going to sleep in it before checking in my code. > >>>> On Thu, 2006-08-10 at 09:06 -0400, Elena Zannoni wrote: >>>> >>>>> Mark Wielaard writes: >>>>> > > We really need an autobuilder to catch such things early. >>>>> >>>>> We really need people to run make check before checking stuff in. >>>>> Please folks be considerate to your fellow coders... Mea culpa for not running the tests more carefully, though in my defense the tests were broken at the time on x8664 :) Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE27P5eDhWHdXrDRURAmdVAJ9FhkhB9S2wd3dOacNIKAOX6g7AXgCffu6R zt98Ri3j0ZKjWKeIU9r5tJA= =KKdO -----END PGP SIGNATURE----- From woodzltc@cn.ibm.com Fri Aug 11 01:58:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 11 Aug 2006 01:58:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <17627.12098.758731.327893@localhost.redhat.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> Message-ID: <20060810215840.f6g2f8hf8c8so0c8@imap.linux.ibm.com> Quoting Elena Zannoni : > Mark Wielaard writes: > > > > We really need an autobuilder to catch such things early. > > We really need people to run make check before checking stuff in. > Please folks be considerate to your fellow coders... > That might not be enough. People might be working on a older source tree. My idea is to do a cvs merge before attempting to check in codes. And run "make check" on that tree instead. The idea of autobuilder are also helpful. I ever put some commands together into a so-called script, which can do this in some aspect. But I don't do any effort to make it robust. I put it here if anyone is interested. #!/bin/bash -x rm -rf ./older-cvs mv ./latest-cvs/ ./older-cvs mkdir ./latest-cvs cd ./latest-cvs/ export CVSROOT=:pserver:anoncvs:anoncvs@sources.redhat.com:/cvs/frysk cvs login cvs co frysk #export 'JAVAC=/opt/gccfr/bin/gcj -C' #export 'GCJ=/opt/gccfr/bin/gcj' #export 'GIJ=/opt/gccfr/bin/gij' #export 'JAR=/opt/gccfr/bin/fastjar' #export 'GCJH=/opt/gccfr/bin/gcjh' #export 'GCJ_DBTOOL=/opt/gccfr/bin/gcj-dbtool' #export 'GCC=/opt/gccfr/bin/gcc' #export 'CC=/opt/gccfr/bin/gcc' #export 'CXX=/opt/gccfr/bin/g++' #export 'JAVA=/opt/gccfr/bin/gij' #export 'JV_SCAN=/opt/gccfr/bin/jv-scan' export CCASFLAGS="-g3" export CFLAGS="-g3" export CXXFLAGS="-g3" export GCJFLAGS="-g3" ( mkdir build && cd build && ../frysk/autogen.sh ) 1>autogen.log 2>>autogen.log ( cd build/frysk-imports/tests && make check ) 1>imports-check.log 2>>imports-check.log ( cd build/frysk-gtk/tests && make check ) 1>gtk-check.log 2>>gtk-check.log ( cd build && make -j2 ) 1>make-j2.log 2>>make-j2.log ( cd build && make check ) 1>make-check.log 2>>make-check.log (cd build/frysk-core && ./TestRunner -l FINE) 1>core-tr.log 2>>core-tr.log (cd build/frysk-sys && ./TestRunner -l FINE) 1>sys-tr.log 2>>sys-tr.log (cd build/frysk-imports && ./TestRunner -l FINE) 1>imports-tr.log 2>>imports-tr.log sudo mkdir -p /var/www/html/frysk/i686/`date '+%Y%m%d'` sudo cp -f *.log /var/www/html/frysk/ /var/www/html/frysk/i686/`date '+%Y%m%d'` Regards - Wu Zhou P.S: I am thinking of revisiting the idea of running the build and test automatically in a regular time base. I am planning to cover x86, x86_64 and ppc64. (We have x86_64 available now). On x86, x86_64, we don't need any extra effort to auto build. But on ppc64, extra effort is still needed. From woodzltc@cn.ibm.com Fri Aug 11 02:21:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 11 Aug 2006 02:21:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <44DBB4A5.2060304@redhat.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <1155218243.5279.56.camel@dijkstra.wildebeest.org> <44DB556C.3040407@redhat.com> <44DB718B.609@redhat.com> <44DB8D63.7030204@redhat.com> <44DBB4A5.2060304@redhat.com> Message-ID: <20060810222045.dcqqdmvl0k0cgco8@imap.linux.ibm.com> Quoting Tim Moore : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Phil Muldoon wrote: >> I reverted LinuxTask.hava from 1.32. The endian patch was causing a few >> issues. Perhaps the ultimate issue is in getIsa() using an elfFile which >> uses a file handle. The theory is these handles are being queued for >> Garbage Collection along with the object when the object is destroyed, >> but the system is running out of handles before the Garbage Collection >> is happening. Hopefully I have not totally mangled that explanation >> though that people worked through on irc today. ;) >> > The problem is that the file descriptor passed to libelf is *never* > closed, whether or not the Elf Java object is garbage collected. I've > added an explicit close() method for the Elf object so that getIsa() can > release the file descriptor right away, and of course added the code to > close the file descriptor. frysk-core TestRunner tests run now, but I'm > going to sleep in it before checking in my code. > That is just what I thought of. Can you post your code here? BTW. This make me think of another checkin policy: before checking in code, we can post the diff on the mail-list, if nobody reject in a specified time (one day, two days, or longer), it can get in. Another option is for some people to review the code, but that will take some more time. If the first option is enabled, we are willing to test the new code in a as-short-as-possible time. Although we are mainly focused on ppc64, we also care about all aspect of Frysk anyway. :-) >>>>> On Thu, 2006-08-10 at 09:06 -0400, Elena Zannoni wrote: >>>>> >>>>>> Mark Wielaard writes: >>>>>> > > We really need an autobuilder to catch such things early. >>>>>> >>>>>> We really need people to run make check before checking stuff in. >>>>>> Please folks be considerate to your fellow coders... > > Mea culpa for not running the tests more carefully, though in my defense > the tests were broken at the time on x8664 :) I guess Mea culpa is French's saying for saying sorry. If it is, we need say sorry here too. :-) These getIsa() code is from us anyway. I am now requesting my side's people to carefully test all the code they write. If they need to check in, they need at least try TestRunner and make check under relevant directory to make sure there is no regression. Regards - Wu Zhou From qiyaoltc@cn.ibm.com Fri Aug 11 02:38:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 11 Aug 2006 02:38:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <20060810222045.dcqqdmvl0k0cgco8@imap.linux.ibm.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <1155218243.5279.56.camel@dijkstra.wildebeest.org> <44DB556C.3040407@redhat.com> <44DB718B.609@redhat.com> <44DB8D63.7030204@redhat.com> <44DBB4A5.2060304@redhat.com> <20060810222045.dcqqdmvl0k0cgco8@imap.linux.ibm.com> Message-ID: <20060811023014.GA7238@GreenHouse.cn.ibm.com> On Thu, Aug 10, 2006 at 10:20:45PM -0400, Wu Zhou wrote: > Quoting Tim Moore : > > I guess Mea culpa is French's saying for saying sorry. If it is, we > need say sorry here too. :-) These getIsa() code is from us anyway. Hi, Tim, and Wu, Sorry for the trouble this patch brought. We will double check patches later, and run TestRunner after any modifications. -- Yao Qi From woodzltc@cn.ibm.com Fri Aug 11 05:21:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 11 Aug 2006 05:21:00 -0000 Subject: Fwd: [libunwind] moving libunwind to Savannah/kernel.org Message-ID: <20060811012103.g9g0uz0fksowk0wg@imap.linux.ibm.com> libunwind is moving home. A new mail-list is opened, which is more convenient I believe. ----- ?David.Mosberger@acm.org????? ----- ??? Thu, 10 Aug 2006 22:07:34 -0600 ????David Mosberger-Tang ????David Mosberger-Tang ???[libunwind] moving libunwind to Savannah/kernel.org ????libunwind@napali.hpl.hp.com Since I'm no longer working for HP Labs (and haven't worked there for over a year now), I started to move the libunwind-related files to Savannah (web interface, mailing list, etc.) and kernel.org (GIT repository). The libunwind project web-site can now be found here: http://sv.nongnu.org/projects/libunwind/ I also created a new mailing list: libunwind-devel@nongnu.org Due to HP's privacy policy, I cannot simply move current subscribers of libunwind@linux.hpl.hp.com to this new mailing list, so if you continue to be interested in libunwind-development, please subscribe to the new mailing list *now*, before you forget! ;-) You can subscribe to the mailing list either by sending a mail with a body of "subscribe" to libunwind-devel-request@nongnu.org or you can do it via a web-browser at: http://lists.nongnu.org/mailman/listinfo/libunwind-devel If you want to browse the current source trees, you can do so at the following URLs: * for the current development tree: http://www.kernel.org/git/gitweb.cgi?p=libs/libunwind/libunwind.git * for the stable v0.98 tree: http://www.kernel.org/git/gitweb.cgi?p=libs/libunwind/libunwind-v0.98.git You can check out a GIT repository with the command: $ git clone git://git.kernel.org/pub/scm/libs/libunwind/libunwind.git (for development tree) or $ git clone git://git.kernel.org/pub/scm/libs/libunwind/libunwind-v0.98.git (for v0.98 tree) I probably am forgetting a couple of things, but hopefully this will get you started off in the right direction. Enjoy, --david -- Mosberger Consulting LLC, http://www.mosberger-consulting.com/ _______________________________________________ libunwind mailing list libunwind@linux.hpl.hp.com http://www.hpl.hp.com/hosted/linux/mail-archives/libunwind/ ----- End forwarded message ----- Regards - Wu Zhou From timoore@redhat.com Fri Aug 11 06:20:00 2006 From: timoore@redhat.com (Tim Moore) Date: Fri, 11 Aug 2006 06:20:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <20060810222045.dcqqdmvl0k0cgco8@imap.linux.ibm.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <1155218243.5279.56.camel@dijkstra.wildebeest.org> <44DB556C.3040407@redhat.com> <44DB718B.609@redhat.com> <44DB8D63.7030204@redhat.com> <44DBB4A5.2060304@redhat.com> <20060810222045.dcqqdmvl0k0cgco8@imap.linux.ibm.com> Message-ID: <44DC21B7.5060206@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wu Zhou wrote: > Quoting Tim Moore : >> The problem is that the file descriptor passed to libelf is *never* >> closed, whether or not the Elf Java object is garbage collected. I've >> added an explicit close() method for the Elf object so that getIsa() can >> release the file descriptor right away, and of course added the code to >> close the file descriptor. frysk-core TestRunner tests run now, but I'm >> going to sleep in it before checking in my code. >> > > That is just what I thought of. Can you post your code here? Attached, to be checked in soon. > > BTW. This make me think of another checkin policy: before checking in > code, we can post the diff on the mail-list, if nobody reject in a > specified time (one day, two days, or longer), it can get in. Another > option is for some people to review the code, but that will take some > more time. A code review before radical patches is good, but it's really more important to get the tests in shape so that lazy developers, like myself, will run them. >> Mea culpa for not running the tests more carefully, though in my defense >> the tests were broken at the time on x8664 :) > > I guess Mea culpa is French's saying for saying sorry. If it is, we > need say sorry here too. :-) These getIsa() code is from us anyway. > Actually, it's Latin :) This wasn't the fault of getIsa(); the code was doing something quite reasonable and exposed a bug elsewhere. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE3CG2eDhWHdXrDRURAm9uAJ9+YfrwX+so8llOqfACwsKFZw5H6wCfUYNh wP6LI8BoVV4EOnhFLzoTRdc= =RpmW -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: fd.diff Type: text/x-patch Size: 5382 bytes Desc: not available URL: From mark@klomp.org Fri Aug 11 10:14:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 11 Aug 2006 10:14:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog StressMapRead.ja ... In-Reply-To: <20060802182624.29409.qmail@sourceware.org> References: <20060802182624.29409.qmail@sourceware.org> Message-ID: <1155291280.2946.7.camel@dijkstra.wildebeest.org> Hi Adam, On Wed, 2006-08-02 at 18:26 +0000, ajocksch@sourceware.org wrote: > 2006-08-02 Adam Jocksch > > * StressMapRead.java: Renamed from TestMapRead since the test > is very cpu-intensive, also enabled test. Thanks! But make check still runs it. Is there another 'quick-check' make target that excludes the stress tests? Cheers, Mark From mark@klomp.org Fri Aug 11 12:01:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 11 Aug 2006 12:01:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <20060720155840.24856.qmail@sourceware.org> References: <20060720155840.24856.qmail@sourceware.org> Message-ID: <1155297656.2946.15.camel@dijkstra.wildebeest.org> Hi Tim, On Thu, 2006-07-20 at 15:58 +0000, moore@sourceware.org wrote: > Log message: > Throw a TaskException from some methods in Task. This is not a > RuntimeException, so fix all the affected callers too. Sorry for the late reply, but I was cleaning up my own code to see how to properly handle the new TaskExceptions and ran into this patch. In a couple of files we now just do things like: + catch (Task.TaskException e) + { + // XXX do real exception handling + } I am all for Checked Exceptions, but this is the worst way to handle them. This just swallows the exception completely without leaving any trace that anything went wrong. Now we are worse off then when we had unchecked exceptions. At least then the exception doesn't just disappear. Please do fix these locations by either explicitly printing the exception, or better wrapping them in RuntimeExceptions and rethrowing them. Thanks, Mark From mark@klomp.org Fri Aug 11 13:39:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 11 Aug 2006 13:39:00 -0000 Subject: frysk-imports frysk/proc/ChangeLog frysk/proc/ ... In-Reply-To: <20060811072652.414.qmail@sourceware.org> References: <20060811072652.414.qmail@sourceware.org> Message-ID: <1155303581.2946.23.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-08-11 at 07:26 +0000, moore@sourceware.org wrote: > 2006-08-11 Tim Moore > > bz 3014, 3032 > * Elf.java (close): New method to explicity clean up the libelf > object. > * cni/Elf.cxx (elf_begin): Store the file descriptor for later > use. Close it if there's an error creating the Elf object. > (elf_end): Close the file descriptor used to access the Elf file. O, the joys of combining manual resource management with a garbage collector finalization scheme. When we explicitly clean up the Elf file descriptor we have to be careful that the garbage collector doesn't kick in later and closes it again. If it does and the file descriptor number has been reused it will close a descriptor that might be in use! Luckily the fix is easy: 2006-08-11 Mark Wielaard * frysk-imports/lib/elf/cni/Elf.cxx (elf_end): Set fd field to -1. Committed, Mark diff -u -r1.18 Elf.cxx --- frysk-imports/lib/elf/cni/Elf.cxx 11 Aug 2006 07:26:52 -0000 1.18 +++ frysk-imports/lib/elf/cni/Elf.cxx 11 Aug 2006 13:31:09 -0000 @@ -116,7 +116,10 @@ lib::elf::Elf::elf_end(){ jint val = ::elf_end((::Elf*) this->pointer); if (fd >= 0) + { ::close(fd); + fd = -1; + } return val; } From cagney@redhat.com Fri Aug 11 19:12:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 11 Aug 2006 19:12:00 -0000 Subject: cvs head has lots of test failures In-Reply-To: <20060810215840.f6g2f8hf8c8so0c8@imap.linux.ibm.com> References: <1155214946.5279.41.camel@dijkstra.wildebeest.org> <17627.12098.758731.327893@localhost.redhat.com> <20060810215840.f6g2f8hf8c8so0c8@imap.linux.ibm.com> Message-ID: <44DCD68E.7000507@redhat.com> Wu Zhou wrote: > Quoting Elena Zannoni : > >> Mark Wielaard writes: >> > >> > We really need an autobuilder to catch such things early. >> >> We really need people to run make check before checking stuff in. >> Please folks be considerate to your fellow coders... >> > > That might not be enough. People might be working on a older source > tree. My idea is to do a cvs merge before attempting to check in > codes. And run "make check" on that tree instead. I agree with Elena, and note that it is both established best practice and part of test driven development. Developers need to both confirm that: - a clean check-out passes - adding a new test, that without other changes, has just that test failing - adding the changes cause both the new test to start passing, and the existing tests continue passing If bringing frysk up on a new ISA, where many tests may be failing, then this means confirming changes don't break the base isa (i386). Andrew From timoore@redhat.com Fri Aug 11 19:15:00 2006 From: timoore@redhat.com (Tim Moore) Date: Fri, 11 Aug 2006 19:15:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <1155297656.2946.15.camel@dijkstra.wildebeest.org> References: <20060720155840.24856.qmail@sourceware.org> <1155297656.2946.15.camel@dijkstra.wildebeest.org> Message-ID: <44DCD764.1090003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Wielaard wrote: > Hi Tim, > > + catch (Task.TaskException e) > + { > + // XXX do real exception handling > + } > > I am all for Checked Exceptions, but this is the worst way to handle > them. This just swallows the exception completely without leaving any > trace that anything went wrong. Now we are worse off then when we had > unchecked exceptions. At least then the exception doesn't just > disappear. Please do fix these locations by either explicitly printing > the exception, or better wrapping them in RuntimeExceptions and > rethrowing them. I agree that this is terrible style. I believe that you are not very likely to see a TaskException in the wild and are thus not going to be bitten by this right now, but the time to fix this is now. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE3NdkeDhWHdXrDRURAviaAKCEZOZaDjzt5u3xJ6HnLrPXHB1YKgCbB2I0 zpO6VB7rFFOxyni8f4bY6RU= =es1A -----END PGP SIGNATURE----- From woodzltc@cn.ibm.com Sun Aug 13 10:48:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Sun, 13 Aug 2006 10:48:00 -0000 Subject: First try of breakpoint support Message-ID: <20060813064819.60hq9zhm804048g4@imap.linux.ibm.com> Hi Mark, By using cvs source of 07-19, and applying three patches you mentioned, I had a try with the breakpoint. It seems there are some intermittent errors. The first time I run the testcase, it reported NPE on testInsertRemove, but it succeeded in the later tries. Please see the following sessions: [woodzltc@localhost frysk-core]$ ./TestRunner -l FINEST frysk.proc.TestBreakpoints Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ...ERROR java.lang.NullPointerException Running testAddLots(frysk.proc.TestBreakpoints) ...PASS Time: 5.129 There was 1 error: 1) testInsertRemove(frysk.proc.TestBreakpoints)java.lang.NullPointerException at frysk.proc.TestBreakpoints.testInsertRemove(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 3, Failures: 0, Errors: 1 [woodzltc@localhost frysk-core]$ ./TestRunner -l FINEST frysk.proc.TestBreakpoints Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS Running testAddLots(frysk.proc.TestBreakpoints) ...PASS Time: 4.84 OK (3 tests) [woodzltc@localhost frysk-core]$ ./TestRunner -l FINEST frysk.proc.TestBreakpoints Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS Running testAddLots(frysk.proc.TestBreakpoints) ...PASS Time: 3.282 OK (3 tests) [woodzltc@localhost frysk-core]$ Lookint through your words, I see that you also mentioned similar problems. So how are you going on with this kind of problem? I also have some thought about general breakpoint support. - the kprobe like mechanism to support multi-thread breakpoint seems to me a very good idea. Some candidate for holding the original instruction I can thought of are: .init section (they are not needed after the program starts up), ELF header or P-headers (storing these information somewhere else, so no need to look into them again), or an extra dynamically loaded library (through some kinds of dynamic code patching technique) - this kind of dynamic code patching technique might also be used for fast conditional breakpoint. To say this, I means something like Dyninst (http://www.cs.umd.edu/projects/dyninstAPI/). I know it is mainly used in non-interactive dynamic instrumentation. But I am not sure if it is proper to use it in interavtive debugging. Maybe there are some other technique feasible to do similar thing in interactive debugging. Any idea on how to implement fast conditional breakpoints in Frysk? - I see that you create a new breakpoint by hardwiring to LinuxIa32Breakpoint. We are thinking that breakpoint for LinuxPPC64 will be very similar except that we will use an illegal instruction opcode, which will trigger a SIGTRAP as well. The later work flow is the same, frysk.sys.Wait will detect this when inspecting the wait status, and handleTrappedEvent will be called. Is our understanding correct? Any thing we need to keep in mind when adding LinuxPPC64 support for this? And we will appreciate it very much if you can share your latest workable code with us. - Hardware watchpoint hit will also delieve SIGTRAP, then watchpoint might also share some work flow with breakpoint. Do you have some consideration in this aspect? - I remember you (or some one else) mentioned that system call tracing can't co-exist with single step. I don't have any knowledge about this before. Any reason for this? Is there any testcase to confirm this? What about inserting a breakpoint in the next instruction following system call to simulate stepping over system call? > Hi, > > Here is a first try of adding breakpointing support. It works for the > attached 3 testcases which simply test that a process can be stopped, > Code observers can be added (and removed) and the updateHit() method is > called whenever the process hits the breakpoint address the Code > Observer is interested in. > > It isn't integrated with the state machine yet. Which means it contains > some small hacks to force the Task into the right State at times. Adding > Code Observers is currently only supported in a Blocked state and > removing them only in the Running state. See the various XXX comments in > the patch. This also means there is no support yet for returning BLOCK > from Code.updateHit(). Even though it is clearly not finished I wanted > to post what I have to get some feedback. > > The idea is as follows: > - A Proc will have a new field that holds the BreakpointAddresses. > (breakpoints are shared between all Tasks of a Proc) > - BreakpointAddresses keep track of the actual Code Observers interested > in an breakpoint address and request to Proc to add or remove them > when necessary. > - A Breakpoint holds some state necessary for resetting, stepping and > continuing. When you create a Breakpoint for a task on an address that > is already installed you will get that instance back so it is easy to > reset, step or continue it. Currently interaction between the > Task/Proc is not based on the TaskState, but it obviously should. For > now the process is forced to stop when necessary. This should be > handled by the state machine. > - There is only support for LinuxIa32 simple INT3 breakpoints for now. > But it should be easy to create subclasses for other architectures. > (With a little luck I will get my hands on a x86-64/em64t style > machine this week and will try adding support for that then.) > Currently the stepping/continuing isn't thread/Task-safe. If there > is another Task running while resetting the LinuxIa32Breakpoint it > might miss hitting it temporarily. > > Here are the ChangeLog entries: > > 2006-07-19 Mark Wielaard > > * frysk/proc/Breakpoint.java: New file. > * frysk/proc/BreakpointAddresses.java: New file. > * frysk/proc/DummyProc.java (removeBreakpoint): Dummy > implementation. > (addBreakpoint): Likewise. > * frysk/proc/LinuxIa32Breakpoint.java: New file. > * frysk/proc/LinuxProc.java (removeBreakpoint): New method. > (addBreakpoint): New method. > * frysk/proc/Proc.java (breakpoints): New field. > (Proc(ProcId,Proc,Host,Task): Initialize breakpoints. > (requestUpdateBreakpoints): New method. > (addBreakpoint): New method. > (removeBreakpoint): New method. > * frysk/proc/Task.java (codeObservers): New field. > (requestAddCodeObserver): New method. > (requestDeleteCodeObserver): New method. > (notifyCodeBreakpoint): New method. > * frysk/proc/TaskObserver.java (updateHit): Update description. > * frysk/proc/TaskState.java (running.handleTrappedEvent): New > Method. > > * frysk/proc/TestBreakpoints.java: New test. > > 2006-07-19 Mark Wielaard > > * funit-breakpoints.c: New file. > > The testcase depends on the the ForkedProcess support I suggested: > http://sourceware.org/ml/frysk/2006-q3/msg00065.html > Let me know if that is a good idea to add. Otherwise I can rewrite my > testcases of course. But I rather don't :) > > When running by hand they always PASS: > $ ./TestRunner frysk.proc.TestBreakpoints > Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS > Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS > Running testAddLots(frysk.proc.TestBreakpoints) ...PASS > > Time: 1.057 > > OK (3 tests) > > But that depends on the PtraceByteBuffer vs errno patch that I > suggested: http://sourceware.org/ml/frysk/2006-q3/msg00077.html > Otherwise you will get some spurious interrupted system call > RuntimeExceptions. > > When run with 'make check' they intermittently fail. I haven't tracked > this down yet. But it might very well be because of timing and my > failure to properly integrate this yet with the rest of the state > machine. This is my next task. > > Comments and suggestions welcome. > > Cheers, > > Mark > Regards - Wu Zhou From mark@klomp.org Mon Aug 14 09:44:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 14 Aug 2006 09:44:00 -0000 Subject: First try of breakpoint support In-Reply-To: <20060813064819.60hq9zhm804048g4@imap.linux.ibm.com> References: <20060813064819.60hq9zhm804048g4@imap.linux.ibm.com> Message-ID: <1155548675.477.34.camel@dijkstra.wildebeest.org> Hi Wu Zhou, On Sun, 2006-08-13 at 06:48 -0400, Wu Zhou wrote: > By using cvs source of 07-19, and applying three patches you > mentioned, I had a try with the breakpoint. Thank you. > It seems there are some > intermittent errors. The first time I run the testcase, it reported > NPE on testInsertRemove, but it succeeded in the later tries. Please > see the following sessions: > [...] > Lookint through your words, I see that you also mentioned similar > problems. So how are you going on with this kind of problem? Yes, I also had some intermittent failures. That first try depended on the timing of the ptrace calls to be right. I have fixed that by integrating the code with the proc and task state machines. That makes sure that the various ptrace calls are made at the right time. This also makes the code much faster. > I also have some thought about general breakpoint support. > > - the kprobe like mechanism to support multi-thread breakpoint seems > to me a very good idea. Some candidate for holding the original > instruction I can thought of are: .init section (they are not needed > after the program starts up), ELF header or P-headers (storing these > information somewhere else, so no need to look into them again), or an > extra dynamically loaded library (through some kinds of dynamic code > patching technique) Yes, the only issue would be locking because we want the areas to be only used by one thread at a time. Ideally we would have some per Task section. Unfortunately we cannot use something like the per-thread-stack since those are not executable these days. Loading an extra dynamically loaded library is clever. But that might be pretty intrusive on the process we monitor. > - this kind of dynamic code patching technique might also be used for > fast conditional breakpoint. To say this, I means something like > Dyninst (http://www.cs.umd.edu/projects/dyninstAPI/). I know it is > mainly used in non-interactive dynamic instrumentation. But I am not > sure if it is proper to use it in interavtive debugging. Maybe there > are some other technique feasible to do similar thing in interactive > debugging. Any idea on how to implement fast conditional breakpoints > in Frysk? I hadn't seen that yet. Unfortunately it isn't Free Software and can only be used for research purposes. But the idea to have a rich library of dynamic instrumentation code is nice. We will most likely need something that can generate conditional breakpoints by code patching at some point. But for now I have kept the design as easy as possible and just have unconditional breakpoints. There are a lot of issues to think about when multiple threads might have different conditionals on their breakpoints. > - I see that you create a new breakpoint by hardwiring to > LinuxIa32Breakpoint. We are thinking that breakpoint for LinuxPPC64 > will be very similar except that we will use an illegal instruction > opcode, which will trigger a SIGTRAP as well. The later work flow is > the same, frysk.sys.Wait will detect this when inspecting the wait > status, and handleTrappedEvent will be called. Is our understanding > correct? Any thing we need to keep in mind when adding LinuxPPC64 > support for this? And we will appreciate it very much if you can > share your latest workable code with us. I'll post the rewritten code asap. I redesigned the state machine part 3 times now and I am still not completely satisfied, but having the code out means more feedback. I made the Breakpoint class even simpler, ignoring any possible optimizations for now. That should make it even simpler to get it up and running on another architecture quickly. The things to consider with this simple approach are 'branch-delay-slots' if your processor has those. In that case the simple, set/reset trapping-instruction doesn't work if the target is a branch instruction since then an instruction from the branch delay slot just after the branch might be executed before the breakpoint is hit. > - Hardware watchpoint hit will also delieve SIGTRAP, then watchpoint > might also share some work flow with breakpoint. Do you have some > consideration in this aspect? There doesn't seem to be a way to set those through something like ptrace. So we would need kernel support for that since they can normally only be set when running in kernel-privilege mode. But I haven't looked into this yet. If we can support them they shouldn't work to differently from how they work now by patching and resetting the original code with trapping instructions. It would certainly be a faster. > - I remember you (or some one else) mentioned that system call tracing > can't co-exist with single step. I don't have any knowledge about > this before. Any reason for this? Is there any testcase to confirm > this? What about inserting a breakpoint in the next instruction > following system call to simulate stepping over system call? There are 2 issues. The first is that the state machine support isn't integrated yet. Breakpoints and syscall tracing are similar, but different enough to make it non-trivial to use the same setup. The second is as you mention, single-stepping over a syscall instruction and interacting correctly with ptrace is a bit tricky. The other solution for the problem you mention above is to turn on syscall tracing whenever you set a breakpoint on a system call instruction. Both generate a SIGTRAP when ptrace is used. You can then just have a flag or a table that tells you how to interpret it (as syscall enter/leave or breakpoint or both). I haven't looked at how utrace can be used here. I don't have testcases yet. Those should indeed be written asap. Cheers, Mark From qiyaoltc@cn.ibm.com Mon Aug 14 10:38:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 14 Aug 2006 10:38:00 -0000 Subject: Stub bfd_getb32 and bfd_getl32 for libopcodes on ppc64 Message-ID: <20060814103013.GB2324@GreenHouse.cn.ibm.com> "bfd_getb32" and "bfd_getl32" are defined in libbfd, but are needed for libopcodes only on ppc64. This issue has been discussed in some threads, and lasted for nearly 3 months. We proposed that link "libbfd" and "libiberty" only on ppc64, but it seems that none here would like to use these two libraries. Now, we propose to stub these two methods on ppc64. 2006-08-02 Yao Qi * m4/frysk_libopcode.m4: New file and define FRYSK_LIBOPCODE. * acinclude.m4: Call FRYSK_LIBOPCODE. 2006-08-14 Yao Qi * frysk-imports/Makefile.am: Append "-lbfd_get " per macro USE_LIBOPCODES. * frysk-core/Makefile.am: Likewise. * frysk-gui/Makefile.am: Likewise. * frysk-gtk/Makefile.am: Likewise. * frysk-sys/Makefile.am: Likewise. 2006-08-14 Yao Qi * lib/opcodes/libbfd_get.c : New file to stub bfd_getb32 and bfd_getl32 on PPC64. Rebuild frysk on PPC64 and X86, and tested it. As I still do not have the write access to CVS tree, please review these patches and commit them if they are OK. Thanks in advance! -- Yao Qi -------------- next part -------------- Index: acinclude.m4 =================================================================== RCS file: /cvs/frysk/frysk-common/acinclude.m4,v retrieving revision 1.52 diff -u -r1.52 acinclude.m4 --- acinclude.m4 30 Jun 2006 17:04:58 -0000 1.52 +++ acinclude.m4 2 Aug 2006 04:59:32 -0000 @@ -133,3 +133,4 @@ test $UUDECODE = no && AC_ERROR([no uudecode program found, please install sharutils package]) FRYSK_USE_LIBUNWIND +FRYSK_LIBOPCODE --- /dev/null 2006-07-28 20:41:40.430451000 +0800 +++ m4/frysk_libopcode.m4 2006-08-02 10:02:26.000000000 +0800 @@ -0,0 +1,48 @@ +# This file is part of the program FRYSK. +# +# Copyright 2006, Red Hat Inc. +# +# FRYSK is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# FRYSK is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with FRYSK; if not, write to the Free Software Foundation, +# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +# +# In addition, as a special exception, Red Hat, Inc. gives You the +# additional right to link the code of FRYSK with code not covered +# under the GNU General Public License ("Non-GPL Code") and to +# distribute linked combinations including the two, subject to the +# limitations in this paragraph. Non-GPL Code permitted under this +# exception must only link to the code of FRYSK through those well +# defined interfaces identified in the file named EXCEPTION found in +# the source code files (the "Approved Interfaces"). The files of +# Non-GPL Code may instantiate templates or use macros or inline +# functions from the Approved Interfaces without causing the +# resulting work to be covered by the GNU General Public +# License. Only Red Hat, Inc. may make changes or additions to the +# list of Approved Interfaces. You must obey the GNU General Public +# License in all respects for all of the FRYSK code and other code +# used in conjunction with FRYSK except the Non-GPL Code covered by +# this exception. If you modify this file, you may extend this +# exception to your version of the file, but you are not obligated to +# do so. If you do not wish to provide this exception without +# modification, you must delete this exception statement from your +# version and license this file solely under the GPL without +# exception. + +AC_DEFUN([FRYSK_LIBOPCODE], [ +AC_REQUIRE([AC_CANONICAL_TARGET]) +case $target_cpu in +i?86|x86_64|ia64) + libopcodes=no;; +*) libopcodes=yes;; +esac +AM_CONDITIONAL([USE_LIBOPCODES], [test $libopcodes = yes]) +]) -------------- next part -------------- --- /dev/null 2006-08-14 08:54:56.447529000 +0800 +++ frysk-imports/lib/opcodes/libbfd_get.c 2006-08-14 14:32:14.000000000 +0800 @@ -0,0 +1,23 @@ + +unsigned long +bfd_getb32 (const void *p) +{ + const char *addr = p; + unsigned long v; + v = (unsigned long) addr[0] << 24; + v |= (unsigned long) addr[1] << 16; + v |= (unsigned long) addr[2] << 8; + v |= (unsigned long) addr[3]; + return v; +} +unsigned long +bfd_getl32 (const void *p) +{ + const char *addr = p; + unsigned long v; + v = (unsigned long) addr[0]; + v |= (unsigned long) addr[1] << 8; + v |= (unsigned long) addr[2] << 16; + v |= (unsigned long) addr[3] << 24; + return v; +} -------------- next part -------------- Index: frysk-core/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-core/Makefile.am,v retrieving revision 1.59 diff -u -r1.59 Makefile.am --- frysk-core/Makefile.am 7 Aug 2006 20:22:15 -0000 1.59 +++ frysk-core/Makefile.am 14 Aug 2006 06:36:58 -0000 @@ -85,7 +85,12 @@ if USE_LIBUNWIND GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a endif + +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -L../frysk-imports/lib/opcodes -lbfd_get +else GEN_GCJ_LDADD += -lopcodes +endif # XXX: This needs to be make less-architecture independant. Index: frysk-gtk/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-gtk/Makefile.am,v retrieving revision 1.18 diff -u -r1.18 Makefile.am --- frysk-gtk/Makefile.am 13 Jul 2006 01:26:42 -0000 1.18 +++ frysk-gtk/Makefile.am 14 Aug 2006 06:37:14 -0000 @@ -61,7 +61,12 @@ if USE_LIBUNWIND GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a endif + +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -L../frysk-imports/lib/opcodes -lbfd_get +else GEN_GCJ_LDADD += -lopcodes +endif # Hack, need to compile this entire sub-tree with JNI. AM_GCJFLAGS += -fjni Index: frysk-gui/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-gui/Makefile.am,v retrieving revision 1.63 diff -u -r1.63 Makefile.am --- frysk-gui/Makefile.am 8 Aug 2006 18:44:35 -0000 1.63 +++ frysk-gui/Makefile.am 14 Aug 2006 06:37:24 -0000 @@ -81,7 +81,12 @@ GEN_GCJ_LDADD += -L../frysk-gtk/EggTrayIcon GEN_GCJ_LDADD += -L../frysk-gtk/tlwidgets GEN_GCJ_LDADD += $(FRYSK_GUI_LIBS) + +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -L../frysk-imports/lib/opcodes -lbfd_get +else GEN_GCJ_LDADD += -lopcodes +endif # Skip the JUnit tests (exit with status 77) when there is no display; bug #3012. #TESTS_ENVIRONMENT = ( test $$tst != TestRunner || test -n "$$DISPLAY" || exit 77 ) && Index: frysk-imports/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-imports/Makefile.am,v retrieving revision 1.62 diff -u -r1.62 Makefile.am --- frysk-imports/Makefile.am 13 Jul 2006 01:26:41 -0000 1.62 +++ frysk-imports/Makefile.am 14 Aug 2006 06:37:34 -0000 @@ -85,7 +85,12 @@ GEN_GCJ_LDADD += ./libunwind/src/libunwind-$(libunwind_cpu).a endif +if USE_LIBOPCODES +noinst_LIBRARIES += lib/opcodes/libbfd_get.a +GEN_GCJ_LDADD += -lopcodes -L./lib/opcodes -lbfd_get +else GEN_GCJ_LDADD += -lopcodes +endif all-local: lib/elf/tests/test-core lib/elf/tests/helloworld.o Index: frysk-sys/Makefile.am =================================================================== RCS file: /cvs/frysk/frysk-sys/Makefile.am,v retrieving revision 1.27 diff -u -r1.27 Makefile.am --- frysk-sys/Makefile.am 13 Jul 2006 01:26:41 -0000 1.27 +++ frysk-sys/Makefile.am 14 Aug 2006 06:37:47 -0000 @@ -59,4 +59,9 @@ if USE_LIBUNWIND GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a endif + +if USE_LIBOPCODES +GEN_GCJ_LDADD += -lopcodes -L../frysk-imports/lib/opcodes -lbfd_get +else GEN_GCJ_LDADD += -lopcodes +endif From mark@klomp.org Mon Aug 14 11:06:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 14 Aug 2006 11:06:00 -0000 Subject: frysk-gtk CVS broken Message-ID: <1155553603.477.40.camel@dijkstra.wildebeest.org> Hi, frysk-gui seems completely broken at the moment. The Makefile seems to miss something and the c sources do some strange int/pointer casting which doesn't work (at least on 64 bit systems). Attached is a patch to get things to compile again. Just fixes the makefile in a way that I think is what was meant and storing pointers in longs to make sure there is at least enough room. But I don't really know what this code is supposed to do so I haven't really tested except to see that FryskGui still seems to work. Storing pointers in ints is not safe. There are some gtk+ type conversion macros that might help. But they come with big warnings: http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html Could someone more familiar with this code take a look and make CVS compile again? Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: compile-fixes.patch Type: text/x-patch Size: 5709 bytes Desc: not available URL: From mark@klomp.org Mon Aug 14 14:00:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 14 Aug 2006 14:00:00 -0000 Subject: frysk-gtk CVS broken In-Reply-To: <1155553603.477.40.camel@dijkstra.wildebeest.org> References: <1155553603.477.40.camel@dijkstra.wildebeest.org> Message-ID: <1155564028.477.58.camel@dijkstra.wildebeest.org> On Mon, 2006-08-14 at 13:06 +0200, Mark Wielaard wrote: > Could someone more familiar with this code take a look and make CVS > compile again? We discussed it on irc and decided that a compiling CVS is important enough to commit this. make check passes (except of course the dogtail tests). Committed as: 2006-08-14 Mark Wielaard * Makefile.am (ftk.jar): Add all classes to jar. * src/java/com/redhat/ftk/EventViewer.java (getSelectedTraces): Returns long[]. (ftk_eventviewer_get_selected_traces): Likewise. * src/jni/com_redhat_ftk_EventViewer.c (Java_com_redhat_ftk_EventViewer_ftk_1eventviewer_1get_1selected_1traces): Returns jlongArray. * src/widgets/ftkeventviewer.c (ftk_eventviewer_get_selected_traces): Uses longs. 2006-08-14 Mark Wielaard * StatusWidget.java (StatusWidget): MouseListener.mouseEvent() traces[] consists of longs. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Mon Aug 14 16:04:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 14 Aug 2006 16:04:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog StressMapRead.ja ... In-Reply-To: <1155291280.2946.7.camel@dijkstra.wildebeest.org> References: <20060802182624.29409.qmail@sourceware.org> <1155291280.2946.7.camel@dijkstra.wildebeest.org> Message-ID: <1155571430.477.71.camel@dijkstra.wildebeest.org> On Fri, 2006-08-11 at 12:14 +0200, Mark Wielaard wrote: > Hi Adam, > > On Wed, 2006-08-02 at 18:26 +0000, ajocksch@sourceware.org wrote: > > 2006-08-02 Adam Jocksch > > > > * StressMapRead.java: Renamed from TestMapRead since the test > > is very cpu-intensive, also enabled test. > > Thanks! But make check still runs it. Is there another 'quick-check' > make target that excludes the stress tests? Since this actively prevents running make check in any reasonable fashing I just filed a bug report on it and committed the following to skip this test completely for now: 2006-08-14 Mark Wielaard * StressMapRead.java (testMapRead): Add brokenXXX(3043). Cheers, Mark diff -u -r1.1 StressMapRead.java --- frysk/sys/StressMapRead.java 2 Aug 2006 18:26:24 -0000 1.1 +++ frysk/sys/StressMapRead.java 14 Aug 2006 16:01:49 -0000 @@ -78,7 +78,9 @@ public void testMapRead () { - + if (brokenXXX(3043)) + return; + PtraceByteBuffer buffer = new PtraceByteBuffer(pid, PtraceByteBuffer.Area.DATA); From npremji@redhat.com Mon Aug 14 16:06:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Mon, 14 Aug 2006 16:06:00 -0000 Subject: Eventviewer complex traces screenshots. Message-ID: <1155571563.2457.20.camel@to-rhaps5.toronto.redhat.com> Here is a picture of what the eventviewer would look like if traces could be enhanced based on cpu usages (or whatever other important data users might like) Tell me what you think. -------------- next part -------------- A non-text attachment was scrubbed... Name: complex_traces.png Type: image/png Size: 47961 bytes Desc: not available URL: From mcvet@redhat.com Mon Aug 14 17:58:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Mon, 14 Aug 2006 17:58:00 -0000 Subject: Eventviewer complex traces screenshots. In-Reply-To: <1155571563.2457.20.camel@to-rhaps5.toronto.redhat.com> References: <1155571563.2457.20.camel@to-rhaps5.toronto.redhat.com> Message-ID: <1155578280.2006.7.camel@towel.toronto.redhat.com> On Mon, 2006-08-14 at 12:06 -0400, Nurdin Premji wrote: > Here is a picture of what the eventviewer would look like if traces > could be enhanced based on cpu usages (or whatever other important data > users might like) > > Tell me what you think. > I think that we'll need to be careful about information being consistently represented in the EventViewer. As far as I understand it, the events in this widget are separated by a space not representative of the amount of time between them. But this would not work when representing CPU usage over time, because it is strictly a time-orientated plot. Will this CPU usage plot (and others like it) be displayed as a permanent addition to the EventViewer, or will there be a series of tabs to select various displays, such as default, CPU time, memory usage, page faults, etc? That being said, I agree that incorporating more information into the monitor is important and we should continue to pursue it. Mike From tromey@redhat.com Tue Aug 15 01:33:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 15 Aug 2006 01:33:00 -0000 Subject: Patch: add two accessors to Syscall Message-ID: I was reading a thread on the valgrind list about finding where a bad close() was called http://article.gmane.org/gmane.comp.debugging.valgrind/5996 and I thought this would be a simple thing for frysk to do. First I wanted the appended patch to let my code inspect a Syscall. Could someone check this in? (I didn't add all the accessors, just the ones I needed.) I hacked up ftrace.java to do what I wanted (it was *very* easy this way -- nice :-), but on my FC5 box I always get an I/O error when trying to get the stack trace of a task (failure attached). Any ideas? Also I noticed a few other oddities here and there. For instance, SyscallEventInfo.returnCode returns a long -- but apparently does not sign-extend the syscall's actual return value. This leads to the unobvious test: (int) syscallEventInfo.returnCode(task) < 0 I wasn't sure whether you'd prefer email about little things like this or whether I should just drop stuff directly in bugzilla... let me know. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: P Type: application/octet-stream Size: 753 bytes Desc: patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: S Type: application/octet-stream Size: 1188 bytes Desc: stack trace URL: From woodzltc@cn.ibm.com Tue Aug 15 02:29:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 15 Aug 2006 02:29:00 -0000 Subject: First try of breakpoint support Message-ID: <20060814222929.w8o6joo64gggo4w4@imap.linux.ibm.com> Quoting Mark Wielaard : > Yes, I also had some intermittent failures. That first try depended on > the timing of the ptrace calls to be right. I have fixed that by > integrating the code with the proc and task state machines. That makes > sure that the various ptrace calls are made at the right time. This also > makes the code much faster. Great! Nice to know that it is fixed. >> I also have some thought about general breakpoint support. >> >> - the kprobe like mechanism to support multi-thread breakpoint seems >> to me a very good idea. Some candidate for holding the original >> instruction I can thought of are: .init section (they are not needed >> after the program starts up), ELF header or P-headers (storing these >> information somewhere else, so no need to look into them again), or an >> extra dynamically loaded library (through some kinds of dynamic code >> patching technique) > > Yes, the only issue would be locking because we want the areas to be > only used by one thread at a time. Ideally we would have some per Task > section. Unfortunately we cannot use something like the per-thread-stack > since those are not executable these days. Loading an extra dynamically > loaded library is clever. But that might be pretty intrusive on the > process we monitor. Yes, non-executable stack is a problem. Is there any way for the debugger to change the access attribute of the debuggee pages? AFAIK, ptrace can't do that. I am now thinking if utrace can do that. It seems to me not that hard. Utrace can register a hook function to do that in my opinion. If this kind of mechanism is available, it might also help in watchpoint implementation. To set a write watchpoint on some address, we can set that page to be read-only, a page fault will trigger when a write attempt is tried on it, then debugger can fetch that and report a write hit; vice versa for read watchpoint. Any ideas? Yes, loading extra dynamically loaded library is somewhat intrusive. In fact, many thing debugger are doing are intrusive in some aspect. The difference is the intrusive degree. What degree of intrusiveness can we accept? >> - this kind of dynamic code patching technique might also be used for >> fast conditional breakpoint. To say this, I means something like >> Dyninst (http://www.cs.umd.edu/projects/dyninstAPI/). I know it is >> mainly used in non-interactive dynamic instrumentation. But I am not >> sure if it is proper to use it in interavtive debugging. Maybe there >> are some other technique feasible to do similar thing in interactive >> debugging. Any idea on how to implement fast conditional breakpoints >> in Frysk? > > I hadn't seen that yet. Unfortunately it isn't Free Software and can > only be used for research purposes. But the idea to have a rich library > of dynamic instrumentation code is nice. We will most likely need > something that can generate conditional breakpoints by code patching at > some point. But for now I have kept the design as easy as possible and > just have unconditional breakpoints. There are a lot of issues to think > about when multiple threads might have different conditionals on their > breakpoints. Yes. multi-thread debugging is always a hard problem. Maybe we can list first all the possible problem we might encounter. And then current available solution, their pros and cons...what support low level provide? what we need to ask low-level for? ... based on these, we might come up a better solution. Though there are really quite a lot of works to be done. >> - I see that you create a new breakpoint by hardwiring to >> LinuxIa32Breakpoint. We are thinking that breakpoint for LinuxPPC64 >> will be very similar except that we will use an illegal instruction >> opcode, which will trigger a SIGTRAP as well. The later work flow is >> the same, frysk.sys.Wait will detect this when inspecting the wait >> status, and handleTrappedEvent will be called. Is our understanding >> correct? Any thing we need to keep in mind when adding LinuxPPC64 >> support for this? And we will appreciate it very much if you can >> share your latest workable code with us. > > I'll post the rewritten code asap. I redesigned the state machine part 3 > times now and I am still not completely satisfied, but having the code > out means more feedback. I made the Breakpoint class even simpler, > ignoring any possible optimizations for now. That should make it even > simpler to get it up and running on another architecture quickly. The > things to consider with this simple approach are 'branch-delay-slots' if > your processor has those. In that case the simple, set/reset > trapping-instruction doesn't work if the target is a branch instruction > since then an instruction from the branch delay slot just after the > branch might be executed before the breakpoint is hit. Thanks in advance for that. We will be very happy to go thru your code and to see if we can provide any feedback. And it is really awful for me to hear that you change the state machines three times (I am wishing that you don't change that too much so that I don't need to spend the same time I need to understand it the first time. :-). For branch-delay-slot, I am not sure if power processors have that. We will check that. >> - Hardware watchpoint hit will also delieve SIGTRAP, then watchpoint >> might also share some work flow with breakpoint. Do you have some >> consideration in this aspect? > > There doesn't seem to be a way to set those through something like > ptrace. On ppc64, there is an extra ptrace command which can do this. I am not very sure about the situation in i386 though. > So we would need kernel support for that since they can normally > only be set when running in kernel-privilege mode. But I haven't looked > into this yet. If we can support them they shouldn't work to differently > from how they work now by patching and resetting the original code with > trapping instructions. It would certainly be a faster. > >> - I remember you (or some one else) mentioned that system call tracing >> can't co-exist with single step. I don't have any knowledge about >> this before. Any reason for this? Is there any testcase to confirm >> this? What about inserting a breakpoint in the next instruction >> following system call to simulate stepping over system call? > > There are 2 issues. The first is that the state machine support isn't > integrated yet. Breakpoints and syscall tracing are similar, but > different enough to make it non-trivial to use the same setup. The > second is as you mention, single-stepping over a syscall instruction and > interacting correctly with ptrace is a bit tricky. The other solution > for the problem you mention above is to turn on syscall tracing whenever > you set a breakpoint on a system call instruction. Both generate a > SIGTRAP when ptrace is used. You can then just have a flag or a table > that tells you how to interpret it (as syscall enter/leave or breakpoint > or both). I haven't looked at how utrace can be used here. > > I don't have testcases yet. Those should indeed be written asap. Yes. A testcase can help understand this situation more easily. I am wishing someone can do that. :-) Regards - Wu Zhou From qiyaoltc@cn.ibm.com Tue Aug 15 03:24:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 15 Aug 2006 03:24:00 -0000 Subject: Patch: add two accessors to Syscall In-Reply-To: References: Message-ID: <20060815031611.GC2324@GreenHouse.cn.ibm.com> On Mon, Aug 14, 2006 at 07:28:33PM -0600, Tom Tromey wrote: > I was reading a thread on the valgrind list about finding where a bad > close() was called > > http://article.gmane.org/gmane.comp.debugging.valgrind/5996 > > and I thought this would be a simple thing for frysk to do. > > First I wanted the appended patch to let my code inspect a Syscall. > Could someone check this in? (I didn't add all the accessors, just > the ones I needed.) > > I hacked up ftrace.java to do what I wanted (it was *very* easy this > way -- nice :-), but on my FC5 box I always get an I/O error when > trying to get the stack trace of a task (failure attached). Any > ideas? In the log, I find that, ...... ...... at inua.eio.ByteBuffer.getInt(fdtrace) at frysk.rt.StackCallbacks.accessMem(fdtrace) at lib.unwind.StackTraceCreator.unwind_setup(fdtrace) ..... ..... libunwind could not work with frysk core, and its java binding could not do backtrace. Here is a bug about it. http://sources.redhat.com/bugzilla/show_bug.cgi?id=2936 We are investigating the libunwind internals, and find that, libunwind could be divided to four parts logically, ptrace, unwind, dwarf/elf, and target, but unfortunately, ptrace part is closely-coupled with dwarf part and unwind part. It is hard to replace ptrace in libunwind with PtraceThread in frysk core via java binding. We will post our proposal here when we make it more clear. Here is one problem about libunwind we met, if anyone here could explain them for us, thanks very much. unwind table. What is the meaning of this? I searched it in DWARF3 specification, but little could be found. > > Also I noticed a few other oddities here and there. For instance, > SyscallEventInfo.returnCode returns a long -- but apparently does not > sign-extend the syscall's actual return value. This leads to the > unobvious test: > > (int) syscallEventInfo.returnCode(task) < 0 SyscallEventInfo.returnCode is only a abstract method that should be overridden in sub-class, such as in LinuxPPC64, LinuxPPC, and LinuxIa32. The return code is sign-extended in LinuxPPC64 at least. > > I wasn't sure whether you'd prefer email about little things like this > or whether I should just drop stuff directly in bugzilla... let me > know. It is easy to track the bug in bugzilla, but not everyone here could be notified when bug is filed or updated. It is great, if we could post the information about the bug in maillist after we open it in bugzilla. > > Tom > -- Yao Qi From mark@klomp.org Tue Aug 15 13:14:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 15 Aug 2006 13:14:00 -0000 Subject: ForkedProcess (Was: Kill and refresh) In-Reply-To: <1154693489.2982.38.camel@dijkstra.wildebeest.org> References: <1152807064.2738.58.camel@elsschot.wildebeest.org> <44B7273F.6040708@redhat.com> <1152879437.2529.31.camel@elsschot.wildebeest.org> <1152881355.2529.41.camel@elsschot.wildebeest.org> <1154003024.2977.1.camel@dijkstra.wildebeest.org> <44D20733.5000406@redhat.com> <1154693489.2982.38.camel@dijkstra.wildebeest.org> Message-ID: <1155647626.3023.24.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-08-04 at 14:11 +0200, Mark Wielaard wrote: > > - since it is only intended for testing and testing fork, can this live > > in TestLib - keeps frysk.sys's interfaces as close as possible to the > > underlying mechanism? > > Can do. Will move it to TestLib. It was just so similar to the rest of > the Fork class that it seemed natural to put it there. This proved more difficult than I thought. TestLib uses junit and we would need cni headers for that. I couldn't figure out an easy way to generate those in the fryks-imports and then use those inside frysk-proc. So I created a separate package private test utility class in frysk.proc for those tests that need it. If you rather have it in TestLib itself please do file a bug report and assign it to me and I will have another look at the build-magic needed. The usage of Errno outside the frysk.sys package is also a bit confusing. I ended up creating a subclass to be able to throw. If there is a better mechanism for this please do let me know. 2006-08-15 Mark Wielaard * ForkTestLib.java: New file. * cni/ForkTestLib.cxx: Likewise. Committed as attached. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: ForkTestLib.patch Type: text/x-patch Size: 10339 bytes Desc: not available URL: From mark@klomp.org Tue Aug 15 13:39:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 15 Aug 2006 13:39:00 -0000 Subject: FC6 kernel lockups? Message-ID: <1155649135.3023.32.camel@dijkstra.wildebeest.org> Hi, Is anyone else testing on FC6. I seem to still get the occasional lockup even with the latest kernel when running our test suite. This is with kernel 2.6.17-1.2564 on a x86 system. It looks to be happening in testTaskBlockExec (frysk.proc.TestExec), but since the machine locks up solid it is hard to tell. Anyone else seeing that? Also something changed in libvte-java, someone renamed a method from the obviously wrongly spelled 'setBackGroud' to 'setBackGround'. We were using the misspelled method. I don't see how to easily make this work, except with some configure voodoo, on both FC5 and FC6 for now since the old method was just removed. Cheers, Mark From cagney@redhat.com Tue Aug 15 14:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 15 Aug 2006 14:38:00 -0000 Subject: Stub bfd_getb32 and bfd_getl32 for libopcodes on ppc64 In-Reply-To: <20060814103013.GB2324@GreenHouse.cn.ibm.com> References: <20060814103013.GB2324@GreenHouse.cn.ibm.com> Message-ID: <44E1DC52.2050704@redhat.com> Yao Qi wrote: > "bfd_getb32" and "bfd_getl32" are defined in libbfd, but are needed > for libopcodes only on ppc64. This issue has been discussed in some > threads, and lasted for nearly 3 months. We proposed that link "libbfd" > and "libiberty" only on ppc64, but it seems that none here would like > to use these two libraries. Now, we propose to stub these two methods > on ppc64. > Yao, nice Just a simplification: I'd be unconditionally compiling this code (don't make it conditional on ppc/ppc64), that way we always know that the code compiles. The other is that the endian .c file needs (C) IBM along with frysk's standard licence. With that tweaked (assuming your account is working, and assuming i386 continues to pass), check it in. Andrew From cagney@redhat.com Tue Aug 15 14:52:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 15 Aug 2006 14:52:00 -0000 Subject: FC6 kernel lockups? In-Reply-To: <1155649135.3023.32.camel@dijkstra.wildebeest.org> References: <1155649135.3023.32.camel@dijkstra.wildebeest.org> Message-ID: <44E1DFC9.3030100@redhat.com> Mark Wielaard wrote: > Hi, > > Is anyone else testing on FC6. I seem to still get the occasional lockup > even with the latest kernel when running our test suite. This is with > kernel 2.6.17-1.2564 on a x86 system. It looks to be happening in > testTaskBlockExec (frysk.proc.TestExec), but since the machine locks up > solid it is hard to tell. Anyone else seeing that? > > Guess not :-/ Why not <> towns.toronto (1) and then run: ./TestRunner -r 1000 frysk.proc.TestExec on that (and your machine) to see what happens (I think phil is done with the machine). From last time, it may not be that test, just that that was the last flushed output :-( Chris, you've a dedicated machine right? Can you set up and try similar? Something to just repeatedly run the frysk tests. Andrew (1) On second thoughts, perhaps don't, my last two yum-update attempts on towns appear to have hung :-/ From cagney@redhat.com Tue Aug 15 15:02:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 15 Aug 2006 15:02:00 -0000 Subject: FC6 kernel lockups? In-Reply-To: <1155649135.3023.32.camel@dijkstra.wildebeest.org> References: <1155649135.3023.32.camel@dijkstra.wildebeest.org> Message-ID: <44E1E213.5030507@redhat.com> Mark Wielaard wrote: > Hi, > > Is anyone else testing on FC6. I seem to still get the occasional lockup > even with the latest kernel when running our test suite. This is with > kernel 2.6.17-1.2564 on a x86 system. It looks to be happening in > testTaskBlockExec (frysk.proc.TestExec), but since the machine locks up > solid it is hard to tell. Anyone else seeing that? > > Also something changed in libvte-java, someone renamed a method from the > obviously wrongly spelled 'setBackGroud' to 'setBackGround'. We were > using the misspelled method. I don't see how to easily make this work, > except with some configure voodoo, on both FC5 and FC6 for now since the > old method was just removed. > > Cheers, > > Mark > > So i've this straight, FC-5 has setBackGroud; and FC-6 has setBackGround? So either FC-5 should get the "correct" method added, or FC-6 get a backward compatible method added? I suspect the former (tweak FC-5) moves us forward more. Was there a bug? Stepan, can this be fixed? Andrew From cmoller@redhat.com Tue Aug 15 15:05:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Tue, 15 Aug 2006 15:05:00 -0000 Subject: FC6 kernel lockups? In-Reply-To: <44E1DFC9.3030100@redhat.com> References: <1155649135.3023.32.camel@dijkstra.wildebeest.org> <44E1DFC9.3030100@redhat.com> Message-ID: <44E1E2A5.2000206@redhat.com> Andrew Cagney mumbled something on 08/15/2006 10:52 AM: > Mark Wielaard wrote: >> Hi, >> >> Is anyone else testing on FC6. I seem to still get the occasional lockup >> even with the latest kernel when running our test suite. This is with >> kernel 2.6.17-1.2564 on a x86 system. It looks to be happening in >> testTaskBlockExec (frysk.proc.TestExec), but since the machine locks up >> solid it is hard to tell. Anyone else seeing that? >> >> > Guess not :-/ frysk@sources.redhat.com didn't like my text/html reply to that... > > Why not <> towns.toronto (1) and then run: > ./TestRunner -r 1000 frysk.proc.TestExec > on that (and your machine) to see what happens (I think phil is done > with the machine). From last time, it may not be that test, just that > that was the last flushed output :-( > > Chris, you've a dedicated machine right? Can you set up and try > similar? Something to just repeatedly run the frysk tests. It's not a dedicated machine, it's my main devel machine. But I stuff the latest fc6 kernel into it every afternoon, along with the latest cvs frysk, and let them have a go at each other. > > Andrew > > (1) On second thoughts, perhaps don't, my last two yum-update attempts > on towns appear to have hung :-/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From pmuldoon@redhat.com Tue Aug 15 15:12:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 15 Aug 2006 15:12:00 -0000 Subject: FC6 kernel lockups? In-Reply-To: <1155649135.3023.32.camel@dijkstra.wildebeest.org> References: <1155649135.3023.32.camel@dijkstra.wildebeest.org> Message-ID: <44E1E44F.5060404@redhat.com> Mark Wielaard wrote: > Hi, > > Is anyone else testing on FC6. Since yesterday. > I seem to still get the occasional lockup > even with the latest kernel when running our test suite. This is with > kernel 2.6.17-1.2564 on a x86 system. [pmuldoon@dhcp-199 ~]$ rpm -q kernel kernel-2.6.17-1.2564.fc6 > Also something changed in libvte-java, someone renamed a method from the > obviously wrongly spelled 'setBackGroud' to 'setBackGround'. We were > using the misspelled method. I don't see how to easily make this work, > except with some configure voodoo, on both FC5 and FC6 for now since the > old method was just removed. > > Adam wrote a patch - just a compatibility layer. Sent it to Stepan. Stepan will put them in the RPM so both methods will work. Regards Phil From tromey@redhat.com Tue Aug 15 15:16:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 15 Aug 2006 15:16:00 -0000 Subject: Patch: add two accessors to Syscall In-Reply-To: <20060815031611.GC2324@GreenHouse.cn.ibm.com> References: <20060815031611.GC2324@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: Yao> libunwind could not work with frysk core, and its java binding could Yao> not do backtrace. Here is a bug about it. Yao> http://sources.redhat.com/bugzilla/show_bug.cgi?id=2936 Thanks, I added myself. >> Also I noticed a few other oddities here and there. For instance, >> SyscallEventInfo.returnCode returns a long -- but apparently does not >> sign-extend the syscall's actual return value. Yao> SyscallEventInfo.returnCode is only a abstract method that should be Yao> overridden in sub-class, such as in LinuxPPC64, LinuxPPC, and LinuxIa32. Yao> The return code is sign-extended in LinuxPPC64 at least. I think it would be preferable if all platforms did the same thing. A little javadoc in SyscallEventInfo explaining the return results of these methods would help here... it would let folks porting to a new platform know what to do. (javadoc everywhere in frysk would be quite helpful...) Tom From mark@klomp.org Tue Aug 15 17:18:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 15 Aug 2006 17:18:00 -0000 Subject: Breakpoints Message-ID: <1155662239.3023.49.camel@dijkstra.wildebeest.org> Hi, This finally adds and merges the breakpoint support into frysk-core. I get clean make check results on both x86 and x86_64. But other architectures aren't supported at the moment. There are two main differences with the first attempt. First it is a little less abstract. The earlier version had a little bit too much design for non-existing cases. I have stripped out anything not explicitly needed at this time. The only architecture dependent code is in the main BreakPoint class itself which just checks the Isa. No more abstract classes. The second main difference is is that it is now actually integrated in the task and proc state machines. This means that there are no "timing issues" anymore. And we can use the eventloop to serialize events. After a couple of tries to integrate this with the syscall states and trying to have another task hierarchy like the syscall states I ended up not introducing new task states. It was really a nightmare to keep track of the state explosion. So what I ended up doing was to add a little "extra state" to the Running State. So the Running State is now 'magic' in that it knows about any pending CodeObservers that need to be added or removed and it knows about the current Breakpoint the Task is taking. I find this setup clean and clear. But that is obviously because I spend so much time thinking on it and not having much success with emulating the traditional state machine design. I do think doing it this way can also simplify some of the syscall state explosion, which should make it easier to combine syscall tracing and breakpoints. Comments and/or flames more than welcome. 2006-08-15 Mark Wielaard * funit-breakpoints.c: New test prog. 2006-08-15 Mark Wielaard * frysk/proc/Breakpoint.java: New file. * frysk/proc/BreakpointAddresses.java: Likewise. * frysk/proc/Proc.java (breakpoints): New final field. (Proc): Initialize breakpoints. (requestAddCodeObserver): New method. (requestDeleteCodeObserver): New method. * frysk/proc/Task.java (handleAddCodeObserver): New method. (handleDeleteCodeObserver): New method. (codeObservers): New field. (requestAddCodeObserver): New method. (requestDeleteCodeObserver): New method. (notifyCodeBreakpoint): Likewise. * frysk/proc/TaskCodeObservation.java: New file. * frysk/proc/TaskObserver.java (updateHit): Update documentation. * frysk/proc/TaskState.java (handleAddCodeObserver): New method. (handleDeleteCodeObserver): New method. (Running.handleStoppedEvent): Add and remove pending CodeObservers. (Running.steppingBreakpoint): New field. (Running.handleTrappedEvent): New method. (Running.pendingCodeObservers): New field. (Running.PendingCodeObserver): New struct. (Running.handleAddCodeObserver): New method. (Running.handleDeleteCodeObserver): New method. (BlockedSignal.handleAddCodeObserver): New method. (BlockedSignal.handleDeleteCodeObserver): New method. * frysk/proc/TestBreakpoints.java: new file. Committed as attached. Please let me know if I broke something horribly or if you think the current setup is not clear. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: breakpoint.patch Type: text/x-patch Size: 51153 bytes Desc: not available URL: From npremji@redhat.com Tue Aug 15 19:02:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Tue, 15 Aug 2006 19:02:00 -0000 Subject: Nurdin's plans for the eventviewer Message-ID: <1155668531.2496.14.camel@to-rhaps5.toronto.redhat.com> So I created a few bugzilla feature requests against myself on thursday and here is where I plan on going with the eventviewer. First: clean the clutter, which I keep forgetting to do. Things to do here: Get rid of the buttons, I'm not a big button fan, so I have plans to introduce functionality that will obsolete these buttons. (Hold button, see Bug 3021) Bug 3025: Vertical time EventViewer. So make the eventviewer time axis on the vertical, that way the event log can go on the right side of it, and the events in the text log can be linked up with the events in the eventviewer. So what the event log needs to morph into is something along the lines of the tree views on the left hand, where each element can be selected, and maybe taken to the event in the eventviewer. Bug 3023: Complex traces: What I mean by this is instead of having a trace that has only one straight horizontal (or soon to be vertical) line, it becomes a jagged line based on cpu usage, or memory usage, or more important things based on user preference. Somehow, I haven't really thought about what it should be based on, how to change between them, etc. So that shouldn't really require anything from the rest of the monitor, mostly an eventviewer feature. The way I plan to do this is that each trace gets its own little area, (ex. ten pixels) and its % of cpu/whatever usage is based on those 10 pixels. I think this would be better explained with a screen shot, which I will draw up and post to the list to see if people like. Bug 3022: Complex scrollbar: There is the idea of having the scrollbar contain information about the eventviewer directly inside it. Sort of an "overall" view of the eventviewer. I like Andrew Cagney's idea/concern that the user should be able to see multiple processes interacting at the same time, as that would be useful for debugging. However I don't know how we can get a massive number of processes and threads shown in a small-medium sized widget. My short answer is that we should assume a limit of several threads/processes as I don't believe that the human mind can keep track of so many processes. In terms of implementation, I have no idea where to start. Maybe constantly take a bitmap of the eventviewer? Or render directly into it. I dunno. Bug 3021: Mouse-edge Scrolling: Dragging the mouse to the edges of the eventviewer should be able to scroll the eventviewer in that direction. A side effect of this can be that dragging the mouse all the way to the right enables auto-updates (what the hold button deactives) and focusing the eventviewer anywhere left of the right-most edge will deactivate auto-updates (activate hold). This way I can get rid of the hold button. As for the Center button, it really is just a zoom-out feature as much as I can tell, so once I try to enable mouse wheel zooming I shouldn't need to use that anymore, a simple push of the scroll all the way down should zoom out all the way. From ezannoni@redhat.com Tue Aug 15 20:05:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Tue, 15 Aug 2006 20:05:00 -0000 Subject: frysk minutes 20060815 Message-ID: <17634.10238.800583.159286@localhost.redhat.com> Attendees: Adam, Sami, Mike, Nurdin, Phil, Rick, Alex, Jason, Stan, Richard, Andrew, Ivan, Mark, Chris, Roland, Elena. Libunwind: the big issue identified is the remote backtrace vs. local backtrace. Unwind_remote_only is a problem. Remote dwarf2 side of things was never finished. A chunk of code was never completed. Always assume it's the current process address space, not the remote one. I.e. it tries to give you the backtrace for Frysk itself instead of for the debugged process. See Richard's postings to the libunwind mailing list. Once the infrastructure is in place IBM can do the ppc port themselves. frysk repository has rth latest changes. rth was rearranging code internally to libunwind so that it looked like glibc in its layout. ATM there are bits in x86 that are dedicated to linux and there is no way to share among other arches. Also identified number of local unwindng bugs that ought to be fixed anyway. Structure that libunwind uses to store machine state shouldn't need to change between local and remote code. rth hasn't looked at teh remote libunwind roblem yet. Seems that there is an interface missing to retrieve the remote dwarf2 tables. Uses structures that don't get exported, this needs to be fixed. Adam to file bugs in bugzilla, cc Jason and Alex. Tim: on vacation. It's a holiday everywhere but the USA :-( Mark: checked in all his WIP changes. FC6 state is not too good. Stuff works elsewhere. Are there more features needed for this code? General way to transition a running thread to a stopped state and back to a running thread. The need is because one wants to make operations on the thread while stopped. We need a refactoring for this, so that it's code shared amongst different subsystems. Comment about keeping state within state. There are precedents in Frysk that already do that. Mark has 2 possible work items: Combining breakpoints with syscall tracing and making breakpoints thread safe. Agreemet that syscalls & breakpoints is 1st item to work on. Having breakpoint while tracing systemcalls doesn't work right now. There is some problem with the current kernels. So it will never be perfect. But we'll get the basis covered. Utrace: - s390 nominally working, but the guy went on vacation. Working for basic stuff. - ia64 making progress. Another few days. Chris hasn't run the .ko version of the utrace work yet. This is just plain ptrace() (but with the new implementatin under the hood). Next thing is to get the kernel modules version performance numbers. Terminal: Still stuck on the hung pty. Need to get help from Bedhad at this point. Need to do 3 calls to set things up correctly when launching a new terminal. Talk to Roland. Parser: Stan is at the point that he can start hooking up libdw. Use the java bindings. Could look at what stap does. Instruction parser is in relatively good shape. Console can be brought up and expression tpes in and it uses the expresion evaluator. Phil: start figuring out which bugs to fix first. Refactoring the monitor to allow multiple sessions. Nurdin: Event viewer click a trace -> highlights it. Right click on a trace: brings up a context menu. Dogtail: Phil updated to fc6t2: dogtail works ok there. But they still don't work in headless. Dogtail not working in fc5. Sami: Audit-libs and audit-libs-devel. Has list of syscalls and function to print syscalls too. Will be using that from frysk. Also almost done with Frysk article. Mike: libunwind work, and doing some work with the monitor. Found nasty bug (missed details sorry). IBM: they got sware access, yeah. They are still stuck on the bugzilla upstream: sware bug 2479 and has a corresponging gtk bug. From zhengyo@cn.ibm.com Wed Aug 16 02:15:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 16 Aug 2006 02:15:00 -0000 Subject: Test result of utrace on PPC64(based on Fedoracore 6 Test 2 release). Message-ID: <1155694227.2913.95.camel@YZ_X86_64> Hi all, Fedora Core 6 Test 2 has been released on July 7, 2006. Based on it, we do one thorough test on PPC64. The test consists of the following two parts and we summarize what we have tested as follows, wishing it can be helpful for you to get a picture of how utrace works on PPC64. 1. Gdb's test on the FC6 test 2 release In this part, we build gdb and run gdb testsuite on PPC64 with the kernel 2.6.17-1.2517(shipped with FC6 Test 2). As for comparison, we also run gdb testsuite on kernel 2.6.17-1.2145(without utrace patched in but with the original ptrace). On each kernel, we run gdb testsuite twice: the first by compiling them into 32bits ELF files and the second by compiling them into 64bits ELF files. The test results are shown in the following tables: Testcase 32on64on64(2.6.17-1.2145) 32on64on64(2.6.17-1.2517) expected passes 10673 10660 unexpected failures 339(3.18%) 356(3.34%) expected failures 40 40 known failures 59 59 unresolved testcases 15 14 untested testcases 5 4 unsupported tests 11 11 Testcase 64on64on64(2.6.17-1.2145) 64on64on64(2.6.17-1.2517) expected passes 10684 10665 unexpected failures 392(3.67%) 409(3.835%) expected failures 44 44 known failures 60 60 unresolved testcases 4 4 untested testcases 1 1 unsupported tests 12 14 Seen from the numbers in the above tables, the test results are very encouraging. There're just only more 17 unexpected failures on the kernel patched in utrace than on the kernel with the original ptrace! If anyone think the detailed test results might be helpful, we're willing to send the test results(including all test logs) to you. 2. utrace's testsuite on the FC6 test 2 release As to utrace's testsuite, there are two test ways: one is to do the test through building case into executable program; another is through compiling case into kernel module. If we choose the former test way, all testcases in ntrace package(you can get it from roland's website: http://people.redhat.com/roland/utrace/) work well, the kernel runs well during and after the test. All seems to be good. However, if you build testcase(for example, crash-suspend.c, also got from the roland's website) into kernel module, insert the module and then do the test, the kernel may crash once in a while. Best regards Yong Zheng From ajocksch@redhat.com Wed Aug 16 14:44:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Wed, 16 Aug 2006 14:44:00 -0000 Subject: libunwind progress Message-ID: <44E32F4B.7070809@redhat.com> I've attached the patch to enable using dwarf_find_proc_info to be applied in frysk-imports. This is how I'd recommend using it: 1) Build frysk normally 2) Apply the patch to frysk-imports. 3) Comment out the lines in frysk-imports' generated makefile that build fryski and build frysk-imports 4) cd to frysk-core and 'make TestRunner' You will probably also have to undo the patch that Rick brought in to enable UNW_REMOTE_ONLY. The issue of the linker errors when building fryski is something that needs to be addressed at some point. I've not committed this patch because of the issues associated with using it. The bugs for these problems are: http://sourceware.org/bugzilla/show_bug.cgi?id=3068 http://sourceware.org/bugzilla/show_bug.cgi?id=3070 http://sourceware.org/bugzilla/show_bug.cgi?id=3071 Adam From mark@klomp.org Wed Aug 16 14:54:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 16 Aug 2006 14:54:00 -0000 Subject: First try of breakpoint support In-Reply-To: <20060814222929.w8o6joo64gggo4w4@imap.linux.ibm.com> References: <20060814222929.w8o6joo64gggo4w4@imap.linux.ibm.com> Message-ID: <1155740056.3183.34.camel@dijkstra.wildebeest.org> Hi, On Mon, 2006-08-14 at 22:29 -0400, Wu Zhou wrote: > Quoting Mark Wielaard : > > > Yes, I also had some intermittent failures. That first try depended on > > the timing of the ptrace calls to be right. I have fixed that by > > integrating the code with the proc and task state machines. That makes > > sure that the various ptrace calls are made at the right time. This also > > makes the code much faster. > > Great! Nice to know that it is fixed. And it is in CVS now if you like to check. > Yes, non-executable stack is a problem. Is there any way for the > debugger to change the access attribute of the debuggee pages? AFAIK, > ptrace can't do that. I am now thinking if utrace can do that. It > seems to me not that hard. Utrace can register a hook function to do > that in my opinion. > > If this kind of mechanism is available, it might also help in > watchpoint implementation. To set a write watchpoint on some address, > we can set that page to be read-only, a page fault will trigger when a > write attempt is tried on it, then debugger can fetch that and report > a write hit; vice versa for read watchpoint. Any ideas? Interesting ideas. I had assumed there was already a way to do that. But it seems even gdb uses hardware registers. I don't know if that is because nobody ever implemented watchpoints by page-faulting, or that page-faulting is just too inefficient (you could get a lot of false traps if the page is large). > Maybe we can > list first all the possible problem we might encounter. And then > current available solution, their pros and cons...what support low > level provide? what we need to ask low-level for? ... based on these, > we might come up a better solution. Though there are really quite a > lot of works to be done. It might be most efficient to try to write the support first on the frysk side. Using simple CodeObservers that are unconditional. And just check the conditionals ourselves each time. When we have a feeling for what kind of conditionals are most commonly used then we can benchmark and see what can be pushed/injected into the process code pages that we are debugging. > Thanks in advance for that. We will be very happy to go thru your code > and to see if we can provide any feedback. And it is really awful for > me to hear that you change the state machines three times (I am > wishing that you don't change that too much so that I don't need to > spend the same time I need to understand it the first time. :-). I actually changed very little in the end. The patch that I committed doesn't add any new states. I am now working on merging the breakpoint tracing with the syscall tracing and that will also involve merging states. So we will end up with less states. But some of the states will have more complex state transition rules. > >> - Hardware watchpoint hit will also delieve SIGTRAP, then watchpoint > >> might also share some work flow with breakpoint. Do you have some > >> consideration in this aspect? > > > > There doesn't seem to be a way to set those through something like > > ptrace. > > On ppc64, there is an extra ptrace command which can do this. I am > not very sure about the situation in i386 though. O that is nice. It does indeed seem that you can access the hardware debug registers through ptrace. But there doesn't seem to be any documentation (except reading sys/user.h) and it is obviously all architecture dependent. > > I don't have testcases yet. Those should indeed be written asap. > > Yes. A testcase can help understand this situation more easily. I am > wishing someone can do that. :-) Writing them as we speak. Cheers, Mark From cagney@redhat.com Wed Aug 16 19:14:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 16 Aug 2006 19:14:00 -0000 Subject: getLogger parameter Message-ID: <44E36E7D.60000@redhat.com> FYI, I've changed all the calls to getLogger() so that they specify the current package (e.g., frysk.event, frysk.proc, frysk.gui.monitor), and not frysk .Config .FRYSK_LOG_ID. My understanding of the logging code is that's the general intent as it makes possible fine-grained logging such as just frysk.event, et.al. A follow-on is obviously to let us manipulate logging at that finer level. Andrew From qiyaoltc@cn.ibm.com Thu Aug 17 02:42:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 17 Aug 2006 02:42:00 -0000 Subject: Stub bfd_getb32 and bfd_getl32 for libopcodes on ppc64 In-Reply-To: <44E1DC52.2050704@redhat.com> References: <20060814103013.GB2324@GreenHouse.cn.ibm.com> <44E1DC52.2050704@redhat.com> Message-ID: <20060817023354.GA32647@GreenHouse.cn.ibm.com> On Tue, Aug 15, 2006 at 10:38:10AM -0400, Andrew Cagney wrote: > Yao, nice > > Just a simplification: I'd be unconditionally compiling this code > (don't make it conditional on ppc/ppc64), that way we always know that > the code compiles. The other is that the endian .c file needs (C) IBM > along with frysk's standard licence. I added (C) IBM with frysk's licence in libbfd_get.c. Thanks for your advice. > > With that tweaked (assuming your account is working, and assuming i386 > continues to pass), check it in. I did have the cvs write access. :) Tested frysk on X86 and PPC64. Checked it in. -- Yao Qi From woodzltc@cn.ibm.com Thu Aug 17 03:43:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 17 Aug 2006 03:43:00 -0000 Subject: First try of breakpoint support In-Reply-To: <1155740056.3183.34.camel@dijkstra.wildebeest.org> References: <20060814222929.w8o6joo64gggo4w4@imap.linux.ibm.com> <1155740056.3183.34.camel@dijkstra.wildebeest.org> Message-ID: <44E3E5E6.6090001@cn.ibm.com> Mark Wielaard wrote: >> Great! Nice to know that it is fixed. >> > > And it is in CVS now if you like to check. > Mark, thanks for that. We will have a check on that a while later. One quick point though, I see that you hardcoded TRAP in breakpoint.java to 0xcc, and assumed that the length of TRAP and original instruction to be 1. I know that your current focus is to make it work on x86 and x86_64. But the assumption is not true for other architectures. And because the opcode of TRAP is ISA dependent. Our point is that it is better to declare it as a memeber of ISA class, and its subclass (IsaIA32, IsaEM64T, IsaPPC64...) can inherit and overwrite it in the time of initialization. In the time of creating a breakpoint, Breakpoint.java can get the ISA depedent TRAP instruction and its length at the same time. > Interesting ideas. I had assumed there was already a way to do that. But > it seems even gdb uses hardware registers. I don't know if that is > because nobody ever implemented watchpoints by page-faulting, or that > page-faulting is just too inefficient (you could get a lot of false > traps if the page is large). > Really? in what way can we do that? I am very happy to be educated. In the aspect of efficiency, page-faulting is obviously weaker than hardware watchpoint, but much more efficient than single step simulated ones. To consider what if there is no hardware support or available hardware resource are used up. > It might be most efficient to try to write the support first on the > frysk side. Using simple CodeObservers that are unconditional. And just > check the conditionals ourselves each time. When we have a feeling for > what kind of conditionals are most commonly used then we can benchmark > and see what can be pushed/injected into the process code pages that we > are debugging. > Yes. That is more efficient. Regards - Wu Zhou From woodzltc@cn.ibm.com Thu Aug 17 04:55:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 17 Aug 2006 04:55:00 -0000 Subject: Test result of utrace on PPC64(based on Fedoracore 6 Test 2 release). In-Reply-To: <1155694227.2913.95.camel@YZ_X86_64> References: <1155694227.2913.95.camel@YZ_X86_64> Message-ID: <44E3F6C0.7040207@cn.ibm.com> Appended is the difference of gdb.sum for 32-bits testcases (the situation is similar with 64-bit testcases). We made some initial analysis: --- 32on64on64-2.6.17-1.2145_FC5-2006-08-14/gdb.sum 2006-08-14 22:40:00.000000000 -0400 +++ 32on64on64-2.6.17-1.2517.fc6-2006-08-14/gdb.sum 2006-08-14 04:18:07.000000000 -0400 ..... PASS: gdb.base/auxv.exp: info auxv on gcore-created dump -PASS: gdb.base/auxv.exp: matching auxv data from live and gcore +FAIL: gdb.base/auxv.exp: matching auxv data from live and gcore Our Comments: This regression is related to this output: 15 AT_PLATFORM String identifying platform 0xfa61fa89
which should be: 15 AT_PLATFORM String identifying platform 0xff9e54a5 "power5+" I guess kernel 2.6.17-1.2517.fc6 has problem in generating the correct AT_PLATFORM for power5+, or that gdb has difficulty in reading out the platform identifying string from the gcore-created dump. -ERROR: internal buffer is full. -UNRESOLVED: gdb.base/checkpoint.exp: info checkpoints with at least 600 checkpoints +PASS: gdb.base/checkpoint.exp: info checkpoints with at least 600 checkpoints Our Comments: fc6 (or utrace) supports large numbers of checkpoints better? -FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES +PASS: gdb.base/fileio.exp: Open for write but no write permission returns EACCES -FAIL: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES +PASS: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES Our Comments: don't know why it fails on 2.6.17-1.2145_FC5? -PASS: gdb.base/gcore.exp: corefile restored un-initialized array -PASS: gdb.base/gcore.exp: corefile restored heap array +FAIL: gdb.base/gcore.exp: corefile restored un-initialized array +FAIL: gdb.base/gcore.exp: corefile restored heap array -PASS: gdb.base/info-proc.exp: info proc mapping +FAIL: gdb.base/info-proc.exp: info proc mapping Our Comments: no comments at this time. :-) -PASS: gdb.base/recurse.exp: continue to recurse (a = 9) -PASS: gdb.base/recurse.exp: continue to recurse (a = 8) -PASS: gdb.base/recurse.exp: continue to recurse (a = 7) -PASS: gdb.base/recurse.exp: continue to recurse (a = 6) -PASS: gdb.base/recurse.exp: continue to recurse (a = 5) -PASS: gdb.base/recurse.exp: next over b = 0 in second instance +FAIL: gdb.base/recurse.exp: continue to recurse (a = 9) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 8) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 7) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 6) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 5) +FAIL: gdb.base/recurse.exp: next over b = 0 in second instance -PASS: gdb.base/recurse.exp: continue to second instance watchpoint, first time +FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, first time Our Comments: 2.6.17-1.2145_FC5 reports gdb is using hardware watchpoint. 2.6.17-1.2517.fc6 doesn't. Maybe utrace don't implement commands GET_DEBUGREG and SET_DEBUGREG of ptrace for ppc64? -FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler entry; performing step +PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; performing step -FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler entry; performing next +PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; performing next -FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; performing continue +PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; performing continue Our comments: 2.6.17-1.2517.fc6 (utrace kernel) behaves better than 2.6.17-1.2145_FC5 (ptrace kernel). -PASS: gdb.mi/mi-watch.exp: wp out of scope +FAIL: gdb.mi/mi-watch.exp: wp out of scope (2) -PASS: gdb.mi/mi2-watch.exp: wp out of scope +FAIL: gdb.mi/mi2-watch.exp: wp out of scope (2) Our comments: still watchpoint relevant. no further analysis yet. -PASS: gdb.threads/gcore-thread.exp: corefile contains at least two threads +FAIL: gdb.threads/gcore-thread.exp: corefile contains at least two threads -PASS: gdb.threads/linux-dp.exp: philosopher is distinct: 2 +FAIL: gdb.threads/linux-dp.exp: philosopher is distinct: 2 -PASS: gdb.threads/manythreads.exp: stop threads 1 -PASS: gdb.threads/manythreads.exp: info threads -PASS: gdb.threads/manythreads.exp: second continue -PASS: gdb.threads/manythreads.exp: stop threads 2 +FAIL: gdb.threads/manythreads.exp: stop threads 1 +FAIL: gdb.threads/manythreads.exp: info threads +FAIL: gdb.threads/manythreads.exp: second continue +FAIL: gdb.threads/manythreads.exp: stop threads 2 -PASS: gdb.threads/schedlock.exp: thread 1 ran +FAIL: gdb.threads/schedlock.exp: thread 1 ran (didn't run) -PASS: gdb.threads/watchthreads.exp: watch args[0] +FAIL: gdb.threads/watchthreads.exp: watch args[0] -FAIL: gdb.threads/watchthreads.exp: threaded watch loop (timeout) -PASS: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit +FAIL: gdb.threads/watchthreads.exp: threaded watch loop +FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit Our comments: main differences are in this aspect (multi-thread debugging), don't do any analysis yet. @@ -335,7 +335,9 @@ PASS: gdb.base/bigcore.exp: grab pid Yong Zheng wrote: > Hi all, > > Fedora Core 6 Test 2 has been released on July 7, 2006. Based on it, we > do one thorough test on PPC64. The test consists of the following two > parts and we summarize what we have tested as follows, wishing it can be > helpful for you to get a picture of how utrace works on PPC64. > > 1. Gdb's test on the FC6 test 2 release > > In this part, we build gdb and run gdb testsuite on PPC64 with the > kernel 2.6.17-1.2517(shipped with FC6 Test 2). As for comparison, we > also run gdb testsuite on kernel 2.6.17-1.2145(without utrace patched in > but with the original ptrace). > > On each kernel, we run gdb testsuite twice: the first by compiling them > into 32bits ELF files and the second by compiling them into 64bits ELF > files. The test results are shown in the following tables: > > Testcase 32on64on64(2.6.17-1.2145) 32on64on64(2.6.17-1.2517) > expected passes 10673 10660 > unexpected failures 339(3.18%) 356(3.34%) > expected failures 40 40 > known failures 59 59 > unresolved testcases 15 14 > untested testcases 5 4 > unsupported tests 11 11 > > Testcase 64on64on64(2.6.17-1.2145) 64on64on64(2.6.17-1.2517) > expected passes 10684 10665 > unexpected failures 392(3.67%) 409(3.835%) > expected failures 44 44 > known failures 60 60 > unresolved testcases 4 4 > untested testcases 1 1 > unsupported tests 12 14 > > Seen from the numbers in the above tables, the test results are very > encouraging. There're just only more 17 unexpected failures on the > kernel patched in utrace than on the kernel with the original ptrace! > > If anyone think the detailed test results might be helpful, we're > willing to send the test results(including all test logs) to you. > > 2. utrace's testsuite on the FC6 test 2 release > > As to utrace's testsuite, there are two test ways: one is to do the test > through building case into executable program; another is through > compiling case into kernel module. > > If we choose the former test way, all testcases in ntrace package(you > can get it from roland's website: > http://people.redhat.com/roland/utrace/) work well, the kernel runs well > during and after the test. All seems to be good. > > However, if you build testcase(for example, crash-suspend.c, also got > from the roland's website) into kernel module, insert the module and > then do the test, the kernel may crash once in a while. > > Best regards > Yong Zheng > From qiyaoltc@cn.ibm.com Thu Aug 17 05:03:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 17 Aug 2006 05:03:00 -0000 Subject: libunwind progress In-Reply-To: <44E32F4B.7070809@redhat.com> References: <44E32F4B.7070809@redhat.com> Message-ID: <20060817045452.GB32647@GreenHouse.cn.ibm.com> On Wed, Aug 16, 2006 at 10:44:27AM -0400, Adam Jocksch wrote: > I've attached the patch to enable using dwarf_find_proc_info to be > applied in frysk-imports. This is how I'd recommend using it: Hi, Adam, Where is the patch? I could not find it in this mail. :) dwarf_find_proc_info in libunwind could extract information about cie/fde, and fill in dwarf_cie_info_t in void* proc_info_t.unwind_info. In parse_fde(src/dwarf/Gparser.c), proc_info_t.unwind_info is casted to dwarf_cie_info_t to get the start/end address of cie and fde. > > 1) Build frysk normally > 2) Apply the patch to frysk-imports. > 3) Comment out the lines in frysk-imports' generated makefile that build > fryski and build frysk-imports > 4) cd to frysk-core and 'make TestRunner' > > You will probably also have to undo the patch that Rick brought in to > enable UNW_REMOTE_ONLY. The issue of the linker errors when building Yes, the first thing I do to make frysk core backtrace is to remove UNW_REMOTE_ONLY. libunwind could not work in a remote-only mode, since information about dwarf/elf is all from local memory. > fryski is something that needs to be addressed at some point. I've not > committed this patch because of the issues associated with using it. The > bugs for these problems are: > > http://sourceware.org/bugzilla/show_bug.cgi?id=3068 > http://sourceware.org/bugzilla/show_bug.cgi?id=3070 > http://sourceware.org/bugzilla/show_bug.cgi?id=3071 > > Adam Actually, frysk could do backtrace partially on my desktop with some modifications to libunwind java bindings. (Here are some my thoughts to libunwind, free to correct me if I am wrong.) One of the most important changes is to implement the functionality of dwarf_find_proc_info in its java binding cni code (populate_procinfo() StackCallbacks.cxx). As I said above, dwarf_find_proc_info extract information about cie/fde, why don't we do the same thing in our java binding cni code? I add some code in populate_procinfo() to set start/end address of cie and fde. Here is a list about the changes I did, for your reference, 1) Set return value of -10(-UNW_ENOINFO) instead of 0 in getDynInfoListAddr(). 2) Set proc_info->unwind_info point to dwarf_cie_info_t* instead of memory image of .debug_frame, and create a new member, debug_frame_addr, to hold the memory image of .debug_frame. 3) Remove -DUNW_REMOTE_ONLY from CFLAGS in libunwind/configure.ac. 4) Hardwired as(address_space) to unw_local_addr_space in run_cfi_program. Index: frysk-imports/libunwind/src/dwarf/Gparser.c =================================================================== RCS file: /cvs/frysk/frysk-imports/libunwind/src/dwarf/Gparser.c,v retrieving revision 1.1 diff -u -r1.1 Gparser.c --- frysk-imports/libunwind/src/dwarf/Gparser.c 31 May 2006 18:22:16 -0000 1.1 +++ frysk-imports/libunwind/src/dwarf/Gparser.c 16 Aug 2006 12:24:06 -0000 @@ -71,7 +71,8 @@ void *arg; int ret; - as = c->as; + //as = c->as; + as = unw_local_addr_space; arg = c->as_arg; a = unw_get_accessors (as); curr_ip = c->pi.start_ip; The test cases about ptrace in libunwind failed if I do this change,:-( However, frysk could not do backtrace if I do not do so. 2) and 4) are relative to Bug#3071, if libunwind could get the right fde/cie address (done by 2), and access local address space instead of remote address space (via ptrace) to get dwarf information(done by 4), this bug might be fixed. In fact, I am still not very clear about the general picture of libunwind, and how frysk utilizes it, and sometimes suffered from DWARF/ELF specification. Any comments or advice is important for us to understand libunwind, contribute to libunwind community, and to find an reasonable solution to libunwind java bindings. Thanks! -- Yao Qi From qiyaoltc@cn.ibm.com Thu Aug 17 06:50:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 17 Aug 2006 06:50:00 -0000 Subject: [patch review] Check null pointer Message-ID: <20060817064143.GC32647@GreenHouse.cn.ibm.com> When chasing bug about libunwind, I find that some pointer should be checked. Here is a small patch to check null pointer. 2006-08-17 Yao Qi * StackCallbacks.java (getProcName): Check the null pointer. (getProcOffset): Ditto. Please review. I will check it in later if none here object this patch. -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/rt/StackCallbacks.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/rt/StackCallbacks.java,v retrieving revision 1.13 diff -u -r1.13 StackCallbacks.java --- frysk-core/frysk/rt/StackCallbacks.java 7 Aug 2006 20:22:15 -0000 1.13 +++ frysk-core/frysk/rt/StackCallbacks.java 17 Aug 2006 06:31:07 -0000 @@ -59,7 +59,7 @@ import frysk.proc.TaskException; public class StackCallbacks - implements UnwindCallbacks + implements UnwindCallbacks { private Task myTask; @@ -250,6 +250,8 @@ Dwfl dwfl = new Dwfl(myTask.getTid()); DwflDieBias bias = dwfl.getDie(addr); + if (bias == null) + return ""; DwarfDie die = bias.die; if (die == null) return ""; @@ -268,6 +270,8 @@ Dwfl dwfl = new Dwfl(myTask.getTid()); DwflDieBias bias = dwfl.getDie(addr); + if (bias == null) + return 0; DwarfDie die = bias.die; if (die == null) return 0; From mark@klomp.org Thu Aug 17 08:55:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 17 Aug 2006 08:55:00 -0000 Subject: First try of breakpoint support In-Reply-To: <44E3E5E6.6090001@cn.ibm.com> References: <20060814222929.w8o6joo64gggo4w4@imap.linux.ibm.com> <1155740056.3183.34.camel@dijkstra.wildebeest.org> <44E3E5E6.6090001@cn.ibm.com> Message-ID: <1155804882.3010.8.camel@dijkstra.wildebeest.org> Hi Wu Zhou, On Thu, 2006-08-17 at 11:43 +0800, Wu Zhou wrote: > And because the opcode of TRAP is ISA dependent. Our point is that it is > better to declare it as a memeber of ISA class, and its subclass > (IsaIA32, IsaEM64T, IsaPPC64...) can inherit and overwrite it in the > time of initialization. In the time of creating a breakpoint, > Breakpoint.java can get the ISA depedent TRAP instruction and its length > at the same time. That seems like a good thing. We should move it into the ISA. I forgot to mention one other architecture dependent thing. In TaskState when we get the breakpoint trap instruction on x86 and x86_64 we do the following: // FIXME This might not hold for all architectures. // Should probably be handled by the Isa. long address; try { address = task.getIsa().pc(task) - 1; } catch (TaskException tte) Because the trap is reported with the process counter already advanced. On other architectures this might not be the case and the address as reported is actually the breakpoint address itself. This should either be moved into the Isa, or we might want to consider to do the adjusting of the pc on a trap instruction inside sys/Wait. > > Interesting ideas. I had assumed there was already a way to do that. But > > it seems even gdb uses hardware registers. I don't know if that is > > because nobody ever implemented watchpoints by page-faulting, or that > > page-faulting is just too inefficient (you could get a lot of false > > traps if the page is large). > > > Really? in what way can we do that? I am very happy to be educated. > In the aspect of efficiency, page-faulting is obviously weaker than > hardware watchpoint, but much more efficient than single step simulated > ones. To consider what if there is no hardware support or available > hardware resource are used up. I also don't know too much about this. So I was just wondering why gdb doesn't use this technique. Elena tells me there is actually a fork of gdb (called wildebeest) that does use page-faulting. But I haven't found or studied that fork yet. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmoseley@redhat.com Thu Aug 17 13:13:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 17 Aug 2006 13:13:00 -0000 Subject: libunwind progress In-Reply-To: <20060817045452.GB32647@GreenHouse.cn.ibm.com> References: <44E32F4B.7070809@redhat.com> <20060817045452.GB32647@GreenHouse.cn.ibm.com> Message-ID: <44E46B69.9060000@redhat.com> Yao Qi wrote: > On Wed, Aug 16, 2006 at 10:44:27AM -0400, Adam Jocksch wrote: > >> I've attached the patch to enable using dwarf_find_proc_info to be >> applied in frysk-imports. This is how I'd recommend using it: >> > Hi, Adam, > Where is the patch? I could not find it in this mail. :) > Ooops, here it is. Please find it attached. Rick > dwarf_find_proc_info in libunwind could extract information about > cie/fde, and fill in dwarf_cie_info_t in void* > proc_info_t.unwind_info. In parse_fde(src/dwarf/Gparser.c), > proc_info_t.unwind_info is casted to dwarf_cie_info_t to get > the start/end address of cie and fde. > > >> 1) Build frysk normally >> 2) Apply the patch to frysk-imports. >> 3) Comment out the lines in frysk-imports' generated makefile that build >> fryski and build frysk-imports >> 4) cd to frysk-core and 'make TestRunner' >> >> You will probably also have to undo the patch that Rick brought in to >> enable UNW_REMOTE_ONLY. The issue of the linker errors when building >> > Yes, the first thing I do to make frysk core backtrace is to remove > UNW_REMOTE_ONLY. libunwind could not work in a remote-only mode, > since information about dwarf/elf is all from local memory. > > >> fryski is something that needs to be addressed at some point. I've not >> committed this patch because of the issues associated with using it. The >> bugs for these problems are: >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=3068 >> http://sourceware.org/bugzilla/show_bug.cgi?id=3070 >> http://sourceware.org/bugzilla/show_bug.cgi?id=3071 >> >> Adam >> > > Actually, frysk could do backtrace partially on my desktop with some > modifications to libunwind java bindings. (Here are some my thoughts to > libunwind, free to correct me if I am wrong.) > > One of the most important changes is to implement the functionality > of dwarf_find_proc_info in its java binding cni code > (populate_procinfo() StackCallbacks.cxx). As I said above, dwarf_find_proc_info > extract information about cie/fde, why don't we do the same thing in our > java binding cni code? I add some code in populate_procinfo() to set > start/end address of cie and fde. > > Here is a list about the changes I did, for your reference, > > 1) Set return value of -10(-UNW_ENOINFO) instead of 0 in getDynInfoListAddr(). > 2) Set proc_info->unwind_info point to dwarf_cie_info_t* instead of > memory image of .debug_frame, and create a new member, > debug_frame_addr, to hold the memory image of .debug_frame. > 3) Remove -DUNW_REMOTE_ONLY from CFLAGS in libunwind/configure.ac. > 4) Hardwired as(address_space) to unw_local_addr_space in > run_cfi_program. > Index: frysk-imports/libunwind/src/dwarf/Gparser.c > =================================================================== > RCS file: /cvs/frysk/frysk-imports/libunwind/src/dwarf/Gparser.c,v > retrieving revision 1.1 > diff -u -r1.1 Gparser.c > --- frysk-imports/libunwind/src/dwarf/Gparser.c 31 May 2006 18:22:16 -0000 1.1 > +++ frysk-imports/libunwind/src/dwarf/Gparser.c 16 Aug 2006 12:24:06 -0000 > @@ -71,7 +71,8 @@ > void *arg; > int ret; > > - as = c->as; > + //as = c->as; > + as = unw_local_addr_space; > arg = c->as_arg; > a = unw_get_accessors (as); > curr_ip = c->pi.start_ip; > > The test cases about ptrace in libunwind failed if I do this change,:-( > However, frysk could not do backtrace if I do not do so. 2) and 4) > are relative to Bug#3071, if libunwind could get the right fde/cie address > (done by 2), and access local address space instead of remote address > space (via ptrace) to get dwarf information(done by 4), this bug might > be fixed. > > In fact, I am still not very clear about the general picture of > libunwind, and how frysk utilizes it, and sometimes suffered from > DWARF/ELF specification. Any comments or advice is important for us to > understand libunwind, contribute to libunwind community, and to find > an reasonable solution to libunwind java bindings. Thanks! > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dwarf_find_info_patch.diff Type: text/x-patch Size: 2090 bytes Desc: not available URL: From mcvet@redhat.com Thu Aug 17 15:14:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Thu, 17 Aug 2006 15:14:00 -0000 Subject: [patch review] Check null pointer In-Reply-To: <20060817064143.GC32647@GreenHouse.cn.ibm.com> References: <20060817064143.GC32647@GreenHouse.cn.ibm.com> Message-ID: <1155827654.2006.47.camel@towel.toronto.redhat.com> On Thu, 2006-08-17 at 14:42 +0800, Yao Qi wrote: > When chasing bug about libunwind, I find that some pointer should be > checked. Here is a small patch to check null pointer. > > 2006-08-17 Yao Qi > > * StackCallbacks.java (getProcName): Check the null pointer. > (getProcOffset): Ditto. > > Please review. > I will check it in later if none here object this patch. > Yup, you're right - that check should be in there. Mike From woodzltc@gmail.com Thu Aug 17 15:47:00 2006 From: woodzltc@gmail.com (Wu Zhou) Date: Thu, 17 Aug 2006 15:47:00 -0000 Subject: Fwd: libunwind stubs for ppc64 In-Reply-To: <4e8ba5bf0608170835k15bd3c7ucd028348259e9ed8@mail.gmail.com> References: <4e8ba5bf0608170835k15bd3c7ucd028348259e9ed8@mail.gmail.com> Message-ID: <4e8ba5bf0608170847g482eb5bcs7710dd2b87cf7daf@mail.gmail.com> Andrew, Here is the patch to stub libunwind for ppc64, as we had discussed a few days. It has three parts, all of which are attached below. 1. patch to enable use_libunwind on ppc64 (in common/m4/frysk- use-libunwind.m4) 2. patch to bootstrap libunwind auto make and lib/unwind makefile.gen (in frysk-imports/bootstrap.sh) 3. the actual libunwind stubs for ppc64. (in frysk-imports/libunwind) I had tested it on ppc64, it can build ok without any extra patch. I also tested the patch on x86, no regression found. Any comments? Regards - Wu Zhou -------------- next part -------------- A non-text attachment was scrubbed... Name: m4.patch Type: text/x-patch Size: 646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bootstrap.patch Type: text/x-patch Size: 466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64-libunwind-stubs.patch Type: text/x-patch Size: 66880 bytes Desc: not available URL: From qiyaoltc@cn.ibm.com Fri Aug 18 03:13:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 18 Aug 2006 03:13:00 -0000 Subject: [patch review] Check null pointer In-Reply-To: <1155827654.2006.47.camel@towel.toronto.redhat.com> References: <20060817064143.GC32647@GreenHouse.cn.ibm.com> <1155827654.2006.47.camel@towel.toronto.redhat.com> Message-ID: <20060818030401.GB8871@GreenHouse.cn.ibm.com> On Thu, Aug 17, 2006 at 11:14:14AM -0400, Mike Cvet wrote: > On Thu, 2006-08-17 at 14:42 +0800, Yao Qi wrote: > > When chasing bug about libunwind, I find that some pointer should be > > checked. Here is a small patch to check null pointer. > > > > 2006-08-17 Yao Qi > > > > * StackCallbacks.java (getProcName): Check the null pointer. > > (getProcOffset): Ditto. > > > > Please review. > > I will check it in later if none here object this patch. > > > > Yup, you're right - that check should be in there. Committed! > > Mike > -- Yao Qi From oliva@lsd.ic.unicamp.br Fri Aug 18 06:55:00 2006 From: oliva@lsd.ic.unicamp.br (Alexandre Oliva) Date: Fri, 18 Aug 2006 06:55:00 -0000 Subject: Fix lossage with multi-word CC Message-ID: I have CC set to 'ccache gcc -m{64,32}' by default, and Frysk's common/ build machinery can't tolerate that. This simple change is required to all Makefile.rules containing these rules which, if I understand correctly, is the same CVS directory that gets magically checked out onto the right place for multiple sub-projects, right? It will break CC containing single quotes, but if you have that, you're probably already toast anyway. Ok to install? for common/ChangeLog from Alexandre Oliva * Makefile.rules (.shjava.java, .shenum.java): Support multi-word CC. Index: common/Makefile.rules =================================================================== RCS file: /cvs/frysk/frysk-common/Makefile.rules,v retrieving revision 1.130 diff -u -p -r1.130 Makefile.rules --- common/Makefile.rules 16 Aug 2006 10:31:07 -0000 1.130 +++ common/Makefile.rules 17 Aug 2006 08:42:01 -0000 @@ -181,7 +181,7 @@ SUFFIXES += .mkjava SUFFIXES += .shjava .shjava.java: rm -f $*.tmp - export CC=$(CC) ; \ + CC='$(CC)'; export CC ; \ $(SHELL) $< | $(SHELL) $(MKJAVA) > $*.tmp $@ chmod a-w $*.tmp mv -f $*.tmp $@ @@ -198,7 +198,7 @@ SUFFIXES += .mkenum SUFFIXES += .shenum .shenum.java: rm -f $*.tmp - export CC=$(CC) ; \ + CC='$(CC)'; export CC ; \ $(SHELL) $< | $(SHELL) $(MKENUM) > $*.tmp $@ chmod a-w $*.tmp mv -f $*.tmp $@ -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From zhengyo@cn.ibm.com Fri Aug 18 07:09:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Fri, 18 Aug 2006 07:09:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. Message-ID: <1155884638.7779.25.camel@YZ_X86_64> hi, There's no any case for us to test register and memory modification in PPC64 in frysk. So we write two cases for above purpose. During the test, we found the PPC64's worksize(got from IsaPPC64.java) should be 8bytes but not 4 bytes. Here is the patch to add PPC64 tests. 2006-08-18 Yong Zheng * frysk/proc/TestPPC64Regs.java: New file for PPC64 test * frysk/proc/TestPPC64Modify.java: New file for PPC64 test * frysk/pkglibexecdir/funit-ppc64-regs.S: New file for PPC64 * frysk/pkglibexecdir/funit-ppc64-modify.S: Ditto * frysk/Makefile.am: Add PPC64Regs/PPC64Modify tests * frysk/proc/IsaPPC64.java (getWordSize): Edit return value from 4 to 8 Rebuild frysk on X86-64/PPC64 based on the cvs head(08-18) and tested. Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64_testcase.patch Type: text/x-patch Size: 20178 bytes Desc: not available URL: From qiyaoltc@cn.ibm.com Fri Aug 18 07:44:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 18 Aug 2006 07:44:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <1155884638.7779.25.camel@YZ_X86_64> References: <1155884638.7779.25.camel@YZ_X86_64> Message-ID: <20060818073613.GC8871@GreenHouse.cn.ibm.com> On Fri, Aug 18, 2006 at 03:03:58PM +0800, Yong Zheng wrote: > hi, > > There's no any case for us to test register and memory modification in > PPC64 in frysk. So we write two cases for above purpose. During the > test, we found the PPC64's worksize(got from IsaPPC64.java) should be > 8bytes but not 4 bytes. Here is the patch to add PPC64 tests. It look fine to me. Here are some my comments to the format or style of changelog and source code. 1) The description in ChangLog is a sentence, even if it is short, so please end it with ".". > > 2006-08-18 Yong Zheng > > * frysk/proc/TestPPC64Regs.java: New file for PPC64 test > * frysk/proc/TestPPC64Modify.java: New file for PPC64 test > * frysk/pkglibexecdir/funit-ppc64-regs.S: New file for PPC64 > * frysk/pkglibexecdir/funit-ppc64-modify.S: Ditto > * frysk/Makefile.am: Add PPC64Regs/PPC64Modify tests > > * frysk/proc/IsaPPC64.java (getWordSize): Edit return value > from 4 to 8 > > Rebuild frysk on X86-64/PPC64 based on the cvs head(08-18) and tested. 2) In the licence part of the source code, "IBM Corp." may be better than "IBM Co.", so please replace "Co." with "Corp.". 3) There is no licence in these asm files. Please add them with (C) IBM Corp. :) > > Best regards > Yong Zheng > -- Yao Qi From mark@klomp.org Fri Aug 18 09:58:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 18 Aug 2006 09:58:00 -0000 Subject: Fix lossage with multi-word CC In-Reply-To: References: Message-ID: <1155895111.3010.58.camel@dijkstra.wildebeest.org> Hi Alexander, On Fri, 2006-08-18 at 03:55 -0300, Alexandre Oliva wrote: > This simple change is required to all Makefile.rules containing these > rules which, if I understand correctly, is the same CVS directory that > gets magically checked out onto the right place for multiple > sub-projects, right? Yes. We use a little CVSROOT/modules magic to make that happen. > It will break CC containing single quotes, but if you have that, > you're probably already toast anyway. > > Ok to install? It looks good to me. Do you have CVS access? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From oliva@lsd.ic.unicamp.br Fri Aug 18 10:15:00 2006 From: oliva@lsd.ic.unicamp.br (Alexandre Oliva) Date: Fri, 18 Aug 2006 10:15:00 -0000 Subject: Fix lossage with multi-word CC In-Reply-To: <1155895111.3010.58.camel@dijkstra.wildebeest.org> (Mark Wielaard's message of "Fri, 18 Aug 2006 11:58:30 +0200") References: <1155895111.3010.58.camel@dijkstra.wildebeest.org> Message-ID: On Aug 18, 2006, Mark Wielaard wrote: >> It will break CC containing single quotes, but if you have that, >> you're probably already toast anyway. >> Ok to install? > It looks good to me. Do you have CVS access? Andrew has already requested it, so I should have it any time now. I'll check it in as soon as I know that I do (just tried, not there yet :-). Thanks, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From zhengyo@cn.ibm.com Fri Aug 18 12:11:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Fri, 18 Aug 2006 12:11:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <1155884638.7779.25.camel@YZ_X86_64> References: <1155884638.7779.25.camel@YZ_X86_64> Message-ID: <1155902825.2829.3.camel@YZ_X86_64> hi, here is the latest patch. 2006-08-18 Yong Zheng * frysk/proc/TestPPC64Regs.java: New file for PPC64 test. * frysk/proc/TestPPC64Modify.java: Ditto. * frysk/pkglibexecdir/funit-ppc64-regs.S: Ditto. * frysk/pkglibexecdir/funit-ppc64-modify.S: Ditto. * frysk/Makefile.am: Add PPC64Regs/PPC64Modify tests. * frysk/proc/IsaPPC64.java (getWordSize): Edit return value from 4 to 8. Rebuild frysk on X86-64/PPC64 based on the cvs head(08-18) and tested. Please review it. Best regards Yong Zheng On Fri, 2006-08-18 at 15:03 +0800, Yong Zheng wrote: > hi, > > There's no any case for us to test register and memory modification in > PPC64 in frysk. So we write two cases for above purpose. During the > test, we found the PPC64's worksize(got from IsaPPC64.java) should be > 8bytes but not 4 bytes. Here is the patch to add PPC64 tests. > > 2006-08-18 Yong Zheng > > * frysk/proc/TestPPC64Regs.java: New file for PPC64 test > * frysk/proc/TestPPC64Modify.java: New file for PPC64 test > * frysk/pkglibexecdir/funit-ppc64-regs.S: New file for PPC64 > * frysk/pkglibexecdir/funit-ppc64-modify.S: Ditto > * frysk/Makefile.am: Add PPC64Regs/PPC64Modify tests > > * frysk/proc/IsaPPC64.java (getWordSize): Edit return value > from 4 to 8 > > Rebuild frysk on X86-64/PPC64 based on the cvs head(08-18) and tested. > > Best regards > Yong Zheng > -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64_testcase.patch Type: text/x-patch Size: 24390 bytes Desc: not available URL: From cagney@redhat.com Fri Aug 18 15:51:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 18 Aug 2006 15:51:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <1155884638.7779.25.camel@YZ_X86_64> References: <1155884638.7779.25.camel@YZ_X86_64> Message-ID: <44E5E21B.7080604@redhat.com> Yong Zheng wrote: > hi, > > There's no any case for us to test register and memory modification in > PPC64 in frysk. So we write two cases for above purpose. During the > test, we found the PPC64's worksize(got from IsaPPC64.java) should be > 8bytes but not 4 bytes. Here is the patch to add PPC64 tests. > > 2006-08-18 Yong Zheng > > * frysk/proc/TestPPC64Regs.java: New file for PPC64 test > * frysk/proc/TestPPC64Modify.java: New file for PPC64 test > * frysk/pkglibexecdir/funit-ppc64-regs.S: New file for PPC64 > * frysk/pkglibexecdir/funit-ppc64-modify.S: Ditto > * frysk/Makefile.am: Add PPC64Regs/PPC64Modify tests > > * frysk/proc/IsaPPC64.java (getWordSize): Edit return value > from 4 to 8 > > Rather than individual TestRegs.java files, I'd prefer to see a single TestRegs.java file that selects the applicable test and runs that, or fails if no test is implemented. Past experience tells us that, unless unimplemented is detected and treated as a FAIL, the tests won't get implemented - too easy to ignore. Andrew From kasal@ucw.cz Fri Aug 18 19:53:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Fri, 18 Aug 2006 19:53:00 -0000 Subject: -devel packages for java-gnome now needed Message-ID: <20060818195331.GC22816@camelia.ucw.cz> Hello, in short, if you upgrade your Fedora Core 5 or Devel, please run also yum install libglade-java-devel libvte-java-devel libgconf-java-devel An explanation: in a recent upgrade of the java-gnome packages in Fedora Core 5 and Fedora Core Devel, the pkgconfig specifications (*.pc files) were moved to the -devel packages (glib-java-devel, etc.). This means that the java-gnome packages are not recognized by frysk's configure script, unless their -devel counterparts are installed, too. The above command is enough, because dependencies bring in all other java-gnome -devel packages. The pkgconfig *.pc file is always put in the -devel part of the package. This enables to get dependencies right. For example, when glade-java.pc specified the requirement of libglade-2.0, then not only package libglade-java requires package libglade2, but also libglade-java-devel requires package libglade2-devel. I apologize for the problems caused by the fact that I have not posted this announcement earlier. Stepan Kasal From cagney@redhat.com Fri Aug 18 20:06:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 18 Aug 2006 20:06:00 -0000 Subject: try this on your kernel Message-ID: <44E61DE3.7090707@redhat.com> Phil, Can you give this a spin on your kernel? Andrew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs URL: From pmuldoon@redhat.com Fri Aug 18 20:48:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 18 Aug 2006 20:48:00 -0000 Subject: try this on your kernel In-Reply-To: <44E61DE3.7090707@redhat.com> References: <44E61DE3.7090707@redhat.com> Message-ID: <44E62780.9010205@redhat.com> Findings: Patch applied to clean sources ok Built ok. uname -a Linux localhost.localdomain 2.6.17-1.2571.fc6 #1 SMP Wed Aug 16 16:23:47 EDT 2006 i686 i686 i386 GNU/Linux ./TestRunner -r 100 frysk.proc.TestTaskForkedObserver Running testTaskForkedObserver(frysk.proc.TestTaskForkedObserver) ...PASS Time: 0.342 100 of those (obviously Time is different). Also did a ui test. Added a session that watches all active bash processes for forks. Typing ls in the bash shell 35 times produces 35 correct ui log entries, and 35 plots to the ui eventviewer. Andrew Cagney wrote: > Phil, > Can you give this a spin on your kernel? > Andrew > > ------------------------------------------------------------------------ > > Index: frysk-core/frysk/proc/LinuxHost.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxHost.java,v > retrieving revision 1.55 > diff -p -u -r1.55 LinuxHost.java > --- frysk-core/frysk/proc/LinuxHost.java 16 Aug 2006 10:58:50 -0000 1.55 > +++ frysk-core/frysk/proc/LinuxHost.java 18 Aug 2006 20:04:44 -0000 > @@ -40,6 +40,7 @@ > > package frysk.proc; > > +import frysk.event.Event; > import frysk.event.EventLoop; > import frysk.event.SignalEvent; > import frysk.sys.Ptrace; > @@ -241,6 +242,48 @@ public class LinuxHost > > Wait.Observer waitObserver = new Wait.Observer() > { > + /** > + * Maintain a list of fscked up kernel waitpid events - where > + * an event for a pid arrives before it has been created - so > + * that they can be re-processed when there's a fork. > + */ > + private List fsckedOrderedKernelEvents; > + /** > + * Run through the list of fscked up kernel waitpid events > + * attempting delivery of each in turn. > + */ > + private void attemptDeliveringFsckedKernelEvents () > + { > + if (fsckedOrderedKernelEvents != null) { > + Event[] pending = (Event[]) fsckedOrderedKernelEvents.toArray (new Event[0]); > + fsckedOrderedKernelEvents = null; > + for (int i = 0; i < pending.length; i++) { > + pending[i].execute (); > + } > + } > + } > + /** > + * Append the fscked-up stop event (it arrived when the task > + * didn't exist) to the fscked-up list. Will get re-processed > + * later. > + */ > + private void saveFsckedOrderedKernelStopedEvent (final int aPid, > + final int aSignal) > + { > + if (fsckedOrderedKernelEvents == null) > + fsckedOrderedKernelEvents = new LinkedList (); > + fsckedOrderedKernelEvents.add (new Event () > + { > + final int pid = aPid; > + final int signal = aSignal; > + public void execute () > + { > + waitObserver.stopped (pid, signal); > + } > + }); > + > + } > + > // Hold onto a scratch ID; avoids overhead of > // allocating a new taskId everytime a new event > // arrives -- micro optimization.. > @@ -300,6 +343,7 @@ public class LinuxHost > throw new RuntimeException("caught TaskException", e); > } > task.processForkedEvent(forkTask); > + attemptDeliveringFsckedKernelEvents (); > } > > public void exitEvent (int pid, boolean signal, int value, > @@ -330,6 +374,10 @@ public class LinuxHost > public void stopped (int pid, int sig) > { > Task task = getTask(pid, "{0} stopped\n"); > + if (task == null) { > + saveFsckedOrderedKernelStopedEvent (pid, sig); > + return; > + } > switch (sig) > { > case Sig.STOP_: > From zhengyo@cn.ibm.com Mon Aug 21 04:05:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Mon, 21 Aug 2006 04:05:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <44E5E21B.7080604@redhat.com> References: <1155884638.7779.25.camel@YZ_X86_64> <44E5E21B.7080604@redhat.com> Message-ID: <1156132796.18109.13.camel@YZ_X86_64> hi, According to Andrew's advice, we merge the following three testcases (TestI386Regs.java, TestX8664Regs.java and TestPPC64Regs.java) into one case: TestRegs.java. After merging the three cases, the files TestI386Regs.java, TestX8664Regs.java and TestPPC64Regs.java can be removed from frysk-core/frysk/proc/. If it's ok, we will post out the patch for merging TestI386Modify.java, TestX8664Modify.java and TestPPC64Modify.java. Here is the patch for adding TestRegs.java. Rebuild frysk on X86/X86-64/PPC64 based on the cvs head(08-18) and tested. please review. On Fri, 2006-08-18 at 11:51 -0400, Andrew Cagney wrote: > Yong Zheng wrote: > > hi, > > > > There's no any case for us to test register and memory modification in > > PPC64 in frysk. So we write two cases for above purpose. During the > > test, we found the PPC64's worksize(got from IsaPPC64.java) should be > > 8bytes but not 4 bytes. Here is the patch to add PPC64 tests. > > > > 2006-08-18 Yong Zheng > > > > * frysk/proc/TestPPC64Regs.java: New file for PPC64 test > > * frysk/proc/TestPPC64Modify.java: New file for PPC64 test > > * frysk/pkglibexecdir/funit-ppc64-regs.S: New file for PPC64 > > * frysk/pkglibexecdir/funit-ppc64-modify.S: Ditto > > * frysk/Makefile.am: Add PPC64Regs/PPC64Modify tests > > > > * frysk/proc/IsaPPC64.java (getWordSize): Edit return value > > from 4 to 8 > > > > > Rather than individual TestRegs.java files, I'd prefer to see a > single TestRegs.java file that selects the applicable test and runs > that, or fails if no test is implemented. > > Past experience tells us that, unless unimplemented is detected and > treated as a FAIL, the tests won't get implemented - too easy to ignore. > > Andrew > -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-testregs-0821.patch Type: text/x-patch Size: 14462 bytes Desc: not available URL: From mark@klomp.org Mon Aug 21 13:40:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 21 Aug 2006 13:40:00 -0000 Subject: Make TestBreakpoints deterministic Message-ID: <1156167597.3529.7.camel@dijkstra.wildebeest.org> Hi, The following patch makes TestBreakpoint deterministically PASS on both my FC5 (x86_64) and FC6test (x86) boxes: 2006-08-21 Mark Wielaard * TestBreakpoints.java: Implements Observer. (procTerminated): New boolean field. (setup): Add observableProcRemoved to manager.host. (tearDown): Make sure proc is really gone. (update): New method. It seems that under fc6 kernels procs are kept around longer than under fc5. So we were seeing "about to terminate" procs under fc6 when restarting the eventloop, which we weren't seeing under fc5 because they were always already gone. You do sometimes observe this with fc5 kernels, you will get a WARNING: No task for pid XXX from LinuxHost, but in those cases it seems the terminated event has already happened, or is never delivered to us. Under fc6 we then will get a terminated event, which upset this test. I am still seeing lots of FAILs on my FC6 machine, so it might be that something similar is generally needed and should go into TestLib. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: fc6proc.patch Type: text/x-patch Size: 2176 bytes Desc: not available URL: From cagney@redhat.com Mon Aug 21 17:05:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 21 Aug 2006 17:05:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <1156167597.3529.7.camel@dijkstra.wildebeest.org> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> Message-ID: <44E9E7F1.4040401@redhat.com> Mark, Does this actually stop the problem? For instance, if I were to be running two instances of the frysk simultaneously (or any other operation that would leave around defunct processes), wouldn't that lead to similar consequences? And under exactly what circumstance are you seeing terminated events? Having a wait call in tearDown, or waiting on observableProcRemovedXXX, does not give me warm fuzzies :-( The latter implies that the event loop is running - it may have crashed. Andrew Mark Wielaard wrote: > Hi, > > The following patch makes TestBreakpoint deterministically PASS on both > my FC5 (x86_64) and FC6test (x86) boxes: > > 2006-08-21 Mark Wielaard > > * TestBreakpoints.java: Implements Observer. > (procTerminated): New boolean field. > (setup): Add observableProcRemoved to manager.host. > (tearDown): Make sure proc is really gone. > (update): New method. > > It seems that under fc6 kernels procs are kept around longer than under > fc5. So we were seeing "about to terminate" procs under fc6 when > restarting the eventloop, which we weren't seeing under fc5 because they > were always already gone. You do sometimes observe this with fc5 > kernels, you will get a WARNING: No task for pid XXX from LinuxHost, but > in those cases it seems the terminated event has already happened, or is > never delivered to us. Under fc6 we then will get a terminated event, > which upset this test. > From mark@klomp.org Mon Aug 21 17:31:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 21 Aug 2006 17:31:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <44E9E7F1.4040401@redhat.com> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> Message-ID: <1156181460.3529.43.camel@dijkstra.wildebeest.org> Hi Andrew, On Mon, 2006-08-21 at 13:05 -0400, Andrew Cagney wrote: > Does this actually stop the problem? For instance, if I were to be > running two instances of the frysk simultaneously (or any other > operation that would leave around defunct processes), wouldn't that lead > to similar consequences? I don't think so because in those cases the kernel doesn't think we are still attached and interesting in terminated events in that case. > And under exactly what circumstance are you seeing terminated events? > Having a wait call in tearDown, or waiting on observableProcRemovedXXX, > does not give me warm fuzzies :-( The latter implies that the event > loop is running - it may have crashed. It is when the eventloop is restarted "too soon". Another fix (well workaround) is to add a small Thread.sleep() to the teardown after TestLib has killed the spawned processes, but that is not as reliable. If we startup the eventloop again "too soon" what happens is that we see the proc/task again when we do a Manager.host.requestRefreshXXX(). This adds the proc as detached to the core. But the kernel still has a terminate event pending for us from when we were actually attached to it (which seems to be the reason the proc is still around). So we must really make sure that we have received all events from the kernel, including the terminated event, even after we have detached already. Cheers, Mark From cagney@redhat.com Mon Aug 21 17:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 21 Aug 2006 17:38:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <1156181460.3529.43.camel@dijkstra.wildebeest.org> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> Message-ID: <44E9EFC1.1000004@redhat.com> > If we startup the eventloop again "too soon" what happens is that we see > the proc/task again when we do a Manager.host.requestRefreshXXX(). This > adds the proc as detached to the core. But the kernel still has a > terminate event pending for us from when we were actually attached to it > (which seems to be the reason the proc is still around). So we must > really make sure that we have received all events from the kernel, > including the terminated event, even after we have detached already. > That's the bug then - the original tearDown didn't detach frysk from those processes, presumably because it didn't know that it needed to? The TestLib.tearDown code iterates over a list of registered processes brute force detaching and killing each in turn. Provided the relevant processes are registered then all should be good. The eventLoop should certainly not be running at the time tearDown is reached - a bug in the test case; and needing to add sleep just tells us that the test is non-deterministic :-( Andrew From mark@klomp.org Mon Aug 21 18:13:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 21 Aug 2006 18:13:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <44E9EFC1.1000004@redhat.com> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> Message-ID: <1156183966.3529.50.camel@dijkstra.wildebeest.org> Hi Andrew, On Mon, 2006-08-21 at 13:39 -0400, Andrew Cagney wrote: > > If we startup the eventloop again "too soon" what happens is that we see > > the proc/task again when we do a Manager.host.requestRefreshXXX(). This > > adds the proc as detached to the core. But the kernel still has a > > terminate event pending for us from when we were actually attached to it > > (which seems to be the reason the proc is still around). So we must > > really make sure that we have received all events from the kernel, > > including the terminated event, even after we have detached already. > > > That's the bug then - the original tearDown didn't detach frysk from > those processes, presumably because it didn't know that it needed to? No teardown does kill and then detach from the process. It is just that that doesn't prevent the kernel from sending us a terminated event for that process later anyway. This never happened with the fc5 kernels, but seems to happen with the recent fc6 kernels. > The TestLib.tearDown code iterates over a list of registered processes > brute force detaching and killing each in turn. Provided the relevant > processes are registered then all should be good. The eventLoop should > certainly not be running at the time tearDown is reached - a bug in the > test case; and needing to add sleep just tells us that the test is > non-deterministic :-( The eventloop isn't running during teardown. It is just that the kernel for whatever reason decides we might still be interested in the terminated event later even though we are already detached. So before we restart the eventloop we need to make sure we have really seen this process disappear because otherwise we risk the kernel letting us know about that event at some later point in time. So we cannot rely on just the kills and detaches of the teardown for procs we have been attached to. Cheers, Mark From cagney@redhat.com Mon Aug 21 18:30:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 21 Aug 2006 18:30:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <1156183966.3529.50.camel@dijkstra.wildebeest.org> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> Message-ID: <44E9FBCC.3090602@redhat.com> Is it a non-detached terminate event you're seeing? If a process is a child, rather than a daemon, then there's the potential for two events: - the exited status, from the attached process - the exited status, because it is a child (the traditional waitpid child stuff) could it be that you're seeing? Andrew > The eventloop isn't running during teardown. It is just that the kernel > for whatever reason decides we might still be interested in the > terminated event later even though we are already detached. So before we > restart the eventloop we need to make sure we have really seen this > process disappear because otherwise we risk the kernel letting us know > about that event at some later point in time. So we cannot rely on just > the kills and detaches of the teardown for procs we have been attached > to. > > Cheers, > > Mark > > From zhengyo@cn.ibm.com Tue Aug 22 04:26:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Tue, 22 Aug 2006 04:26:00 -0000 Subject: One frysk-core patch to add breakpoint support in PPC64. Message-ID: <1156220482.30530.29.camel@YZ_X86_64> hi, Based on the codes submitted by Mark, we do one patch to add the breakpoint support in PPC64. At the meanwhile, we find some attributes in Breakpoint.java are dependent on ISA, so we do some modifications on Breakpoint.java and TaskState.java. 2006-08-22 Yong Zheng * frysk/proc/Isa.java (getBpInstruction): New method to get the instruction to replace the original instruction for breakpoint. (getBreakpointAddress): New method to get the breakpoint's address after hitting the breakpoint. * frysk/proc/IsaIA32.java (getBpInstruction): New method to implement the Isa interface. (getBreakpointAddress): New method to implement the Isa interface. (BREAKPOINT_INSTRUCTION): New attribute to store the breakpoint instruction on IA32. * frysk/proc/IsaEMT64.java (getBpInstruction): New method to implement the Isa interface. (getBreakpointAddress): New method to implement the Isa interface. (BREAKPOINT_INSTRUCTION): New attribute to store the breakpoint instruction on EMT64. * frysk/proc/IsaPPC.java (getBpInstruction): New method to implement the Isa interface. (getBreakpointAddress): New method to implement the Isa interface. * frysk/proc/IsaPPC64.java (getBpInstruction): New method to implement the Isa interface. (getBreakpointAddress): New method to implement the Isa interface. (BREAKPOINT_INSTRUCTION): New attribute to store the breakpoint instruction on PPC64. * frysk/proc/Breakpoint.java (TRAP): Move it to BREAKPOINT_INSTRUCTION in specific ISA. (origInstruction): Renamed from orig. (set): Replace the original instruction with breakpoint instruction got from ISA. (reset): Restore the original instruction. (prepareStep): Add support for PPC64. * frysk/proc/TaskState.java (Running.handleTrappedEvent): Get breakpoint address according to task's ISA. *frysk/pkglibexecdir/funit-breakpoint.c (main): Get the function address instead of address of function descriptor on PPC64. Rebuild frysk on X86/X86-64/PPC64 based on the cvs head(08-22) and tested. Please review and commit! Thanks! Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64-breakpoint-0822.patch Type: text/x-patch Size: 13555 bytes Desc: not available URL: From cagney@redhat.com Tue Aug 22 04:44:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 22 Aug 2006 04:44:00 -0000 Subject: libunwind stubs for ppc64 In-Reply-To: <4e8ba5bf0608170835k15bd3c7ucd028348259e9ed8@mail.gmail.com> References: <4e8ba5bf0608170835k15bd3c7ucd028348259e9ed8@mail.gmail.com> Message-ID: <44EA8BCD.1080303@redhat.com> Wu, for the moment, I'd say this is fine and sufficient. We just need upstream libunwind to grow the proper 64-bit PPC code ready for a new import. Andrew Wu Zhou wrote: > Andrew, > > Here is the patch to stub libunwind for ppc64, as we had discussed a > few days. > > It has three parts, all of which are attached below. > > 1. patch to enable use_libunwind on ppc64 (in common/m4/frysk- > use-libunwind.m4) > 2. patch to bootstrap libunwind auto make and lib/unwind makefile.gen > (in frysk-imports/bootstrap.sh) > 3. the actual libunwind stubs for ppc64. (in frysk-imports/libunwind) > > I had tested it on ppc64, it can build ok without any extra patch. > I also tested the patch on x86, no regression found. > > Any comments? From mark@klomp.org Tue Aug 22 09:44:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 22 Aug 2006 09:44:00 -0000 Subject: Patch: add two accessors to Syscall In-Reply-To: References: Message-ID: <1156239837.3003.30.camel@dijkstra.wildebeest.org> Hi Tom, On Mon, 2006-08-14 at 19:28 -0600, Tom Tromey wrote: > I was reading a thread on the valgrind list about finding where a bad > close() was called > > http://article.gmane.org/gmane.comp.debugging.valgrind/5996 > > and I thought this would be a simple thing for frysk to do. Nice idea. It would be very good to have some simple example checks you can do with frysk-core. > First I wanted the appended patch to let my code inspect a Syscall. > Could someone check this in? (I didn't add all the accessors, just > the ones I needed.) Rick Moseley already checked it in I see. > I hacked up ftrace.java to do what I wanted (it was *very* easy this > way -- nice :-), but on my FC5 box I always get an I/O error when > trying to get the stack trace of a task (failure attached). Any > ideas? Yao Qi already explained some of the issues with libunwind we are seeing. Rick is now discussing this upstream: http://lists.gnu.org/archive/html/libunwind-devel/2006-08/msg00018.html Seems gcj will also need some libunwind support for jdwp. It will be nice to work together on this. > Also I noticed a few other oddities here and there. For instance, > SyscallEventInfo.returnCode returns a long -- but apparently does not > sign-extend the syscall's actual return value. This leads to the > unobvious test: > > (int) syscallEventInfo.returnCode(task) < 0 > > I wasn't sure whether you'd prefer email about little things like this > or whether I should just drop stuff directly in bugzilla... let me > know. Please do both. At the moment it isn't easy to follow now bugzilla reports, but if things are only mentioned on the mailinglist they tend to be forgotten. Cheers, Mark From mark@klomp.org Tue Aug 22 11:24:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 22 Aug 2006 11:24:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <44E9FBCC.3090602@redhat.com> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> Message-ID: <1156245857.3003.35.camel@dijkstra.wildebeest.org> Hi Andrew, On Mon, 2006-08-21 at 14:30 -0400, Andrew Cagney wrote: > Is it a non-detached terminate event you're seeing? If a process is a > child, rather than a daemon, then there's the potential for two events: > > - the exited status, from the attached process > > - the exited status, because it is a child (the traditional waitpid > child stuff) > > could it be that you're seeing? O, that makes sense. The only strange thing is that we didn't see that happening on fc5 kernels. But you are right, in this case it is indeed a real child process so we must wait for the traditional waitpid child stuff. I have updated the comments in the code to make that clear. Thanks, Mark From mark@klomp.org Tue Aug 22 12:40:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 22 Aug 2006 12:40:00 -0000 Subject: One frysk-core patch to add breakpoint support in PPC64. In-Reply-To: <1156220482.30530.29.camel@YZ_X86_64> References: <1156220482.30530.29.camel@YZ_X86_64> Message-ID: <1156250408.3003.76.camel@dijkstra.wildebeest.org> Hi Yong Zheng, On Tue, 2006-08-22 at 12:21 +0800, Yong Zheng wrote: > Based on the codes submitted by Mark, we do one patch to add the > breakpoint support in PPC64. At the meanwhile, we find some attributes > in Breakpoint.java are dependent on ISA, so we do some modifications on > Breakpoint.java and TaskState.java. Great to see you were able to adapt the code to ppc64 and improve the design at the same time. I have only a few small comments. > Index: frysk-core/frysk/proc/Isa.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/Isa.java,v > retrieving revision 1.10 > diff -u -r1.10 Isa.java > --- frysk-core/frysk/proc/Isa.java 8 Aug 2006 08:27:11 -0000 1.10 > +++ frysk-core/frysk/proc/Isa.java 22 Aug 2006 03:19:06 -0000 > @@ -57,7 +57,26 @@ > > int getWordSize(); > ByteOrder getByteOrder(); > - > + > + /** > + * Get the breakpoint instruction. > + * > + * @return bytes[] the instruction of the ISA. > + */ > + byte[] getBpInstruction(); It might be nice to actually name this getBreakpointInstruction(). It is a bit long, but much clearer. > + * The function will take different actions according to task's ISA. > + * > + */ > + long getBreakpointAddress(Task task); > + > // int addressSize; > // InstructionSet; > // FloatingPointFormat; > Index: frysk-core/frysk/proc/TaskState.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/TaskState.java,v > retrieving revision 1.102 > diff -u -r1.102 TaskState.java > --- frysk-core/frysk/proc/TaskState.java 15 Aug 2006 17:16:58 -0000 1.102 > +++ frysk-core/frysk/proc/TaskState.java 22 Aug 2006 03:19:56 -0000 > @@ -1031,7 +1031,7 @@ > long address; > try > { > - address = task.getIsa().pc(task) - 1; > + address = task.getIsa().getBreakpointAddress(task); > } There is a FIXME comment just above this section of code. You fixed it! :) So please also remove that comment. > /** > * Actually sets the breakpoint. > */ > - private void set(Task task) > + private void set(Task task) throws TaskException > { > - ByteBuffer buffer = task.memory; > + int len = 0; > + ByteBuffer buffer = null; > + byte[] bpInstruction = null; > + > + if (null == task) > + return; This method should never be called with a null task. If it is that is an bug somewhere. Just let the NullPointerException happen so the developer gets a fair warning and can figure out where and why the task argument was null. > + buffer = task.memory; > buffer.position(address); > - orig = buffer.getByte(); > + > + try > + { > + bpInstruction = task.getIsa().getBpInstruction(); > + } > + catch (TaskException e) > + { > + throw e; > + } Don't catch and rethrow TaskException here. The caller of set(Task) will have to deal with it (and you already do in install()). > private void reset(Task task) > { > - ByteBuffer buffer = task.memory; > + int len = 0; > + ByteBuffer buffer = null; > + > + if (null == task) > + return; Again, this should be an error, don't silently return please. > Index: frysk-core/frysk/proc/IsaIA32.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v > retrieving revision 1.2 > diff -u -r1.2 IsaIA32.java > --- frysk-core/frysk/proc/IsaIA32.java 8 Aug 2006 08:27:11 -0000 1.2 > +++ frysk-core/frysk/proc/IsaIA32.java 22 Aug 2006 03:21:42 -0000 > @@ -48,6 +48,8 @@ > static final int I387_OFFSET = 18*4; > static final int DBG_OFFSET = 63 * 4; > > + private static final byte[] BREAKPOINT_INSTRUCTION = { (byte)0xcc }; > + > static class IA32Register extends Register > { > IA32Register(String name, int wordOffset) > @@ -121,6 +123,46 @@ > { > return ByteOrder.LITTLE_ENDIAN; > } > + > + /** > + * Get the breakpoint instruction. > + * > + * @return bytes[] the instruction of the ISA or null if TRAP is not > + * initialized. > + */ > + public final byte[] getBpInstruction() > + { > + byte[] instruction = null; > + > + if (null == IsaIA32.BREAKPOINT_INSTRUCTION) > + return null; That is an unnecessary check. It cannot be null, since you declare it above. And if it were null we are in big trouble, so we want a NullPointerException not a silent return. > + /** > + * Get the true breakpoint address according to PC register after hitting > + * one breakpoint set in task. In X86, the length of breakpoint instruction > + * will be added to the PC register's value. So the true breakpoint address > + * is the PC register's value minus the length of breakpoint. > + */ > + public long getBreakpointAddress(Task task) > + { > + long pcValue = 0; > + > + if (null == task) > + return pcValue; Again, don't silently return when the task argument is null, that should be a real error. > --- frysk-core/frysk/proc/IsaEMT64.java 8 Aug 2006 08:27:11 -0000 1.2 > +++ frysk-core/frysk/proc/IsaEMT64.java 22 Aug 2006 03:22:15 -0000 and > --- frysk-core/frysk/proc/IsaPPC.java 4 Aug 2006 09:07:42 -0000 1.1 > +++ frysk-core/frysk/proc/IsaPPC.java 22 Aug 2006 03:24:39 -0000 Same comments as for the IsaIA32.java code. > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC.java,v > retrieving revision 1.1 > diff -u -r1.1 IsaPPC.java > @@ -91,4 +91,22 @@ > { > return ByteOrder.BIG_ENDIAN; > } > + > + /** > + * Not support now. > + * > + * @return bytes[] the instruction of the ISA. > + */ > + public byte[] getBpInstruction() > + { > + return null; > + } > > + /** > + * Not support now. > + */ > + public long getBreakpointAddress(Task task) > + { > + return 0; > + } It might be better to throw a RuntimeException here to make clear that any usage of breakpoints isn't supported for PPC yet. > - // XXX add ppc case > + // There's great difference to get the addresses of one function between > + // PPC64 and other platform(such as X86/X86_64). What we get through the > + // the form "&function_name" is the address of function descriptor but > + // not the true entry address of the function. > +#ifndef __powerpc64__ > printf("%p\n", &first_breakpoint_function); > printf("%p\n", &second_breakpoint_function); > +#else > + printf("%p\n", (void *)(*(long *)&first_breakpoint_function)); > + printf("%p\n", (void *) (*(long *)&second_breakpoint_function)); > +#endif Note that there is another usage of &function_name in frysk-sys/frysk/sys/cni/TestLib.cxx for testing PtraceByteBuffer. It needs a similar fix like this for ppc64. Cheers, Mark From cagney@redhat.com Tue Aug 22 14:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 22 Aug 2006 14:38:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <1156245857.3003.35.camel@dijkstra.wildebeest.org> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> <1156245857.3003.35.camel@dijkstra.wildebeest.org> Message-ID: <44EB16DA.8010407@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Mon, 2006-08-21 at 14:30 -0400, Andrew Cagney wrote: > >> Is it a non-detached terminate event you're seeing? If a process is a >> child, rather than a daemon, then there's the potential for two events: >> >> - the exited status, from the attached process >> >> - the exited status, because it is a child (the traditional waitpid >> child stuff) >> >> could it be that you're seeing? >> > > O, that makes sense. The only strange thing is that we didn't see that > happening on fc5 kernels. But you are right, in this case it is indeed a > real child process so we must wait for the traditional waitpid child > stuff. I have updated the comments in the code to make that clear. > I'm not sure adding comments is helping the tear-down code. The patch added: public void tearDown() { + // Make sure proc is gone. + synchronized (monitor) + { + while (!procTerminated) + { + try + { + monitor.wait(); + } + catch (InterruptedException ie) + { + // Ignored + } + } + } + // Make sure event loop is gone. eventloop.requestStop(); synchronized (monitor) @@ -125,6 +151,22 @@ super.tearDown(); } + // Called by the Host when procs are removed. + // Used to monitor whether or not our proc has truely left the building. + public void update(Observable o, Object obj) + { + Proc p = (Proc) obj; + if (p.equals(proc)) + { + synchronized (monitor) + { + procTerminated = true; + monitor.notifyAll(); + } + } + } + + and, unless I'm mistaken, that can only work if the event loop is still running in its own thread (you seem to think otherwise?) Studying TestLib.tearDown, I find the sequence: - send SIGKILL - send SIGCONT - send DETACH+KILL and then: - block-wait until no children (because all exited, or ECHLD) The interesting part is public void terminated (int pid, boolean signal, int value, boolean coreDumped) { children.remove(new Integer(pid)); } public void disappeared (int pid, Throwable w) { detach (pid); children.remove(new Integer(pid)); } notice how it is removing each child when it sees an exit event, yet here the child is going to generate two exit events. Andrew From mark@klomp.org Tue Aug 22 15:02:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 22 Aug 2006 15:02:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <44EB16DA.8010407@redhat.com> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> <1156245857.3003.35.camel@dijkstra.wildebeest.org> <44EB16DA.8010407@redhat.com> Message-ID: <1156258938.3003.94.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2006-08-22 at 10:38 -0400, Andrew Cagney wrote: > > O, that makes sense. The only strange thing is that we didn't see that > > happening on fc5 kernels. But you are right, in this case it is indeed a > > real child process so we must wait for the traditional waitpid child > > stuff. I have updated the comments in the code to make that clear. > > > I'm not sure adding comments is helping the tear-down code. The patch > added: > > public void tearDown() > { > + // Make sure proc is gone. > + synchronized (monitor) > + { > + while (!procTerminated) > + { > + try > + { > + monitor.wait(); > + } > + catch (InterruptedException ie) > + { > + // Ignored > + } > + } > + } > + > // Make sure event loop is gone. > eventloop.requestStop(); > synchronized (monitor) > @@ -125,6 +151,22 @@ > super.tearDown(); > } > > + // Called by the Host when procs are removed. > + // Used to monitor whether or not our proc has truely left the building. > + public void update(Observable o, Object obj) > + { > + Proc p = (Proc) obj; > + if (p.equals(proc)) > + { > + synchronized (monitor) > + { > + procTerminated = true; > + monitor.notifyAll(); > + } > + } > + } > + > > and, unless I'm mistaken, that can only work if the event loop is still > running in its own thread (you seem to think otherwise?) No, at that time the eventloop is running. Otherwise it wouldn't work as you said. > Studying TestLib.tearDown, I find the sequence: > > - send SIGKILL > - send SIGCONT > - send DETACH+KILL > > and then: > > - block-wait until no children (because all exited, or ECHLD) > > The interesting part is > > public void terminated (int pid, boolean signal, > int value, boolean > coreDumped) > { > children.remove(new Integer(pid)); > } > public void disappeared (int pid, Throwable w) > { > detach (pid); > children.remove(new Integer(pid)); > } > > notice how it is removing each child when it sees an exit event, yet > here the child is going to generate two exit events. Right, but that is what we expect isn't it? Since we expect this process to give us 2 terminated events, one through ptrace/wait and one because it is a child. Cheers, Mark From cagney@redhat.com Tue Aug 22 15:11:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 22 Aug 2006 15:11:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <1156258938.3003.94.camel@dijkstra.wildebeest.org> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> <1156245857.3003.35.camel@dijkstra.wildebeest.org> <44EB16DA.8010407@redhat.com> <1156258938.3003.94.camel@dijkstra.wildebeest.org> Message-ID: <44EB1EA5.6030509@redhat.com> Mark Wielaard wrote: > >> >> and, unless I'm mistaken, that can only work if the event loop is still >> running in its own thread (you seem to think otherwise?) >> > > No, at that time the eventloop is running. Otherwise it wouldn't work as > you said. > > Now I am confused, you previously wrote: > The eventloop isn't running during teardown. To re-iterate the relevant point from that part of the thread, tearDown must never rely on a running eventLoop - that may be part of what crashed. Therefore the above is wrong. >> public void terminated (int pid, boolean signal, >> int value, boolean >> coreDumped) >> { >> children.remove(new Integer(pid)); >> } >> public void disappeared (int pid, Throwable w) >> { >> detach (pid); >> children.remove(new Integer(pid)); >> } >> >> notice how it is removing each child when it sees an exit event, yet >> here the child is going to generate two exit events. >> > > Right, but that is what we expect isn't it? Since we expect this process > to give us 2 terminated events, one through ptrace/wait and one because > it is a child. > Actually, previously we expected nothing. Most (all but one?) tests were running as demons - so the second event did not occur. Your code changes those rules, should the code be adjusted (we certainly shouldn't be adding code reliant on the event loop)? Andrew From mark@klomp.org Tue Aug 22 15:26:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 22 Aug 2006 15:26:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <44EB1EA5.6030509@redhat.com> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> <1156245857.3003.35.camel@dijkstra.wildebeest.org> <44EB16DA.8010407@redhat.com> <1156258938.3003.94.camel@dijkstra.wildebeest.org> <44EB1EA5.6030509@redhat.com> Message-ID: <1156260356.3003.107.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2006-08-22 at 11:11 -0400, Andrew Cagney wrote: > Mark Wielaard wrote: > >> and, unless I'm mistaken, that can only work if the event loop is still > >> running in its own thread (you seem to think otherwise?) > > > > No, at that time the eventloop is running. Otherwise it wouldn't work as > > you said. > > > Now I am confused, you previously wrote: > > > The eventloop isn't running during teardown. We are talking about different tearDowns it seems. The testcase has its own teardown in which will make sure the eventloop is stopped (and before that it will now make sure the process is gone, that is what the patch added). And there is the TestLib.tearDown() which is called from the testcase teardown, after the eventloop is properly stopped, and which mobs up any other processes that might have been spawned. > Actually, previously we expected nothing. Most (all but one?) tests > were running as demons - so the second event did not occur. Your code > changes those rules, should the code be adjusted (we certainly shouldn't > be adding code reliant on the event loop)? I think we agree. The testcase now handles this case transparently itself before TestLib.tearDown() is called (of course with the eventloop gone). So TestLib doesn't have to change at all and can just rely on the previous 'rules'. Cheers, Mark From cagney@redhat.com Tue Aug 22 15:47:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 22 Aug 2006 15:47:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <1156260356.3003.107.camel@dijkstra.wildebeest.org> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> <1156245857.3003.35.camel@dijkstra.wildebeest.org> <44EB16DA.8010407@redhat.com> <1156258938.3003.94.camel@dijkstra.wildebeest.org> <44EB1EA5.6030509@redhat.com> <1156260356.3003.107.camel@dijkstra.wildebeest.org> Message-ID: <44EB2707.3050209@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Tue, 2006-08-22 at 11:11 -0400, Andrew Cagney wrote: > >> Mark Wielaard wrote: >> >>>> and, unless I'm mistaken, that can only work if the event loop is still >>>> running in its own thread (you seem to think otherwise?) >>>> >>> No, at that time the eventloop is running. Otherwise it wouldn't work as >>> you said. >>> >>> >> Now I am confused, you previously wrote: >> >> >>> The eventloop isn't running during teardown. >>> > > We are talking about different tearDowns it seems. > The testcase has its own teardown in which will make sure the eventloop > is stopped (and before that it will now make sure the process is gone, > that is what the patch added). > And there is the TestLib.tearDown() which is called from the testcase > teardown, after the eventloop is properly stopped, and which mobs up any > other processes that might have been spawned. > We're not. That code assumes that tearDown is a fair-weather method which it is not. tearDown must work regardless of the state of the rest of the test. In particular and especially when the test has crashed for some totally unexplained reason. Relying on a still running event loop violates that. It should be possible to make a simple change to testLib.tearDown that both makes it even more robust and allows you to remove the broken code in your local tearDown method. Andrew From cagney@redhat.com Tue Aug 22 15:50:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 22 Aug 2006 15:50:00 -0000 Subject: frysk-imports frysk/bindir/ftrace.java frysk/d ... In-Reply-To: <44DCD764.1090003@redhat.com> References: <20060720155840.24856.qmail@sourceware.org> <1155297656.2946.15.camel@dijkstra.wildebeest.org> <44DCD764.1090003@redhat.com> Message-ID: <44EB27E4.7050008@redhat.com> Tim Moore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Wielaard wrote: > >> Hi Tim, >> >> + catch (Task.TaskException e) >> + { >> + // XXX do real exception handling >> + } >> >> I am all for Checked Exceptions, but this is the worst way to handle >> them. This just swallows the exception completely without leaving any >> trace that anything went wrong. Now we are worse off then when we had >> unchecked exceptions. At least then the exception doesn't just >> disappear. Please do fix these locations by either explicitly printing >> the exception, or better wrapping them in RuntimeExceptions and >> rethrowing them. >> > I agree that this is terrible style. I believe that you are not very > likely to see a TaskException in the wild and are thus not going to be > bitten by this right now, but the time to fix this is now. > That isn't the only example, and as expected and as predicted, they are continuing to accumulate. The key point here is that no language since Java (to be very specific C#) has thought to include checked-exceptions, if you can convince those language designers that there was a mistake in their rationale, then I'm all ears. I'm going to change this exception to unchecked, and then go through and rip out all that accumulating fluf. Andrew From mark@klomp.org Tue Aug 22 16:19:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 22 Aug 2006 16:19:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <44EB2707.3050209@redhat.com> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> <1156245857.3003.35.camel@dijkstra.wildebeest.org> <44EB16DA.8010407@redhat.com> <1156258938.3003.94.camel@dijkstra.wildebeest.org> <44EB1EA5.6030509@redhat.com> <1156260356.3003.107.camel@dijkstra.wildebeest.org> <44EB2707.3050209@redhat.com> Message-ID: <1156263572.3003.127.camel@dijkstra.wildebeest.org> Hi Andrew, On Tue, 2006-08-22 at 11:47 -0400, Andrew Cagney wrote: > > We are talking about different tearDowns it seems. > > The testcase has its own teardown in which will make sure the eventloop > > is stopped (and before that it will now make sure the process is gone, > > that is what the patch added). > > And there is the TestLib.tearDown() which is called from the testcase > > teardown, after the eventloop is properly stopped, and which mobs up any > > other processes that might have been spawned. > > > We're not. > > That code assumes that tearDown is a fair-weather method which it is > not. tearDown must work regardless of the state of the rest of the > test. In particular and especially when the test has crashed for some > totally unexplained reason. Relying on a still running event loop > violates that. I don't see why. We setup the the process and the eventloop in setup, so we close it down in teardown. Sure if things go completely bonkers thing fail. But that is what you want from the testsuite to point out things that break. > It should be possible to make a simple change to testLib.tearDown that > both makes it even more robust and allows you to remove the broken code > in your local tearDown method. You mean that the testLib.tearDown() is broken because it doesn't handle this case yet, and you want to fix it so it does correctly handles it. That would be nice because then I don't need similar code in other new testcases. I'll look into it. Cheers, Mark From cagney@redhat.com Tue Aug 22 16:31:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 22 Aug 2006 16:31:00 -0000 Subject: Make TestBreakpoints deterministic In-Reply-To: <1156263572.3003.127.camel@dijkstra.wildebeest.org> References: <1156167597.3529.7.camel@dijkstra.wildebeest.org> <44E9E7F1.4040401@redhat.com> <1156181460.3529.43.camel@dijkstra.wildebeest.org> <44E9EFC1.1000004@redhat.com> <1156183966.3529.50.camel@dijkstra.wildebeest.org> <44E9FBCC.3090602@redhat.com> <1156245857.3003.35.camel@dijkstra.wildebeest.org> <44EB16DA.8010407@redhat.com> <1156258938.3003.94.camel@dijkstra.wildebeest.org> <44EB1EA5.6030509@redhat.com> <1156260356.3003.107.camel@dijkstra.wildebeest.org> <44EB2707.3050209@redhat.com> <1156263572.3003.127.camel@dijkstra.wildebeest.org> Message-ID: <44EB3154.3060707@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Tue, 2006-08-22 at 11:47 -0400, Andrew Cagney wrote: > >>> We are talking about different tearDowns it seems. >>> The testcase has its own teardown in which will make sure the eventloop >>> is stopped (and before that it will now make sure the process is gone, >>> that is what the patch added). >>> And there is the TestLib.tearDown() which is called from the testcase >>> teardown, after the eventloop is properly stopped, and which mobs up any >>> other processes that might have been spawned. >>> >>> >> We're not. >> >> That code assumes that tearDown is a fair-weather method which it is >> not. tearDown must work regardless of the state of the rest of the >> test. In particular and especially when the test has crashed for some >> totally unexplained reason. Relying on a still running event loop >> violates that. >> > > I don't see why. We setup the the process and the eventloop in setup, so > we close it down in teardown. Sure if things go completely bonkers thing > fail. But that is what you want from the testsuite to point out things > that break. > Ah, that's how JUnit describes things - JUnit thinks that failures are clean and predictable. With frysk, that is every thing but true, Murphy's Law to the Nth. The event loop will crash, the process will hang. The tearDown needs to be code such that it survives such foul conditions. I'll make the necessary changes. Andrew From tromey@redhat.com Tue Aug 22 23:02:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 22 Aug 2006 23:02:00 -0000 Subject: Patch: add two accessors to Syscall In-Reply-To: <1156239837.3003.30.camel@dijkstra.wildebeest.org> References: <1156239837.3003.30.camel@dijkstra.wildebeest.org> Message-ID: >> I was reading a thread on the valgrind list about finding where a bad >> close() was called >> http://article.gmane.org/gmane.comp.debugging.valgrind/5996 >> and I thought this would be a simple thing for frysk to do. Mark> Nice idea. It would be very good to have some simple example Mark> checks you can do with frysk-core. I've been thinking more generally that it would be nice if this were an ftrace option somehow -- one concrete way of making it nicer than strace :) >> I wasn't sure whether you'd prefer email about little things like this >> or whether I should just drop stuff directly in bugzilla... let me >> know. Mark> Please do both. At the moment it isn't easy to follow now bugzilla Mark> reports, but if things are only mentioned on the mailinglist they tend Mark> to be forgotten. I filed a few things in the sourceware bugzilla. I wasn't sure how far you'd want me to go. E.g., I looked a little at adding command line options to ftrace, to make it strace compatible. I filed a bug resulting from this, but didn't file one for the general idea ... Tom From zhengyo@cn.ibm.com Wed Aug 23 04:21:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 23 Aug 2006 04:21:00 -0000 Subject: One frysk-core patch to add breakpoint support in PPC64. In-Reply-To: <1156250408.3003.76.camel@dijkstra.wildebeest.org> References: <1156220482.30530.29.camel@YZ_X86_64> <1156250408.3003.76.camel@dijkstra.wildebeest.org> Message-ID: <1156306548.30530.37.camel@YZ_X86_64> Hi, On Tue, 2006-08-22 at 14:40 +0200, Mark Wielaard wrote: > Hi Yong Zheng, > > On Tue, 2006-08-22 at 12:21 +0800, Yong Zheng wrote: > > Based on the codes submitted by Mark, we do one patch to add the > > breakpoint support in PPC64. At the meanwhile, we find some attributes > > in Breakpoint.java are dependent on ISA, so we do some modifications on > > Breakpoint.java and TaskState.java. > > Great to see you were able to adapt the code to ppc64 and improve the > design at the same time. I have only a few small comments. > > > Index: frysk-core/frysk/proc/Isa.java > > =================================================================== > > RCS file: /cvs/frysk/frysk-core/frysk/proc/Isa.java,v > > retrieving revision 1.10 > > diff -u -r1.10 Isa.java > > --- frysk-core/frysk/proc/Isa.java 8 Aug 2006 08:27:11 -0000 1.10 > > +++ frysk-core/frysk/proc/Isa.java 22 Aug 2006 03:19:06 -0000 > > @@ -57,7 +57,26 @@ > > > > int getWordSize(); > > ByteOrder getByteOrder(); > > - > > + > > + /** > > + * Get the breakpoint instruction. > > + * > > + * @return bytes[] the instruction of the ISA. > > + */ > > + byte[] getBpInstruction(); > > It might be nice to actually name this getBreakpointInstruction(). It is > a bit long, but much clearer. > > > + * The function will take different actions according to task's ISA. > > + * > > + */ > > + long getBreakpointAddress(Task task); > > + > > // int addressSize; > > // InstructionSet; > > // FloatingPointFormat; > > Index: frysk-core/frysk/proc/TaskState.java > > =================================================================== > > RCS file: /cvs/frysk/frysk-core/frysk/proc/TaskState.java,v > > retrieving revision 1.102 > > diff -u -r1.102 TaskState.java > > --- frysk-core/frysk/proc/TaskState.java 15 Aug 2006 17:16:58 -0000 1.102 > > +++ frysk-core/frysk/proc/TaskState.java 22 Aug 2006 03:19:56 -0000 > > @@ -1031,7 +1031,7 @@ > > long address; > > try > > { > > - address = task.getIsa().pc(task) - 1; > > + address = task.getIsa().getBreakpointAddress(task); > > } > > There is a FIXME comment just above this section of code. You fixed > it! :) So please also remove that comment. > > > /** > > * Actually sets the breakpoint. > > */ > > - private void set(Task task) > > + private void set(Task task) throws TaskException > > { > > - ByteBuffer buffer = task.memory; > > + int len = 0; > > + ByteBuffer buffer = null; > > + byte[] bpInstruction = null; > > + > > + if (null == task) > > + return; > > This method should never be called with a null task. If it is that is an > bug somewhere. Just let the NullPointerException happen so the developer > gets a fair warning and can figure out where and why the task argument > was null. > > > + buffer = task.memory; > > buffer.position(address); > > - orig = buffer.getByte(); > > + > > + try > > + { > > + bpInstruction = task.getIsa().getBpInstruction(); > > + } > > + catch (TaskException e) > > + { > > + throw e; > > + } > > Don't catch and rethrow TaskException here. The caller of set(Task) will > have to deal with it (and you already do in install()). > > > private void reset(Task task) > > { > > - ByteBuffer buffer = task.memory; > > + int len = 0; > > + ByteBuffer buffer = null; > > + > > + if (null == task) > > + return; > > Again, this should be an error, don't silently return please. > > > Index: frysk-core/frysk/proc/IsaIA32.java > > =================================================================== > > RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v > > retrieving revision 1.2 > > diff -u -r1.2 IsaIA32.java > > --- frysk-core/frysk/proc/IsaIA32.java 8 Aug 2006 08:27:11 -0000 1.2 > > +++ frysk-core/frysk/proc/IsaIA32.java 22 Aug 2006 03:21:42 -0000 > > @@ -48,6 +48,8 @@ > > static final int I387_OFFSET = 18*4; > > static final int DBG_OFFSET = 63 * 4; > > > > + private static final byte[] BREAKPOINT_INSTRUCTION = { (byte)0xcc }; > > + > > static class IA32Register extends Register > > { > > IA32Register(String name, int wordOffset) > > @@ -121,6 +123,46 @@ > > { > > return ByteOrder.LITTLE_ENDIAN; > > } > > + > > + /** > > + * Get the breakpoint instruction. > > + * > > + * @return bytes[] the instruction of the ISA or null if TRAP is not > > + * initialized. > > + */ > > + public final byte[] getBpInstruction() > > + { > > + byte[] instruction = null; > > + > > + if (null == IsaIA32.BREAKPOINT_INSTRUCTION) > > + return null; > > That is an unnecessary check. It cannot be null, since you declare it > above. And if it were null we are in big trouble, so we want a > NullPointerException not a silent return. > > > + /** > > + * Get the true breakpoint address according to PC register after hitting > > + * one breakpoint set in task. In X86, the length of breakpoint instruction > > + * will be added to the PC register's value. So the true breakpoint address > > + * is the PC register's value minus the length of breakpoint. > > + */ > > + public long getBreakpointAddress(Task task) > > + { > > + long pcValue = 0; > > + > > + if (null == task) > > + return pcValue; > > Again, don't silently return when the task argument is null, that should > be a real error. > > > --- frysk-core/frysk/proc/IsaEMT64.java 8 Aug 2006 08:27:11 -0000 1.2 > > +++ frysk-core/frysk/proc/IsaEMT64.java 22 Aug 2006 03:22:15 -0000 > and > > --- frysk-core/frysk/proc/IsaPPC.java 4 Aug 2006 09:07:42 -0000 1.1 > > +++ frysk-core/frysk/proc/IsaPPC.java 22 Aug 2006 03:24:39 -0000 > > Same comments as for the IsaIA32.java code. > > > =================================================================== > > RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC.java,v > > retrieving revision 1.1 > > diff -u -r1.1 IsaPPC.java > > @@ -91,4 +91,22 @@ > > { > > return ByteOrder.BIG_ENDIAN; > > } > > + > > + /** > > + * Not support now. > > + * > > + * @return bytes[] the instruction of the ISA. > > + */ > > + public byte[] getBpInstruction() > > + { > > + return null; > > + } > > > > + /** > > + * Not support now. > > + */ > > + public long getBreakpointAddress(Task task) > > + { > > + return 0; > > + } > > It might be better to throw a RuntimeException here to make clear that > any usage of breakpoints isn't supported for PPC yet. > We do some modifications on our patch according to the above good advice. Now we have committed the modified patch into CVS. Thanks Mark! > > - // XXX add ppc case > > + // There's great difference to get the addresses of one function between > > + // PPC64 and other platform(such as X86/X86_64). What we get through the > > + // the form "&function_name" is the address of function descriptor but > > + // not the true entry address of the function. > > +#ifndef __powerpc64__ > > printf("%p\n", &first_breakpoint_function); > > printf("%p\n", &second_breakpoint_function); > > +#else > > + printf("%p\n", (void *)(*(long *)&first_breakpoint_function)); > > + printf("%p\n", (void *) (*(long *)&second_breakpoint_function)); > > +#endif > > Note that there is another usage of &function_name in > frysk-sys/frysk/sys/cni/TestLib.cxx for testing PtraceByteBuffer. It > needs a similar fix like this for ppc64. Thanks Mark to remind us about that. The TestPtraceByteBuffer case always passes in our PPC64 platform, so we didnot pay any attention to the case. Although the case passes, there's indeed the &function_name problem in TestLib.cxx. We will submit another patch to fix that. Thanks! > > Cheers, > > Mark > Best regards Yong Zheng From qiyaoltc@cn.ibm.com Wed Aug 23 10:12:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 23 Aug 2006 10:12:00 -0000 Subject: New method to get real length of register Message-ID: <20060823100418.GA18719@GreenHouse.cn.ibm.com> Register.getLength() now is not always equal to the real length of that register. On Ia32, segment register is 16-bit, instead of 32-bit. On X86-64, fs, gs, and ss are 16-bit, instead of 64-bit. On PPC64, xer and ccr are 32-bit, instead of 64-bit. On 64-bit platforms(X86-64 and PPC64), linux kernel assumes these registers as all 64-bit in order to simplify implementation(correct me if I am wrong). However, frysk should present the real length of the registers to the users. For example, in RegisterWindow, the real length of register could be presented if we add "0" as prefix.. "0x0037" is better than "0x37", since it could tell user that this register is 16-bit, and this would be more clear to display some flag registers or condition register. A new method getRealLength is added in Register, and mostly it is the same as getLength, and getRealLength is overridden if they are different. 2006-08-23 Yao Qi * Register.java (getRealLength): New method to return the real length of each register. * IsaIA32.java: Override getRealLength() of segment registers to return 2 since they are 16-bit registers. * IsaPPC64.java: Override getRealLength() of ccr and xer to return 4 since they are 32-bit registers on PPC64. * IsaEMT64.java: Override getRealLength() of segment registers to return 2 since they are 16-bit registers on X86_64. Tim, I add you in cc list, since you refactored IsaIA32 and IsaEMT64, and I also found that you are the author of UBigInteger, which is used to display values in RegisterWindows. Please review. Thanks! Could we rewrite toString in UBigInteger to display register values prefixed with "0"? Any comments? -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/proc/Register.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Register.java,v retrieving revision 1.9 diff -u -r1.9 Register.java --- frysk-core/frysk/proc/Register.java 16 Aug 2006 10:58:50 -0000 1.9 +++ frysk-core/frysk/proc/Register.java 23 Aug 2006 05:49:02 -0000 @@ -196,6 +196,10 @@ { return length; } + public int getRealLength() + { + return length; + } // void get(proc.Task task, byte[] bytes, int off, int len); // void get(Task task, byte[] array); -------------- next part -------------- Index: frysk-core/frysk/proc/IsaIA32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v retrieving revision 1.3 diff -u -r1.3 IsaIA32.java --- frysk-core/frysk/proc/IsaIA32.java 23 Aug 2006 04:04:19 -0000 1.3 +++ frysk-core/frysk/proc/IsaIA32.java 23 Aug 2006 05:55:08 -0000 @@ -65,12 +65,48 @@ new IA32Register("esi", 3), new IA32Register("edi", 4), new IA32Register("ebp", 5), - new IA32Register("cs", 13), - new IA32Register("ds", 7), - new IA32Register("es", 8), - new IA32Register("fs", 9), - new IA32Register("gs", 10), - new IA32Register("ss", 16), + new IA32Register("cs", 13) + { + public int getRealLength() + { + return 2; + } + }, + new IA32Register("ds", 7) + { + public int getRealLength() + { + return 2; + } + }, + new IA32Register("es", 8) + { + public int getRealLength() + { + return 2; + } + }, + new IA32Register("fs", 9) + { + public int getRealLength() + { + return 2; + } + }, + new IA32Register("gs", 10) + { + public int getRealLength() + { + return 2; + } + }, + new IA32Register("ss", 16) + { + public int getRealLength() + { + return 2; + } + }, new IA32Register("orig_eax", 11), new IA32Register("eip", 12), new IA32Register("efl", 14), -------------- next part -------------- Index: frysk-core/frysk/proc/IsaPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC64.java,v retrieving revision 1.2 diff -u -r1.2 IsaPPC64.java --- frysk-core/frysk/proc/IsaPPC64.java 23 Aug 2006 04:04:19 -0000 1.2 +++ frysk-core/frysk/proc/IsaPPC64.java 23 Aug 2006 05:54:40 -0000 @@ -36,8 +36,21 @@ private static final PPC64Register orig_r3 = new PPC64Register("orig_r3", 34); private static final PPC64Register ctr = new PPC64Register("ctr", 35); private static final PPC64Register lnk = new PPC64Register("lnk", 36); - private static final PPC64Register xer = new PPC64Register("xer", 37); - private static final PPC64Register ccr = new PPC64Register("ccr", 38); + // xer and ccr are all 32-bit registers on PPC64. + private static final PPC64Register xer = new PPC64Register("xer", 37) + { + public int getRealLength() + { + return 4; + } + }; + private static final PPC64Register ccr = new PPC64Register("ccr", 38) + { + public int getRealLength() + { + return 4; + } + }; private static final PPC64Register mq = new PPC64Register("mq", 39); private static final PPC64Register trap = new PPC64Register("trap", 40); private static final PPC64Register dar = new PPC64Register("dar", 41); @@ -53,7 +66,7 @@ IsaPPC64() { - for (int i = 0; i < gpr.length; i++) + for (int i = 0; i < gpr.length; i++) { registerMap.put (gpr[i].name, gpr[i]); } -------------- next part -------------- Index: frysk-core/frysk/proc/IsaEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaEMT64.java,v retrieving revision 1.3 diff -u -r1.3 IsaEMT64.java --- frysk-core/frysk/proc/IsaEMT64.java 23 Aug 2006 04:04:19 -0000 1.3 +++ frysk-core/frysk/proc/IsaEMT64.java 23 Aug 2006 09:55:18 -0000 @@ -76,12 +76,48 @@ new EMT64Register("r15", 0), new EMT64Register("rip", 16), new EMT64Register("eflags", 18), - new EMT64Register("cs", 17), - new EMT64Register("ss", 20), - new EMT64Register("ds", 23), - new EMT64Register("es", 24), - new EMT64Register("fs", 25), - new EMT64Register("gs", 26), + new EMT64Register("cs", 17) + { + public int getRealLength() + { + return 2; + } + }, + new EMT64Register("ss", 20) + { + public int getRealLength() + { + return 2; + } + }, + new EMT64Register("ds", 23) + { + public int getRealLength() + { + return 2; + } + }, + new EMT64Register("es", 24) + { + public int getRealLength() + { + return 2; + } + }, + new EMT64Register("fs", 25) + { + public int getRealLength() + { + return 2; + } + }, + new EMT64Register("gs", 26) + { + public int getRealLength() + { + return 2; + } + }, new EMT64Register("orig_rax", 15), new EMT64Register("fs_base", 21), new EMT64Register("gs_base", 22) }; From qiyaoltc@cn.ibm.com Wed Aug 23 11:49:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 23 Aug 2006 11:49:00 -0000 Subject: One frysk-core patch to add breakpoint support in PPC64. In-Reply-To: <1156250408.3003.76.camel@dijkstra.wildebeest.org> References: <1156220482.30530.29.camel@YZ_X86_64> <1156250408.3003.76.camel@dijkstra.wildebeest.org> Message-ID: <20060823113841.GB18719@GreenHouse.cn.ibm.com> On Tue, Aug 22, 2006 at 02:40:08PM +0200, Mark Wielaard wrote: > > Note that there is another usage of &function_name in > frysk-sys/frysk/sys/cni/TestLib.cxx for testing PtraceByteBuffer. It > needs a similar fix like this for ppc64. Hi, Mark, here is a fix for this. 2006-08-23 Yao Qi * cni/TestLib.cxx (getFuncAddr): Get function address instead of address of function descriptor on PPC64. (getFuncBytes): Likewise. Test it on X86/X86-64/PPC64, OK to commit? Thanks! -- Yao Qi -------------- next part -------------- Index: frysk-sys/frysk/sys/cni/TestLib.cxx =================================================================== RCS file: /cvs/frysk/frysk-sys/frysk/sys/cni/TestLib.cxx,v retrieving revision 1.2 diff -u -r1.2 TestLib.cxx --- frysk-sys/frysk/sys/cni/TestLib.cxx 28 Jun 2006 10:06:40 -0000 1.2 +++ frysk-sys/frysk/sys/cni/TestLib.cxx 23 Aug 2006 10:25:20 -0000 @@ -101,13 +101,21 @@ jlong frysk::sys::TestLib::getFuncAddr () { +#ifdef __powerpc64__ + return *((jlong*) dummyfunc); +#else return (jlong) dummyfunc; +#endif } jbyteArray frysk::sys::TestLib::getFuncBytes () { - char *addr = (char *) dummyfunc; +#ifdef __powerpc64__ + char *addr= (char *) *((jlong*) dummyfunc); +#else + char *addr = (char *) dummyfunc; +#endif jbyteArray bytes = JvNewByteArray (4); memcpy (elements (bytes), addr, 4); return bytes; From mark@klomp.org Wed Aug 23 12:24:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 23 Aug 2006 12:24:00 -0000 Subject: One frysk-core patch to add breakpoint support in PPC64. In-Reply-To: <20060823113841.GB18719@GreenHouse.cn.ibm.com> References: <1156220482.30530.29.camel@YZ_X86_64> <1156250408.3003.76.camel@dijkstra.wildebeest.org> <20060823113841.GB18719@GreenHouse.cn.ibm.com> Message-ID: <1156335828.3007.43.camel@dijkstra.wildebeest.org> On Wed, 2006-08-23 at 19:38 +0800, Yao Qi wrote: > Hi, Mark, here is a fix for this. > > 2006-08-23 Yao Qi > > * cni/TestLib.cxx (getFuncAddr): Get function address instead of > address of function descriptor on PPC64. > (getFuncBytes): Likewise. > > Test it on X86/X86-64/PPC64, OK to commit? Thanks! Looks fine to me. Thanks for the testing. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Wed Aug 23 12:39:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 23 Aug 2006 12:39:00 -0000 Subject: New method to get real length of register In-Reply-To: <20060823100418.GA18719@GreenHouse.cn.ibm.com> References: <20060823100418.GA18719@GreenHouse.cn.ibm.com> Message-ID: <1156336770.3007.49.camel@dijkstra.wildebeest.org> Hi, On Wed, 2006-08-23 at 18:04 +0800, Yao Qi wrote: > A new method getRealLength is added in Register, and mostly it is the > same as getLength, and getRealLength is overridden if they are > different. It might be easier if you define an additional constructor for Register that takes the realLenght and stores it in an instance field. That way you don't have to define all these methods for each individual register, which makes the code less readable imho. See attached for an example. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: register-reallength.patch Type: text/x-patch Size: 2463 bytes Desc: not available URL: From qiyaoltc@cn.ibm.com Wed Aug 23 14:50:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 23 Aug 2006 14:50:00 -0000 Subject: dwarf_get_cie_* and dwarf_get_fde_* in elfutils Message-ID: <20060823144247.GA2365@GreenHouse.cn.ibm.com> When do some experiments to do libunwind java binding, I find that the information about cie and fde is needed for libunwind java bindings to set the arguments about cie and fde to libunwind internal function. Current elfutils could not get the information about cie and fde, but the NEWS said that functions for cie/fde was implemented, like this, Version 0.9: Implement dwarf_get_fde_list_eh(), dwarf_get_cie_of_fde(), dwarf_get_fde_range(), dwarf_get_cie_info(), dwarf_get_fde_instr_bytes(), and tests for them. I do not know why and when these functions were removed from source tree. I could not find any elfutils source code with these functions above via google. On the other hand, information about cie and fde is important to frysk beside its libunwind java bindings. Could any one here tell me where could I find source code of elfutils-0.9? Is it feasible to import dwarf_get_cie*.c and dwarf_get_fde_*.c to elfutils in frysk-imports or put them back? Any comments? Thanks! -- Yao Qi From qiyaoltc@cn.ibm.com Wed Aug 23 15:04:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 23 Aug 2006 15:04:00 -0000 Subject: New method to get real length of register In-Reply-To: <1156336770.3007.49.camel@dijkstra.wildebeest.org> References: <20060823100418.GA18719@GreenHouse.cn.ibm.com> <1156336770.3007.49.camel@dijkstra.wildebeest.org> Message-ID: <20060823145559.GB2365@GreenHouse.cn.ibm.com> On Wed, Aug 23, 2006 at 02:39:30PM +0200, Mark Wielaard wrote: > Hi, > > It might be easier if you define an additional constructor for Register > that takes the realLenght and stores it in an instance field. That way > you don't have to define all these methods for each individual register, > which makes the code less readable imho. See attached for an example. Hmmm, It seems that you are right, Mark! The reason why I do not add a new member in Register is that most of the registers get the same thing from getLength() and getRealLength(), but do not think too much about readability, :) Thanks for your comments, and I will modify this patch per your advice. -- Yao Qi From roland@redhat.com Wed Aug 23 18:49:00 2006 From: roland@redhat.com (Roland McGrath) Date: Wed, 23 Aug 2006 18:49:00 -0000 Subject: dwarf_get_cie_* and dwarf_get_fde_* in elfutils In-Reply-To: Yao Qi's message of Wednesday, 23 August 2006 22:42:48 +0800 <20060823144247.GA2365@GreenHouse.cn.ibm.com> Message-ID: <20060823184924.6DC1D180066@magilla.sf.frob.com> libdw does not currently have any code whatsoever to parse .dwarf_frame section format. That's what DWARF support in libunwind is for. The format parsing code must already be there in libunwind if any kind of DWARF-based unwinding has ever worked. From timoore@redhat.com Wed Aug 23 19:59:00 2006 From: timoore@redhat.com (Tim Moore) Date: Wed, 23 Aug 2006 19:59:00 -0000 Subject: New method to get real length of register In-Reply-To: <20060823100418.GA18719@GreenHouse.cn.ibm.com> References: <20060823100418.GA18719@GreenHouse.cn.ibm.com> Message-ID: <44ECB3C8.5070303@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yao Qi wrote: > Register.getLength() now is not always equal to the real length of > that register. > > On Ia32, segment register is 16-bit, instead of 32-bit. > On X86-64, fs, gs, and ss are 16-bit, instead of 64-bit. > On PPC64, xer and ccr are 32-bit, instead of 64-bit. > > On 64-bit platforms(X86-64 and PPC64), linux kernel assumes these > registers as all 64-bit in order to simplify implementation(correct me > if I am wrong). However, frysk should present the real length of the > registers to the users. For example, in RegisterWindow, the real > length of register could be presented if we add "0" as prefix.. > "0x0037" is better than "0x37", since it could tell user that this > register is 16-bit, and this would be more clear to display some flag > registers or condition register. > > A new method getRealLength is added in Register, and mostly it is the > same as getLength, and getRealLength is overridden if they are > different. Right now I can't think of a reason why getLength() shouldn't return the real length of the register. There isn't any requirement that the registers that are read and written be some fixed length; PtraceByteBuffer handles those details. It was just laziness (and reading the header files) that caused all those segment registers to not be they're proper lengths. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE7LPHeDhWHdXrDRURAlnXAJ9NNldklOfgHEMMAKdg0FNklMku/QCgso9o kzyIq0u2VnwNNXDGuA40rdA= =wQ00 -----END PGP SIGNATURE----- From tromey@redhat.com Wed Aug 23 21:20:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Wed, 23 Aug 2006 21:20:00 -0000 Subject: javadoc update Message-ID: Here's a patch to fix some javadoc. I decapitalized 'FRYSK' in proc's package.html since it looks weird in all caps. I fixed a link in Syscall and wrote javadoc for the remaining public methods. Tom Index: frysk/proc/ChangeLog from Tom Tromey * Syscall.java: Updated javadoc. * package.html: Don't capitalize 'frysk'. Index: frysk/proc/Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Syscall.java,v retrieving revision 1.10 diff -u -r1.10 Syscall.java --- frysk/proc/Syscall.java 22 Aug 2006 00:44:00 -0000 1.10 +++ frysk/proc/Syscall.java 23 Aug 2006 21:14:41 -0000 @@ -41,9 +41,9 @@ import inua.util.PrintWriter; /** - * A class that holds static Syscall info. It is used - * in combination with @link frysk.proc.SyscallEventInfo and - * the task to get information about a particular system call event. + * A class that holds static information about a system call. It is + * used in combination with {@link SyscallEventInfo} and the + * task to get information about a particular system call event. */ public class Syscall { @@ -84,12 +84,14 @@ { this ("<" + number + ">", number, 0, "i:"); } - + + /** Return the name of the system call. */ public String getName() { return name; } + /** Return the system call's number. */ public int getNumber() { return number; @@ -111,7 +113,15 @@ writer.print (x); } } - + + /** + * Print a textual representation of a system call. + * @param writer where to print the representation + * @param task the task which supplies information about the + * arguments + * @param syscall the system call event info + * @return writer + */ public PrintWriter printCall (PrintWriter writer, frysk.proc.Task task, SyscallEventInfo syscall) @@ -152,6 +162,15 @@ return writer; } + /** + * Print a textual representation of the return result of a system + * call. + * @param writer where to print the representation + * @param task the task which supplies information about the + * return value + * @param syscall the system call event info + * @return writer + */ public PrintWriter printReturn (PrintWriter writer, frysk.proc.Task task, SyscallEventInfo syscallEventInfo) @@ -193,8 +212,14 @@ return writer; } - // XXX: Eventually this will be moved down to Linux, or even - // further. + /** + * Given a system call's number, this will return the corresponding + * Syscall object. Note that system call numbers are platform + * dependent. + * XXX: Eventually this will be moved down to Linux, or even + * further. + * @param num the number of the system call + */ public static Syscall syscallByNum (int num) { if(num >= syscallList.length || num < 0){ Index: frysk/proc/package.html =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/package.html,v retrieving revision 1.2 diff -u -r1.2 package.html --- frysk/proc/package.html 19 Sep 2005 00:05:23 -0000 1.2 +++ frysk/proc/package.html 23 Aug 2006 21:14:41 -0000 @@ -1,7 +1,7 @@ -This package implements FRYSK's process model of the target system. +This package implements frysk's process model of the target system.

Overview

From woodzltc@cn.ibm.com Thu Aug 24 01:35:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 24 Aug 2006 01:35:00 -0000 Subject: dwarf_get_cie_* and dwarf_get_fde_* in elfutils In-Reply-To: <20060823184924.6DC1D180066@magilla.sf.frob.com> References: <20060823184924.6DC1D180066@magilla.sf.frob.com> Message-ID: <44ED0228.2020807@cn.ibm.com> But from the help message of eu-readelf: -w, --debug-dump[=SECTION] Display DWARF section content. SECTION can be one of abbrev, aranges, frame, info, loc, line, ranges, pubnames, str, or macinfo. Our understanding is that eu-readelf is supposed to dump the content of .debug_frame, maybe in some time in the future. Am my understanding right? Roland McGrath wrote: > libdw does not currently have any code whatsoever to parse .dwarf_frame > section format. That's what DWARF support in libunwind is for. The format > parsing code must already be there in libunwind if any kind of DWARF-based > unwinding has ever worked. > From woodzltc@cn.ibm.com Thu Aug 24 01:47:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 24 Aug 2006 01:47:00 -0000 Subject: any way to get one notified when a new bug is opened on Frysk Message-ID: <44ED0509.6060909@cn.ibm.com> I would like to track all the Frysk relevant bugs on sources.redhat.com. Is there any way to get myself notified when a new bug is opened on Frysk? Regards - Wu Zhou From roland@redhat.com Thu Aug 24 02:16:00 2006 From: roland@redhat.com (Roland McGrath) Date: Thu, 24 Aug 2006 02:16:00 -0000 Subject: dwarf_get_cie_* and dwarf_get_fde_* in elfutils In-Reply-To: Wu Zhou's message of Thursday, 24 August 2006 09:34:32 +0800 <44ED0228.2020807@cn.ibm.com> Message-ID: <20060824021633.30654180066@magilla.sf.frob.com> > But from the help message of eu-readelf: > > -w, --debug-dump[=SECTION] Display DWARF section content. SECTION can be one > of abbrev, aranges, frame, info, loc, line, > ranges, pubnames, str, or macinfo. > > Our understanding is that eu-readelf is supposed to dump the content of .debug_frame, maybe in some > time in the future. Am my understanding right? In future, it will, yes. The binutils readelf can display it. From zhengyo@cn.ibm.com Thu Aug 24 02:28:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Thu, 24 Aug 2006 02:28:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <1156132796.18109.13.camel@YZ_X86_64> References: <1155884638.7779.25.camel@YZ_X86_64> <44E5E21B.7080604@redhat.com> <1156132796.18109.13.camel@YZ_X86_64> Message-ID: <1156386190.30530.47.camel@YZ_X86_64> On Mon, 2006-08-21 at 11:59 +0800, Yong Zheng wrote: > hi, > > According to Andrew's advice, we merge the following three testcases > (TestI386Regs.java, TestX8664Regs.java and TestPPC64Regs.java) into one > case: TestRegs.java. > > After merging the three cases, the files TestI386Regs.java, > TestX8664Regs.java and TestPPC64Regs.java can be removed from > frysk-core/frysk/proc/. > > If it's ok, we will post out the patch for merging TestI386Modify.java, > TestX8664Modify.java and TestPPC64Modify.java. > > Here is the patch for adding TestRegs.java. Rebuild frysk on > X86/X86-64/PPC64 based on the cvs head(08-18) and tested. please review. > Any comments for this? If there's no any objection, we will commit the patch later. Thanks. Best regards Yong Zheng From qiyaoltc@cn.ibm.com Thu Aug 24 03:15:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 24 Aug 2006 03:15:00 -0000 Subject: javadoc update In-Reply-To: References: Message-ID: <20060824030730.GA19715@GreenHouse.cn.ibm.com> On Wed, Aug 23, 2006 at 03:14:51PM -0600, Tom Tromey wrote: > Here's a patch to fix some javadoc. > > I decapitalized 'FRYSK' in proc's package.html since it looks weird in > all caps. > > I fixed a link in Syscall and wrote javadoc for the remaining public > methods. > > Tom > > Index: frysk/proc/ChangeLog > from Tom Tromey > > * Syscall.java: Updated javadoc. > * package.html: Don't capitalize 'frysk'. Hi, Tom, Checked it in. Thanks! -- Yao Qi From qiyaoltc@cn.ibm.com Thu Aug 24 07:15:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 24 Aug 2006 07:15:00 -0000 Subject: New method to get real length of register In-Reply-To: <44ECB3C8.5070303@redhat.com> References: <20060823100418.GA18719@GreenHouse.cn.ibm.com> <44ECB3C8.5070303@redhat.com> Message-ID: <20060824070643.GB19715@GreenHouse.cn.ibm.com> On Wed, Aug 23, 2006 at 10:00:08PM +0200, Tim Moore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yao Qi wrote: > > Register.getLength() now is not always equal to the real length of > > that register. > > > > On Ia32, segment register is 16-bit, instead of 32-bit. > > On X86-64, fs, gs, and ss are 16-bit, instead of 64-bit. > > On PPC64, xer and ccr are 32-bit, instead of 64-bit. > > > > On 64-bit platforms(X86-64 and PPC64), linux kernel assumes these > > registers as all 64-bit in order to simplify implementation(correct me > > if I am wrong). However, frysk should present the real length of the > > registers to the users. For example, in RegisterWindow, the real > > length of register could be presented if we add "0" as prefix.. > > "0x0037" is better than "0x37", since it could tell user that this > > register is 16-bit, and this would be more clear to display some flag > > registers or condition register. > > > > A new method getRealLength is added in Register, and mostly it is the > > same as getLength, and getRealLength is overridden if they are > > different. > > Right now I can't think of a reason why getLength() shouldn't return the > real length of the register. There isn't any requirement that the > registers that are read and written be some fixed length; Hi, Tim, At first, I override getLength() to return the real length of the register(as you suggested above), but the TestX8664Regs failed when reading the value of rdx. However, I could not reproduce this problem after I update these code. :( > PtraceByteBuffer handles those details. It was just laziness (and > reading the header files) that caused all those segment registers to not > be they're proper lengths. Register.get() could get the member length to do ptrace operations with kernel, although member length is not the real length of register, but it is the right length to kernel. getLength() should return real length of register to tell the outsiders. For x86 and x86-64, all the segment registers are different from others, so how about write a new class IA32SegmentRegister, which extends IA32Register(EMT64SegmentRegister extends EMT64Register), and override getLength() to return these real length. Condation or status register makes troubles on PPC64, so a new class, PPC64_32Register, could do the similar thing. Here is an example in attachment. Please review, and comments are welcome. If it is ok to you, I will send another formal patch with changelog for x86/x86-64/ppc64. If you could do it for x86-64, I do not mind, :) -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/proc/IsaIA32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v retrieving revision 1.3 diff -u -r1.3 IsaIA32.java --- frysk-core/frysk/proc/IsaIA32.java 23 Aug 2006 04:04:19 -0000 1.3 +++ frysk-core/frysk/proc/IsaIA32.java 24 Aug 2006 07:02:41 -0000 @@ -57,6 +57,19 @@ super(0, wordOffset * 4, 4, name); } } + + static class IA32SegmentRegister extends IA32Register + { + IA32SegmentRegister(String name, int wordOffset) + { + super(name, wordOffset); + } + public int getLength() + { + return 2; + } + } + private static final IA32Register[] regDefs = { new IA32Register("eax", 6), new IA32Register("ebx", 0), @@ -65,12 +78,12 @@ new IA32Register("esi", 3), new IA32Register("edi", 4), new IA32Register("ebp", 5), - new IA32Register("cs", 13), - new IA32Register("ds", 7), - new IA32Register("es", 8), - new IA32Register("fs", 9), - new IA32Register("gs", 10), - new IA32Register("ss", 16), + new IA32SegmentRegister("cs", 13), + new IA32SegmentRegister("ds", 7), + new IA32SegmentRegister("es", 8), + new IA32SegmentRegister("fs", 9), + new IA32SegmentRegister("gs", 10), + new IA32SegmentRegister("ss", 16), new IA32Register("orig_eax", 11), new IA32Register("eip", 12), new IA32Register("efl", 14), From mark@klomp.org Thu Aug 24 08:00:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 24 Aug 2006 08:00:00 -0000 Subject: any way to get one notified when a new bug is opened on Frysk In-Reply-To: <44ED0509.6060909@cn.ibm.com> References: <44ED0509.6060909@cn.ibm.com> Message-ID: <1156406421.3015.1.camel@dijkstra.wildebeest.org> Hi, On Thu, 2006-08-24 at 09:46 +0800, Wu Zhou wrote: > I would like to track all the Frysk relevant bugs on sources.redhat.com. Is there any way to get > myself notified when a new bug is opened on Frysk? Andrew is working on it with the sourceware people so we get email on every bugzilla change to some central email address. Cheers, Mark From timoore@redhat.com Thu Aug 24 09:00:00 2006 From: timoore@redhat.com (Tim Moore) Date: Thu, 24 Aug 2006 09:00:00 -0000 Subject: New method to get real length of register In-Reply-To: <20060824070643.GB19715@GreenHouse.cn.ibm.com> References: <20060823100418.GA18719@GreenHouse.cn.ibm.com> <44ECB3C8.5070303@redhat.com> <20060824070643.GB19715@GreenHouse.cn.ibm.com> Message-ID: <44ED6A9C.6050905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yao Qi wrote: > On Wed, Aug 23, 2006 at 10:00:08PM +0200, Tim Moore wrote: > > Register.get() could get the member length to do ptrace operations > with kernel, although member length is not the real length of > register, but it is the right length to kernel. This shouldn't be necessary; PtraceByteBuffer "does the right thing" with respect to short read and writes into the buffer that stores the register values. > > getLength() should return real length of register to tell the > outsiders. > > For x86 and x86-64, all the segment registers are different from > others, so how about write a new class IA32SegmentRegister, which > extends IA32Register(EMT64SegmentRegister extends EMT64Register), > and override getLength() to return these real length. > Condation or status register makes troubles on PPC64, so a new class, > PPC64_32Register, could do the similar thing. This is the approach I had in mind. Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE7WqceDhWHdXrDRURAh2QAJ92zG6bVQUSS5CHBzj+YabNEUfFmACfV7qI tkpmmgLb/PnJWIRr5THWs/U= =D1kz -----END PGP SIGNATURE----- From zhengyo@cn.ibm.com Thu Aug 24 10:11:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Thu, 24 Aug 2006 10:11:00 -0000 Subject: bi-arch test patch for 64-bit frysk Message-ID: <1156413940.2172.63.camel@YZ_X86_64> hi, On PPC64, all applications are compiled into 32-bit mode by default if the compiling option "-m64" isn't explicitly given, which means most applications running on PPC64 are in 32-bit mode. So it's necessary for 64-bit frysk to debug 32-bit applications on PPC64. Currently, funit(in frysk-core/frysk/pkglibexecdir/) should be build in 64-bit mode, since it is dependent on other 64-bit frysk libraries, such as libfrysk-core.a. In order to build other test cases in 32-bit mode without breaking the 64-bit funit, one rule in Makefile.am is added. That is to say, we remove all existent test cases(64-bit) except funit, and rebuild them in 32-bit mode. All these 32-bit test cases could be run via TestRunner. On X86_64, although applications are compiled in 64-bit mode by default, it's also necessary to do bi-arch test. The modifications will be useful to 64-bit frysk on X86_64. Among the frysk's five main sub-directories, frysk-gtk, frsyk-gui, frysk-import and frysk-sys needn't do the bi-arch tests for their less arch-dependence. So no rules are added for them. If someone thinks it's also necessary, we'd like to add rules for them. Please review, and any comments are welcome! Thanks! 2006-08-24 Yong Zheng * frysk-core/Makefile.am: Add support for compiling 32bit testcases. Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_core_Makefile_am.patch Type: text/x-patch Size: 542 bytes Desc: not available URL: From woodzltc@cn.ibm.com Thu Aug 24 10:20:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 24 Aug 2006 10:20:00 -0000 Subject: any way to get one notified when a new bug is opened on Frysk In-Reply-To: <1156406421.3015.1.camel@dijkstra.wildebeest.org> References: <44ED0509.6060909@cn.ibm.com> <1156406421.3015.1.camel@dijkstra.wildebeest.org> Message-ID: <44ED7D51.605@cn.ibm.com> That is great! When it is ready, please include me in the circle. Thanks! Mark Wielaard wrote: > Hi, > > On Thu, 2006-08-24 at 09:46 +0800, Wu Zhou wrote: >> I would like to track all the Frysk relevant bugs on sources.redhat.com. Is there any way to get >> myself notified when a new bug is opened on Frysk? > > Andrew is working on it with the sourceware people so we get email on > every bugzilla change to some central email address. > > Cheers, > > Mark > Regards - Wu Zhou From zhengyo@cn.ibm.com Thu Aug 24 11:43:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Thu, 24 Aug 2006 11:43:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <1156413940.2172.63.camel@YZ_X86_64> References: <1156413940.2172.63.camel@YZ_X86_64> Message-ID: <1156419492.2172.87.camel@YZ_X86_64> hi, The followings are some difference between the test results of cases in 64-bit mode and in 32-bit mode on 64-bit frysk. All tests are based on the cvs head(08-24). On X86_64, the following cases fail in 32-bit mode but pass in 64-bit mode on 64-bit frysk: 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: unknown word size for auxv (1|32l|64l|32b|64b 10000) at frysk.sys.proc.AuxvBuilder.construct(TestRunner) 2)testProcRefresh(frysk.proc.TestRefresh)junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendDelCloneWaitForAcks (Sig_USR2)) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) 3)testExecSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: Caught exec syscall expected: but was: at frysk.proc.TestTaskSyscallObserver.testExecSyscall(TestRunner) 4)testX8664Modify(frysk.proc.TestX8664Modify)junit.framework.AssertionFailedError: unexpected signal 30 5)testCloneSyscall(frysk.proc.TestTaskSyscallObserver)java.lang.RuntimeException: clone's parent in unexpected state syscallRunning at frysk.proc.TaskState.clonedState(TestRunner) On PPC64, the following cases fail in 32-bit mode but pass in 64-bit mode on 64-bit frysk: 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: unknown word size for auxv (1|32l|64l|32b|64b 10000) 2)testExecSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: Caught exec syscall expected: but was: 3)testSyscallOpen(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: attempt to open a.file Best regards Yong Zheng From mcvet@redhat.com Thu Aug 24 14:17:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Thu, 24 Aug 2006 14:17:00 -0000 Subject: any way to get one notified when a new bug is opened on Frysk In-Reply-To: <44ED7D51.605@cn.ibm.com> References: <44ED0509.6060909@cn.ibm.com> <1156406421.3015.1.camel@dijkstra.wildebeest.org> <44ED7D51.605@cn.ibm.com> Message-ID: <1156429018.10360.9.camel@towel.toronto.redhat.com> On Thu, 2006-08-24 at 18:20 +0800, Wu Zhou wrote: > That is great! When it is ready, please include me in the circle. Thanks! > > Mark Wielaard wrote: > > Hi, > > > > On Thu, 2006-08-24 at 09:46 +0800, Wu Zhou wrote: > >> I would like to track all the Frysk relevant bugs on sources.redhat.com. Is there any way to get > >> myself notified when a new bug is opened on Frysk? > > > > Andrew is working on it with the sourceware people so we get email on > > every bugzilla change to some central email address. > > > > Cheers, > > > > Mark > > > > Regards > - Wu Zhou I always thought it would be cool if zebedeebot would paste into the channel the summary, reporter,and link to each new bug filed for Frysk... - Mike From woodzltc@cn.ibm.com Thu Aug 24 14:52:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Thu, 24 Aug 2006 14:52:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <1156419492.2172.87.camel@YZ_X86_64> References: <1156413940.2172.63.camel@YZ_X86_64> <1156419492.2172.87.camel@YZ_X86_64> Message-ID: <44EDBD32.3090608@cn.ibm.com> Yong Zheng wrote: > hi, > > The followings are some difference between the test results of cases in > 64-bit mode and in 32-bit mode on 64-bit frysk. > > All tests are based on the cvs head(08-24). > > On X86_64, the following cases fail in 32-bit mode but pass in 64-bit > mode on 64-bit frysk: > > 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: unknown > word size for auxv (1|32l|64l|32b|64b 10000) > at frysk.sys.proc.AuxvBuilder.construct(TestRunner) on ppc64, testGetAuxv fails in 32-bit testcase because there are three AT_NULL at the end of aux vectors, which might be actually ok (because I don't see any nagative impact it can bring up). I don't know what is the situation in x86_64. But I guess it is the same. GDB encounters the same problem for 32-bit application on ppc64. Roland had a fix for that, but I don't verify yet. I can code a patch in Frysk's side tomorrow morning. > 2)testProcRefresh(frysk.proc.TestRefresh)junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendDelCloneWaitForAcks (Sig_USR2)) > at frysk.proc.TestLib.assertRunUntilStop(TestRunner) > > 3)testExecSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: Caught exec syscall expected: but was: > at frysk.proc.TestTaskSyscallObserver.testExecSyscall(TestRunner) I guess this is the same problem with 32-bit testExecSyscall on ppc64: syscall tracer don't get correctly the syscall number. Something in EM64T ISA need to be changed to support 32-bit target well I guess. BTW, one thing confusing me is that why it is named EM64T, and not X86_64. Just curious anyway. :-) Regards - Wu Zhou From qiyaoltc@cn.ibm.com Fri Aug 25 01:58:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 01:58:00 -0000 Subject: frysk-core/frysk/proc ChangeLog TaskState.java Message-ID: <20060825015010.GA9037@GreenHouse.cn.ibm.com> > Log message: > 2006-08-24 Hi, Sami, The name in ChangeLog entry is lost, and I have add it for you. :) > > * TaskState.java: Added handleSignaledEvent to runningInSyscall Could you explain why do you do this? I am confused by this a bit. Do you mean the child will receive a signal when it is in syscall? Is there any bugs opened before we apply this patch? Thanks! -- Yao Qi From qiyaoltc@cn.ibm.com Fri Aug 25 02:09:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 02:09:00 -0000 Subject: Test results on PPC64(08/25/2006, frysk-core). Message-ID: <20060825020033.GB9037@GreenHouse.cn.ibm.com> Just for your information. Time: 33.641 There were 2 errors: 1) testSyscallInterrupt(frysk.proc.TestTaskSyscallObserver)java.lang.RuntimeException: Read exit before enter at java.lang.VMThrowable._ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9Throwable16fillInStackTraceEv(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9ThrowableC1EPNS0_6StringE(libgcj.so.7) at java.lang.Exception._ZN4java4lang9ExceptionC1EPNS0_6StringE(libgcj.so.7) at java.lang.RuntimeException._ZN4java4lang16RuntimeExceptionC1EPNS0_6StringE(libgcj.so.7) at frysk.proc.TestTaskSyscallObserver$TestSyscallInterruptInternals$SyscallInterruptObserver(TestRunner) at frysk.proc.Task(TestRunner) at frysk.proc.TaskState$16(TestRunner) at frysk.proc.Task(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld$2(TestRunner) at frysk.sys.Wait(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld(TestRunner) at frysk.event.EventLoop(TestRunner) at frysk.event.EventLoop(TestRunner) at frysk.proc.TestLib(TestRunner) at frysk.proc.TestLib(TestRunner) at frysk.proc.TestTaskSyscallObserver(TestRunner) at java.lang.reflect.Method._ZN4java4lang7reflect6Method6invokeEPNS0_6ObjectEP6JArrayIS4_E(libgcj.so.7) at frysk.junit.Runner(TestRunner) at TestRunner(TestRunner) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread9call_mainEv(libgcj.so.7) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread3runEv(libgcj.so.7) 2) testSyscallInterruptRestart(frysk.proc.TestTaskSyscallObserver)java.lang.RuntimeException: Read exit before enter at java.lang.VMThrowable._ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9Throwable16fillInStackTraceEv(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9ThrowableC1EPNS0_6StringE(libgcj.so.7) at java.lang.Exception._ZN4java4lang9ExceptionC1EPNS0_6StringE(libgcj.so.7) at java.lang.RuntimeException._ZN4java4lang16RuntimeExceptionC1EPNS0_6StringE(libgcj.so.7) at frysk.proc.TestTaskSyscallObserver$TestSyscallInterruptInternals$SyscallInterruptObserver(TestRunner) at frysk.proc.Task(TestRunner) at frysk.proc.TaskState$16(TestRunner) at frysk.proc.Task(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld$2(TestRunner) at frysk.sys.Wait(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld(TestRunner) at frysk.event.EventLoop(TestRunner) at frysk.event.EventLoop(TestRunner) at frysk.proc.TestLib(TestRunner) at frysk.proc.TestLib(TestRunner) at frysk.proc.TestTaskSyscallObserver(TestRunner) at java.lang.reflect.Method._ZN4java4lang7reflect6Method6invokeEPNS0_6ObjectEP6JArrayIS4_E(libgcj.so.7) at frysk.junit.Runner(TestRunner) at TestRunner(TestRunner) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread9call_mainEv(libgcj.so.7) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread3runEv(libgcj.so.7) There were 2 failures: 1) testTaskBlockExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: tmp file exists at java.lang.VMThrowable._ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9Throwable16fillInStackTraceEv(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9ThrowableC1EPNS0_6StringE(libgcj.so.7) at java.lang.Error._ZN4java4lang5ErrorC1EPNS0_6StringE(libgcj.so.7) at junit.framework.AssertionFailedError(TestRunner) at junit.framework.Assert(TestRunner) at junit.framework.Assert(TestRunner) at junit.framework.Assert(TestRunner) at frysk.proc.TestExec(TestRunner) at java.lang.reflect.Method._ZN4java4lang7reflect6Method6invokeEPNS0_6ObjectEP6JArrayIS4_E(libgcj.so.7) at frysk.junit.Runner(TestRunner) at TestRunner(TestRunner) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread9call_mainEv(libgcj.so.7) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread3runEv(libgcj.so.7) 2) testAttachedMultipleChildExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendExecWaitForAcks:14244 (Sig_USR1)) at java.lang.VMThrowable._ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9Throwable16fillInStackTraceEv(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9ThrowableC1EPNS0_6StringE(libgcj.so.7) at java.lang.Error._ZN4java4lang5ErrorC1EPNS0_6StringE(libgcj.so.7) at junit.framework.AssertionFailedError(TestRunner) at junit.framework.Assert(TestRunner) at junit.framework.Assert(TestRunner) at frysk.proc.TestLib(TestRunner) at frysk.proc.TestLib(TestRunner) at frysk.proc.TestLib$AckHandler(TestRunner) at frysk.proc.TestLib$AckHandler(TestRunner) at frysk.proc.TestLib$AckProcess(TestRunner) at frysk.proc.TestExec(TestRunner) at java.lang.reflect.Method._ZN4java4lang7reflect6Method6invokeEPNS0_6ObjectEP6JArrayIS4_E(libgcj.so.7) at frysk.junit.Runner(TestRunner) at TestRunner(TestRunner) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread9call_mainEv(libgcj.so.7) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread3runEv(libgcj.so.7) FAILURES!!! Tests run: 141, Failures: 2, Errors: 2 -- Yao Qi From qiyaoltc@cn.ibm.com Fri Aug 25 02:14:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 02:14:00 -0000 Subject: Test results on PPC64(08/25/2006, frysk-import). In-Reply-To: <20060825020033.GB9037@GreenHouse.cn.ibm.com> References: <20060825020033.GB9037@GreenHouse.cn.ibm.com> Message-ID: <20060825020635.GC9037@GreenHouse.cn.ibm.com> Running testGet(inua.eio.TestGet) ...PASS Running testMmap(inua.eio.TestMmap) ...PASS Running testPut(inua.eio.TestPut) ...PASS Running testGetWord(inua.eio.TestWordSize) ...PASS Running testRest(inua.eio.TestWordSize) ...PASS Running testParamaterlessPool(inua.util.TestPool) ...PASS Running testParameteredPool(inua.util.TestPool) ...PASS Running testGetLine(lib.dw.tests.TestDwfl) ...<>PASS Running testGetDie(lib.dw.tests.TestDwfl) ...PASS Running testCore(lib.elf.tests.TestElf) ...PASS Running testObjectFile(lib.elf.tests.TestElf) ...<>PASS Running testDisassembler(lib.opcodes.tests.TestOpcodes) ...<>PASS Time: 0.029 OK (12 tests) -- Yao Qi From qiyaoltc@cn.ibm.com Fri Aug 25 02:18:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 02:18:00 -0000 Subject: Test results on PPC64(08/25/2006, frysk-gui). In-Reply-To: <20060825020635.GC9037@GreenHouse.cn.ibm.com> References: <20060825020033.GB9037@GreenHouse.cn.ibm.com> <20060825020635.GC9037@GreenHouse.cn.ibm.com> Message-ID: <20060825021041.GD9037@GreenHouse.cn.ibm.com> Time: 1.612 There was 1 failure: 1) testGladeLoading(frysk.gui.test.TestGlade)junit.framework.AssertionFailedError: menuBar at java.lang.VMThrowable._ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9Throwable16fillInStackTraceEv(libgcj.so.7) at java.lang.Throwable._ZN4java4lang9ThrowableC1EPNS0_6StringE(libgcj.so.7) at java.lang.Error._ZN4java4lang5ErrorC1EPNS0_6StringE(libgcj.so.7) at junit.framework.AssertionFailedError(TestRunner) at junit.framework.Assert(TestRunner) at junit.framework.Assert(TestRunner) at junit.framework.Assert(TestRunner) at frysk.gui.test.TestGlade(TestRunner) at java.lang.reflect.Method._ZN4java4lang7reflect6Method6invokeEPNS0_6ObjectEP6JArrayIS4_E(libgcj.so.7) at frysk.junit.Runner(TestRunner) at TestRunner(TestRunner) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread9call_mainEv(libgcj.so.7) at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread3runEv(libgcj.so.7) FAILURES!!! Tests run: 13, Failures: 1, Errors: 0 -- Yao Qi From qiyaoltc@cn.ibm.com Fri Aug 25 02:21:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 02:21:00 -0000 Subject: Test results on PPC64(08/25/2006, frysk-sys). In-Reply-To: <20060825020033.GB9037@GreenHouse.cn.ibm.com> References: <20060825020033.GB9037@GreenHouse.cn.ibm.com> Message-ID: <20060825021346.GE9037@GreenHouse.cn.ibm.com> Running testIA32(frysk.sys.proc.TestAuxv) ...PASS Running testAMD64(frysk.sys.proc.TestAuxv) ...PASS Running testIA64(frysk.sys.proc.TestAuxv) ...PASS Running testPPC32(frysk.sys.proc.TestAuxv) ...PASS Running testPPC64(frysk.sys.proc.TestAuxv) ...PASS Running test(frysk.sys.proc.TestCmdLine) ...PASS Running test_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0_c0(frysk.sys.proc.TestCmdLine) ...PASS Running testIA32(frysk.sys.proc.TestMaps) ...PASS Running testIA64(frysk.sys.proc.TestMaps) ...PASS Running testAMD64(frysk.sys.proc.TestMaps) ...PASS Running testPPC32(frysk.sys.proc.TestMaps) ...PASS Running testPPC64(frysk.sys.proc.TestMaps) ...PASS Running testParseStatusGetID(frysk.sys.proc.TestStatus) ...PASS Running testParseStatusNullBufferGetID(frysk.sys.proc.TestStatus) ...PASS Running testParseStatusInvalidBufferGetID(frysk.sys.proc.TestStatus) ...PASS Running testMapRead(frysk.sys.StressMapRead) ...<>PASS Running testChildContinue(frysk.sys.TestCallPtrace) ...PASS Running testAttach(frysk.sys.TestCallPtrace) ...PASS Running testTextVariable(frysk.sys.TestPtraceByteBuffer) ...PASS Running testDataFunction(frysk.sys.TestPtraceByteBuffer) ...PASS Running testAll(frysk.sys.TestPty) ...PASS Running testFillEmpty(frysk.sys.TestSigSet) ...PASS Running testAddRemove(frysk.sys.TestSigSet) ...PASS Running testList(frysk.sys.TestSigSet) ...PASS Running testProcMask(frysk.sys.TestSigSet) ...PASS Time: 0.027 OK (31 tests) -- Yao Qi From pmuldoon@redhat.com Fri Aug 25 02:30:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 25 Aug 2006 02:30:00 -0000 Subject: Test results on PPC64(08/25/2006, frysk-gui). In-Reply-To: <20060825021041.GD9037@GreenHouse.cn.ibm.com> References: <20060825020033.GB9037@GreenHouse.cn.ibm.com> <20060825020635.GC9037@GreenHouse.cn.ibm.com> <20060825021041.GD9037@GreenHouse.cn.ibm.com> Message-ID: <44EE60C5.5050204@redhat.com> I'm not sure what kernel version this is? And was it a headless box? Yao Qi wrote: > Time: 1.612 > There was 1 failure: > 1) > testGladeLoading(frysk.gui.test.TestGlade)junit.framework.AssertionFailedError: > menuBar > at java.lang.VMThrowable._ZN4java4lang11VMThrowable16fillInStackTraceEPNS0_9ThrowableE(libgcj.so.7) > at java.lang.Throwable._ZN4java4lang9Throwable16fillInStackTraceEv(libgcj.so.7) > at java.lang.Throwable._ZN4java4lang9ThrowableC1EPNS0_6StringE(libgcj.so.7) > at java.lang.Error._ZN4java4lang5ErrorC1EPNS0_6StringE(libgcj.so.7) > at junit.framework.AssertionFailedError(TestRunner) > at junit.framework.Assert(TestRunner) > at junit.framework.Assert(TestRunner) > at junit.framework.Assert(TestRunner) > at frysk.gui.test.TestGlade(TestRunner) > at java.lang.reflect.Method._ZN4java4lang7reflect6Method6invokeEPNS0_6ObjectEP6JArrayIS4_E(libgcj.so.7) > at frysk.junit.Runner(TestRunner) > at TestRunner(TestRunner) > at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread9call_mainEv(libgcj.so.7) > at gnu.java.lang.MainThread._ZN3gnu4java4lang10MainThread3runEv(libgcj.so.7) > > FAILURES!!! > Tests run: 13, Failures: 1, Errors: 0 > > From qiyaoltc@cn.ibm.com Fri Aug 25 02:42:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 02:42:00 -0000 Subject: information about system and kernel. In-Reply-To: <20060825020033.GB9037@GreenHouse.cn.ibm.com> References: <20060825020033.GB9037@GreenHouse.cn.ibm.com> Message-ID: <20060825023419.GF9037@GreenHouse.cn.ibm.com> forget to post these details first! [root@power-frysk1 ~]# uname -a Linux power-frysk1.cn.ibm.com 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:57:06 EST 2006 ppc64 ppc64 ppc64 GNU/Linux [root@power-frysk1 ~]# gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/ppc64-redhat-linux/4.1.1/libgcj.spec rename spec lib to liborig Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-secureplt --with-long-double-128 --host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) -- Yao Qi From qiyaoltc@cn.ibm.com Fri Aug 25 05:30:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 05:30:00 -0000 Subject: Test results on PPC64(08/25/2006, frysk-gui). In-Reply-To: <44EE60C5.5050204@redhat.com> References: <20060825020033.GB9037@GreenHouse.cn.ibm.com> <20060825020635.GC9037@GreenHouse.cn.ibm.com> <20060825021041.GD9037@GreenHouse.cn.ibm.com> <44EE60C5.5050204@redhat.com> Message-ID: <20060825052229.GG9037@GreenHouse.cn.ibm.com> On Thu, Aug 24, 2006 at 09:30:29PM -0500, Phil Muldoon wrote: > I'm not sure what kernel version this is? And was it a headless box? > I rebuilt frysk with cvs head, and all cases passed. [qiyao@plinuxt18 frysk-gui]$ ./TestRunner Running testAddingRemovingActions(frysk.gui.test.TestActionManager) ...PASS Running testAddingRemovingFilters(frysk.gui.test.TestFilterManager) ...PASS Running testGladeLoading(frysk.gui.test.TestGlade) ...GTK Accessibility Module initialized PASS Running testIconManagerLoad(frysk.gui.test.TestIconManager) ...PASS Running testIconManagerGetFactory(frysk.gui.test.TestIconManager) ...PASS Running testIconLookups(frysk.gui.test.TestIconManager) ...PASS Running testSaveLoad(frysk.gui.test.TestObserverSaveLoad) ...PASS Running testFilterPointSaveLoad(frysk.gui.test.TestObserverSaveLoad) ...PASS Running testActionPointSaveLoad(frysk.gui.test.TestObserverSaveLoad) ...PASS Running testExport(frysk.gui.test.TestObserverSaveLoad) ...PASS Running testPrototypeCopying(frysk.gui.test.TestPrototypeCopying) ...PASS Running testSaveLoad(frysk.gui.test.TestSessionSaveLoad) ...PASS Running testSaveLoad(frysk.gui.test.TestTagsetSaveLoad) ...PASS Time: 1.865 OK (13 tests) Aborted -- Yao Qi From qiyaoltc@cn.ibm.com Fri Aug 25 08:14:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 25 Aug 2006 08:14:00 -0000 Subject: New method to get real length of register In-Reply-To: <44ED6A9C.6050905@redhat.com> References: <20060823100418.GA18719@GreenHouse.cn.ibm.com> <44ECB3C8.5070303@redhat.com> <20060824070643.GB19715@GreenHouse.cn.ibm.com> <44ED6A9C.6050905@redhat.com> Message-ID: <20060825080622.GH9037@GreenHouse.cn.ibm.com> On Thu, Aug 24, 2006 at 11:00:12AM +0200, Tim Moore wrote: > > > > getLength() should return real length of register to tell the > > outsiders. > > > > For x86 and x86-64, all the segment registers are different from > > others, so how about write a new class IA32SegmentRegister, which > > extends IA32Register(EMT64SegmentRegister extends EMT64Register), > > and override getLength() to return these real length. > > Condation or status register makes troubles on PPC64, so a new class, > > PPC64_32Register, could do the similar thing. > > This is the approach I had in mind. Hi, Tim and Mark, Here are some new patches to do what we discussed in this thread. 2006-08-25 Yao Qi * IsaIA32.java: New class for 16-bit segment register on IA32. * TestI386Regs.java: Test length of segment register. * IsaEMT64.java: New class for 32-bit segment registers on X86_64. * TestX8664Regs.java: Test length of segment register. * IsaPPC64.java: New class for 32-bit registers on PPC64. Test them on X86/X86-64/PPC64. OK to commit? Thanks! -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/proc/IsaIA32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v retrieving revision 1.3 diff -u -r1.3 IsaIA32.java --- frysk-core/frysk/proc/IsaIA32.java 23 Aug 2006 04:04:19 -0000 1.3 +++ frysk-core/frysk/proc/IsaIA32.java 25 Aug 2006 07:24:27 -0000 @@ -50,13 +50,28 @@ private static final byte[] BREAKPOINT_INSTRUCTION = { (byte)0xcc }; - static class IA32Register extends Register + static class IA32Register + extends Register { IA32Register(String name, int wordOffset) { super(0, wordOffset * 4, 4, name); } } + + static class IA32SegmentRegister + extends IA32Register + { + IA32SegmentRegister(String name, int wordOffset) + { + super(name, wordOffset); + } + public int getLength() + { + return 2; + } + } + private static final IA32Register[] regDefs = { new IA32Register("eax", 6), new IA32Register("ebx", 0), @@ -65,12 +80,12 @@ new IA32Register("esi", 3), new IA32Register("edi", 4), new IA32Register("ebp", 5), - new IA32Register("cs", 13), - new IA32Register("ds", 7), - new IA32Register("es", 8), - new IA32Register("fs", 9), - new IA32Register("gs", 10), - new IA32Register("ss", 16), + new IA32SegmentRegister("cs", 13), + new IA32SegmentRegister("ds", 7), + new IA32SegmentRegister("es", 8), + new IA32SegmentRegister("fs", 9), + new IA32SegmentRegister("gs", 10), + new IA32SegmentRegister("ss", 16), new IA32Register("orig_eax", 11), new IA32Register("eip", 12), new IA32Register("efl", 14), -------------- next part -------------- Index: frysk-core/frysk/proc/TestI386Regs.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/TestI386Regs.java,v retrieving revision 1.38 diff -u -r1.38 TestI386Regs.java --- frysk-core/frysk/proc/TestI386Regs.java 7 Aug 2006 20:22:15 -0000 1.38 +++ frysk-core/frysk/proc/TestI386Regs.java 25 Aug 2006 07:43:50 -0000 @@ -61,6 +61,8 @@ long esp; long esi; long edi; + int csLength; + int ssLength; // Need to add task observers to the process the moment it is // created, otherwize the creation of the very first task is @@ -98,6 +100,8 @@ esi = isa.getRegisterByName ("esi").get (task); edi = isa.getRegisterByName ("edi").get (task); esp = isa.getRegisterByName ("esp").get (task); + csLength = isa.getRegisterByName ("cs").getLength(); + ssLength = isa.getRegisterByName ("ss").getLength(); } return Action.CONTINUE; } @@ -166,6 +170,8 @@ assertEquals ("esi register", 6, t.esi); assertEquals ("edi register", 7, t.edi); assertEquals ("esp register", 8, t.esp); + assertEquals ("cs length", 2, t.csLength); + assertEquals ("ss length", 2, t.ssLength); assertTrue ("exited", t.exited); } -------------- next part -------------- Index: frysk-core/frysk/proc/IsaEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaEMT64.java,v retrieving revision 1.3 diff -u -r1.3 IsaEMT64.java --- frysk-core/frysk/proc/IsaEMT64.java 23 Aug 2006 04:04:19 -0000 1.3 +++ frysk-core/frysk/proc/IsaEMT64.java 25 Aug 2006 07:47:33 -0000 @@ -57,6 +57,18 @@ super(0, wordOffset * 8, 8, name); } } + static class EMT64SegmentRegister extends EMT64Register + { + EMT64SegmentRegister (String name, int wordOffset) + { + super (name, wordOffset); + } + public int getLength() + { + return 4; + } + } + private static final EMT64Register[] regDefs = { new EMT64Register("rax", 10), new EMT64Register("rbx", 5), @@ -76,12 +88,12 @@ new EMT64Register("r15", 0), new EMT64Register("rip", 16), new EMT64Register("eflags", 18), - new EMT64Register("cs", 17), - new EMT64Register("ss", 20), - new EMT64Register("ds", 23), - new EMT64Register("es", 24), - new EMT64Register("fs", 25), - new EMT64Register("gs", 26), + new EMT64SegmentRegister("cs", 17), + new EMT64SegmentRegister("ss", 20), + new EMT64SegmentRegister("ds", 23), + new EMT64SegmentRegister("es", 24), + new EMT64SegmentRegister("fs", 25), + new EMT64SegmentRegister("gs", 26), new EMT64Register("orig_rax", 15), new EMT64Register("fs_base", 21), new EMT64Register("gs_base", 22) }; -------------- next part -------------- Index: frysk-core/frysk/proc/TestX8664Regs.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/TestX8664Regs.java,v retrieving revision 1.3 diff -u -r1.3 TestX8664Regs.java --- frysk-core/frysk/proc/TestX8664Regs.java 16 Aug 2006 10:58:50 -0000 1.3 +++ frysk-core/frysk/proc/TestX8664Regs.java 25 Aug 2006 07:48:34 -0000 @@ -62,6 +62,8 @@ // 0xdeadbeefdeadbeef -0x2152411021524111l }; + int csLength; + Hashtable longResults = new Hashtable(); Hashtable bigResults = new Hashtable(); @@ -114,6 +116,7 @@ } } + csLength = isa.getRegisterByName("cs").getLength(); return Action.CONTINUE; } } @@ -179,6 +182,7 @@ BigInteger.valueOf(regValues[i]) .compareTo((BigInteger)bigResults.get(regNames[i])) == 0); } + assertEquals ("cs length", 4, csLength); assertTrue ("exited", exited); } } -------------- next part -------------- Index: frysk-core/frysk/proc/IsaPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC64.java,v retrieving revision 1.3 diff -u -r1.3 IsaPPC64.java --- frysk-core/frysk/proc/IsaPPC64.java 23 Aug 2006 06:12:19 -0000 1.3 +++ frysk-core/frysk/proc/IsaPPC64.java 25 Aug 2006 07:54:18 -0000 @@ -18,6 +18,18 @@ super (0, wordOffset * 8, 8, name); } } + static class PPC6432BitRegister + extends PPC64Register + { + PPC6432BitRegister(String name, int wordOffset) + { + super (name, wordOffset); + } + public int getLength() + { + return 4; + } + } private static PPC64Register[] gprs() { @@ -36,8 +48,8 @@ private static final PPC64Register orig_r3 = new PPC64Register("orig_r3", 34); private static final PPC64Register ctr = new PPC64Register("ctr", 35); private static final PPC64Register lnk = new PPC64Register("lnk", 36); - private static final PPC64Register xer = new PPC64Register("xer", 37); - private static final PPC64Register ccr = new PPC64Register("ccr", 38); + private static final PPC64Register xer = new PPC6432BitRegister("xer", 37); + private static final PPC64Register ccr = new PPC6432BitRegister("ccr", 38); private static final PPC64Register mq = new PPC64Register("mq", 39); private static final PPC64Register trap = new PPC64Register("trap", 40); private static final PPC64Register dar = new PPC64Register("dar", 41); From mark@klomp.org Fri Aug 25 09:32:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 25 Aug 2006 09:32:00 -0000 Subject: frysk-core/frysk/proc ChangeLog TaskState.java In-Reply-To: <20060825015010.GA9037@GreenHouse.cn.ibm.com> References: <20060825015010.GA9037@GreenHouse.cn.ibm.com> Message-ID: <1156498305.3007.12.camel@dijkstra.wildebeest.org> On Fri, 2006-08-25 at 09:50 +0800, Yao Qi wrote: > > * TaskState.java: Added handleSignaledEvent to runningInSyscall > Could you explain why do you do this? I am confused by this a bit. > Do you mean the child will receive a signal when it is in syscall? > Is there any bugs opened before we apply this patch? I have the same questions as Yao has. Also note that currently runningInSyscall has the following comment at the top: // XXX: We needn't look for signal events because the // syscall will exit before we get the signal, however, we still. // need to look for terminating and terminated events // because an exit syscall will produce these events and // never produce a syscall-exit event. Which should be updated now since your patch does look for signal events now. Cheers, Mark From swagiaal@redhat.com Fri Aug 25 15:54:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Fri, 25 Aug 2006 15:54:00 -0000 Subject: frysk-core/frysk/proc ChangeLog TaskState.java In-Reply-To: <20060825015010.GA9037@GreenHouse.cn.ibm.com> References: <20060825015010.GA9037@GreenHouse.cn.ibm.com> Message-ID: <44EF1D27.3010800@redhat.com> Yao Qi wrote: >> Log message: >> 2006-08-24 >> > Hi, Sami, > The name in ChangeLog entry is lost, and I have add it for you. :) > Thanx... i must have forgotten to add the change log to the patch i applied :) >> >> * TaskState.java: Added handleSignaledEvent to runningInSyscall >> > Could you explain why do you do this? I am confused by this a bit. > Do you mean the child will receive a signal when it is in syscall? > Is there any bugs opened before we apply this patch? > The reason is that on RHEL4 we were getting this error with all the tests that used the system calls code. java.lang.RuntimeException: {frysk.proc.LinuxTask@4fa960,pid=10898,tid=10898,state=runningInSyscall} in state "runningInSyscall" did not handle handleSignaledEvent this is on the following kernel: + uname -a Linux hs20-bc2-3.build.redhat.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:56:28 EST 2006 i686 i686 i386 GNU/Linux I have not had a chance to reseach it more. I wanted to get the patch in for the release. The truth is even if it is some kind of kernel bug it is not likely to get fixed and we will have to handle it in the same way that the patch did :) I'll know more soon :) From kasal@ucw.cz Fri Aug 25 16:12:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Fri, 25 Aug 2006 16:12:00 -0000 Subject: frysk-gui/frysk/gui/monitor ConsoleWidget.java In-Reply-To: <20060824171122.12406.qmail@sourceware.org> References: <20060824171122.12406.qmail@sourceware.org> Message-ID: <20060825161210.GA22639@camelia.ucw.cz> Hello > 2006-08-24 Ivan Pantuyev > > * ConsoleWidget.java: new I noticed you forgot to add this to the changelog, and the new file had dos line endings; I fixed both. Stepan From mark@klomp.org Fri Aug 25 16:17:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 25 Aug 2006 16:17:00 -0000 Subject: New method to get real length of register In-Reply-To: <20060825080622.GH9037@GreenHouse.cn.ibm.com> References: <20060823100418.GA18719@GreenHouse.cn.ibm.com> <44ECB3C8.5070303@redhat.com> <20060824070643.GB19715@GreenHouse.cn.ibm.com> <44ED6A9C.6050905@redhat.com> <20060825080622.GH9037@GreenHouse.cn.ibm.com> Message-ID: <1156522650.3007.39.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-08-25 at 16:06 +0800, Yao Qi wrote: > Hi, Tim and Mark, > > Here are some new patches to do what we discussed in this thread. > > 2006-08-25 Yao Qi > > * IsaIA32.java: New class for 16-bit segment register on IA32. > * TestI386Regs.java: Test length of segment register. > > * IsaEMT64.java: New class for 32-bit segment registers on X86_64. > * TestX8664Regs.java: Test length of segment register. > > * IsaPPC64.java: New class for 32-bit registers on PPC64. > > Test them on X86/X86-64/PPC64. > OK to commit? Thanks! This approach looks very nice. Thanks. Seems fine to me. Cheers, Mark From cagney@redhat.com Sat Aug 26 17:54:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sat, 26 Aug 2006 17:54:00 -0000 Subject: Fedora Core 5 Test 3 Message-ID: <44F08B01.9020409@redhat.com> FYI, Ref: http://fedoraproject.org/wiki/Core/Schedule Test 3 of fedora core is freezing on September 5th so some of us are going to try to get Fedora's frysk rpm updated early this coming week (29th?). I'll be going through all those pending patches this weekend. Andrew From cagney@redhat.com Mon Aug 28 02:11:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 28 Aug 2006 02:11:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <1156132796.18109.13.camel@YZ_X86_64> References: <1155884638.7779.25.camel@YZ_X86_64> <44E5E21B.7080604@redhat.com> <1156132796.18109.13.camel@YZ_X86_64> Message-ID: <44F250BD.3040008@redhat.com> Yong Zheng wrote: > hi, > > According to Andrew's advice, we merge the following three testcases > (TestI386Regs.java, TestX8664Regs.java and TestPPC64Regs.java) into one > case: TestRegs.java. > > After merging the three cases, the files TestI386Regs.java, > TestX8664Regs.java and TestPPC64Regs.java can be removed from > frysk-core/frysk/proc/. > > If it's ok, we will post out the patch for merging TestI386Modify.java, > TestX8664Modify.java and TestPPC64Modify.java. > > Here is the patch for adding TestRegs.java. Rebuild frysk on > X86/X86-64/PPC64 based on the cvs head(08-18) and tested. please review. > > Much appreciate what you've done. Looking over the code I see you've inherited some older-nastier code. Rather than attempt to also fix that in parallel, can you check this in and then I'll sort out the old code's mess. sorry to not reply earlier, Andrew > On Fri, 2006-08-18 at 11:51 -0400, Andrew Cagney wrote: > >> Yong Zheng wrote: >> >>> hi, >>> >>> There's no any case for us to test register and memory modification in >>> PPC64 in frysk. So we write two cases for above purpose. During the >>> test, we found the PPC64's worksize(got from IsaPPC64.java) should be >>> 8bytes but not 4 bytes. Here is the patch to add PPC64 tests. >>> >>> 2006-08-18 Yong Zheng >>> >>> * frysk/proc/TestPPC64Regs.java: New file for PPC64 test >>> * frysk/proc/TestPPC64Modify.java: New file for PPC64 test >>> * frysk/pkglibexecdir/funit-ppc64-regs.S: New file for PPC64 >>> * frysk/pkglibexecdir/funit-ppc64-modify.S: Ditto >>> * frysk/Makefile.am: Add PPC64Regs/PPC64Modify tests >>> >>> * frysk/proc/IsaPPC64.java (getWordSize): Edit return value >>> from 4 to 8 >>> >>> >>> >> Rather than individual TestRegs.java files, I'd prefer to see a >> single TestRegs.java file that selects the applicable test and runs >> that, or fails if no test is implemented. >> >> Past experience tells us that, unless unimplemented is detected and >> treated as a FAIL, the tests won't get implemented - too easy to ignore. >> >> Andrew >> >> >> ------------------------------------------------------------------------ >> >> --- /dev/null 2006-08-18 19:25:03.428380000 +0800 >> +++ frysk-core/frysk/proc/TestRegs.java 2006-08-21 11:39:48.000000000 +0800 >> @@ -0,0 +1,467 @@ >> +// This file is part of the program FRYSK. >> +// >> +// Copyright 2005, 2006, Red Hat Inc. >> +// >> +// FRYSK is free software; you can redistribute it and/or modify it >> +// under the terms of the GNU General Public License as published by >> +// the Free Software Foundation; version 2 of the License. >> +// >> +// FRYSK is distributed in the hope that it will be useful, but >> +// WITHOUT ANY WARRANTY; without even the implied warranty of >> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> +// General Public License for more details. >> +// >> +// You should have received a copy of the GNU General Public License >> +// along with FRYSK; if not, write to the Free Software Foundation, >> +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. >> +// >> +// In addition, as a special exception, Red Hat, Inc. gives You the >> +// additional right to link the code of FRYSK with code not covered >> +// under the GNU General Public License ("Non-GPL Code") and to >> +// distribute linked combinations including the two, subject to the >> +// limitations in this paragraph. Non-GPL Code permitted under this >> +// exception must only link to the code of FRYSK through those well >> +// defined interfaces identified in the file named EXCEPTION found in >> +// the source code files (the "Approved Interfaces"). The files of >> +// Non-GPL Code may instantiate templates or use macros or inline >> +// functions from the Approved Interfaces without causing the >> +// resulting work to be covered by the GNU General Public >> +// License. Only Red Hat, Inc. may make changes or additions to the >> +// list of Approved Interfaces. You must obey the GNU General Public >> +// License in all respects for all of the FRYSK code and other code >> +// used in conjunction with FRYSK except the Non-GPL Code covered by >> +// this exception. If you modify this file, you may extend this >> +// exception to your version of the file, but you are not obligated to >> +// do so. If you do not wish to provide this exception without >> +// modification, you must delete this exception statement from your >> +// version and license this file solely under the GPL without >> +// exception. >> + >> +package frysk.proc; >> + >> +import java.math.BigInteger; >> +import java.util.Hashtable; >> +import java.util.Observable; >> + >> +import frysk.sys.SyscallNum; >> + >> +/** >> + * Check that registers can be accessed. >> + */ >> + >> +public class TestRegs >> + extends SyscallExaminer >> +{ >> + class TestI386RegsInternals extends SyscallExaminer.Tester >> + { >> + boolean ia32Isa; >> + int syscallNum; >> + long orig_eax; >> + long ebx; >> + long ecx; >> + long edx; >> + long ebp; >> + long esp; >> + long esi; >> + long edi; >> + >> + // Need to add task observers to the process the moment it is >> + // created, otherwize the creation of the very first task is >> + // missed (giving a mismatch of task created and deleted >> + // notifications.) >> + >> + class I386TaskEventObserver >> + extends SyscallExaminer.Tester.TaskEventObserver >> + { >> + public Action updateSyscallEnter (Task task) >> + { >> + super.updateSyscallEnter(task); >> + SyscallEventInfo syscall; >> + LinuxIa32 isa; >> + try >> + { >> + syscall = task.getSyscallEventInfo (); >> + isa = (LinuxIa32)task.getIsa (); >> + } >> + catch (TaskException e) >> + { >> + fail("got task exception " + e); >> + return Action.CONTINUE; // not reached >> + } >> + // The low-level assembler code performs an exit syscall >> + // and sets up the registers with simple values. We want >> + // to verify that all the registers are as expected. >> + syscallNum = syscall.number (task); >> + if (syscallNum == 1) { >> + orig_eax = isa.getRegisterByName ("orig_eax").get (task); >> + ebx = isa.getRegisterByName ("ebx").get (task); >> + ecx = isa.getRegisterByName ("ecx").get (task); >> + edx = isa.getRegisterByName ("edx").get (task); >> + ebp = isa.getRegisterByName ("ebp").get (task); >> + esi = isa.getRegisterByName ("esi").get (task); >> + edi = isa.getRegisterByName ("edi").get (task); >> + esp = isa.getRegisterByName ("esp").get (task); >> + } >> + return Action.CONTINUE; >> + } >> + } >> + >> + class I386RegsTestObserver >> + extends SyscallExaminer.TaskAddedObserver >> + { >> + public void update(Observable o, Object obj) >> + { >> + super.update(o, obj); >> + Task task = (Task)obj; >> + if (!isChildOfMine(task.proc)) >> + return; >> + I386TaskEventObserver taskEventObserver = new I386TaskEventObserver(); >> + Isa isa; >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (TaskException e) >> + { >> + isa = null; >> + } >> + if (isa instanceof LinuxIa32) >> + { >> + ia32Isa = true; >> + task.requestAddSyscallObserver(taskEventObserver); >> + task.requestAddSignaledObserver(taskEventObserver); >> + } >> + else >> + { >> + // If not ia32, stop immediately >> + ia32Isa = false; >> + Manager.eventLoop.requestStop(); >> + } >> + } >> + } >> + >> + TestI386RegsInternals () >> + { >> + super(); >> + addTaskAddedObserver(new I386RegsTestObserver()); >> + } >> + } >> + >> + class TestX8664RegsInternals extends SyscallExaminer.Tester >> + { >> + boolean EMT64Isa; >> + int syscallNum; >> + String[] regNames >> + = new String[] { "orig_rax", "rdi", "rsi", "rdx", "r10", "r8", "r9"}; >> + long[] regValues >> + = new long[] >> + { 1, 2, 3, -4, 0xdeadbeefl, 0xfeeddeadbeefl, >> + // 0xdeadbeefdeadbeef >> + -0x2152411021524111l >> + }; >> + Hashtable longResults = new Hashtable(); >> + Hashtable bigResults = new Hashtable(); >> + >> + // Need to add task observers to the process the moment it is >> + // created, otherwize the creation of the very first task is >> + // missed (giving a mismatch of task created and deleted >> + // notifications.) >> + >> + class X8664TaskEventObserver >> + extends SyscallExaminer.Tester.TaskEventObserver >> + { >> + >> + } >> + >> + class LongTaskEventObserver >> + extends X8664TaskEventObserver >> + { >> + public Action updateSyscallEnter (Task task) >> + { >> + super.updateSyscallEnter(task); >> + SyscallEventInfo syscall; >> + LinuxEMT64 isa; >> + try >> + { >> + syscall = task.getSyscallEventInfo (); >> + isa = (LinuxEMT64)task.getIsa (); >> + } >> + catch (TaskException e) >> + { >> + fail("got task exception " + e); >> + return Action.CONTINUE; // not reached >> + } >> + // The low-level assembler code performs an exit syscall >> + // and sets up the registers with simple values. We want >> + // to verify that all the registers are as expected. >> + syscallNum = syscall.number (task); >> + if (syscallNum == 1) >> + { >> + for (int i = 0; i < regNames.length; i++) >> + { >> + longResults.put(regNames[i], >> + new Long(isa.getRegisterByName(regNames[i]) >> + .get (task))); >> + } >> + for (int i = 0; i < regNames.length; i++) >> + { >> + bigResults.put(regNames[i], >> + isa.getRegisterByName(regNames[i]) >> + .getBigInteger(task)); >> + } >> + >> + } >> + return Action.CONTINUE; >> + } >> + } >> + >> + class X8664RegsTestObserver >> + extends SyscallExaminer.TaskAddedObserver >> + { >> + private X8664TaskEventObserver taskEventObserver; >> + >> + X8664RegsTestObserver(X8664TaskEventObserver teo) >> + { >> + super(); >> + taskEventObserver = teo; >> + } >> + >> + public void update(Observable o, Object obj) >> + { >> + super.update(o, obj); >> + Task task = (Task)obj; >> + if (!isChildOfMine(task.proc)) >> + return; >> + Isa isa; >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (TaskException e) >> + { >> + isa = null; >> + } >> + if (isa instanceof LinuxEMT64) >> + { >> + EMT64Isa = true; >> + task.requestAddSyscallObserver(taskEventObserver); >> + task.requestAddSignaledObserver(taskEventObserver); >> + } >> + else >> + { >> + // If not ia32, stop immediately >> + EMT64Isa = false; >> + Manager.eventLoop.requestStop(); >> + } >> + } >> + } >> + >> + TestX8664RegsInternals () >> + { >> + super(); >> + addTaskAddedObserver(new X8664RegsTestObserver(new LongTaskEventObserver())); >> + } >> + >> + void verify() >> + { >> + for (int i = 0; i < regNames.length; i++) >> + { >> + assertEquals(regNames[i] + " long value", >> + regValues[i], >> + ((Long)longResults.get(regNames[i])).longValue()); >> + } >> + for (int i = 0; i < regNames.length; i++) >> + { >> + assertTrue(regNames[i] + " BigInteger value", >> + BigInteger.valueOf(regValues[i]) >> + .compareTo((BigInteger)bigResults.get(regNames[i])) == 0); >> + } >> + assertTrue ("exited", exited); >> + } >> + } >> + >> + class TestPPC64RegsInternals extends SyscallExaminer.Tester >> + { >> + long gpr0; >> + long gpr3; >> + long gpr4; >> + long gpr5; >> + >> + int syscallNum; >> + boolean isPPC64Isa; >> + >> + // Need to add task observers to the process the moment it is >> + // created, otherwize the creation of the very first task is >> + // missed (giving a mismatch of task created and deleted >> + // notifications.) >> + >> + class PPC64TaskEventObserver >> + extends SyscallExaminer.Tester.TaskEventObserver >> + { >> + public Action updateSyscallEnter (Task task) >> + { >> + LinuxPPC64 isaPPC64; >> + SyscallEventInfo syscall; >> + >> + logger.entering("TestPPC64Regs.TaskEventObserver", >> + "updateSyscallEnter"); >> + super.updateSyscallEnter(task); >> + >> + try >> + { >> + syscall = task.getSyscallEventInfo (); >> + isaPPC64 = (LinuxPPC64)task.getIsa (); >> + } >> + catch (TaskException e) >> + { >> + fail("got task exception " + e); >> + return Action.CONTINUE; // not reached >> + } >> + >> + // The low-level assembler code performs an exit syscall >> + // and sets up the registers with simple values. We want >> + // to verify that all the registers are as expected. >> + syscallNum = syscall.number (task); >> + >> + if (syscallNum == SyscallNum.SYSexit) >> + { >> + gpr0 = isaPPC64.getRegisterByName ("gpr0").get (task); >> + gpr3 = isaPPC64.getRegisterByName ("gpr3").get (task); >> + gpr4 = isaPPC64.getRegisterByName ("gpr4").get (task); >> + gpr5 = isaPPC64.getRegisterByName ("gpr5").get (task); >> + } >> + >> + return Action.CONTINUE; >> + } >> + } >> + >> + class PPC64RegsTestObserver >> + extends SyscallExaminer.TaskAddedObserver >> + { >> + public void update(Observable o, Object obj) >> + { >> + super.update(o, obj); >> + Task task = (Task)obj; >> + >> + if (!isChildOfMine(task.proc)) >> + return; >> + >> + Isa isa; >> + PPC64TaskEventObserver taskEventObserver = new PPC64TaskEventObserver(); >> + >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (TaskException e) >> + { >> + isa = null; >> + } >> + >> + if (isa instanceof LinuxPPC64) >> + { >> + isPPC64Isa = true; >> + task.requestAddSyscallObserver(taskEventObserver); >> + task.requestAddSignaledObserver(taskEventObserver); >> + } >> + else >> + { >> + //If not PPC64, stop immediately >> + isPPC64Isa = false; >> + Manager.eventLoop.requestStop(); >> + } >> + } >> + } >> + >> + TestPPC64RegsInternals () >> + { >> + super(); >> + addTaskAddedObserver(new PPC64RegsTestObserver()); >> + } >> + } >> + >> + private void checkI386Regs () >> + { >> + if (MachineType.getMachineType() != MachineType.IA32) >> + return; >> + TestI386RegsInternals t = new TestI386RegsInternals (); >> + // Create program making an exit syscall"); >> + new AttachedDaemonProcess (new String[] >> + { >> + getExecPrefix () + "funit-ia32-regs" >> + }).resume (); >> + assertRunUntilStop ("run \"x86regs\" until exit"); >> + >> + if (t.ia32Isa) { >> + assertEquals ("orig_eax register", 1, t.orig_eax); >> + assertEquals ("ebx register", 2, t.ebx); >> + assertEquals ("ecx register", 3, t.ecx); >> + assertEquals ("edx register", 4, t.edx); >> + assertEquals ("ebp register", 5, t.ebp); >> + assertEquals ("esi register", 6, t.esi); >> + assertEquals ("edi register", 7, t.edi); >> + assertEquals ("esp register", 8, t.esp); >> + >> + assertTrue ("exited", t.exited); >> + } >> + } >> + >> + private void checkX8664Regs () >> + { >> + if (MachineType.getMachineType() != MachineType.X8664) >> + return; >> + TestX8664RegsInternals t = new TestX8664RegsInternals(); >> + // Create program making an exit syscall"); >> + AttachedDaemonProcess child = new AttachedDaemonProcess (new String[] >> + { >> + getExecPrefix () + "funit-x8664-regs" >> + }); >> + logger.finest("About to resume funit-x8664-regs"); >> + child.resume(); >> + assertRunUntilStop ("run \"x86regs\" until exit"); >> + if (t.EMT64Isa) >> + { >> + t.verify(); >> + } >> + } >> + >> + private void checkPPC64Regs () >> + { >> + if (MachineType.getMachineType() != MachineType.PPC64) >> + return; >> + >> + TestPPC64RegsInternals t = new TestPPC64RegsInternals(); >> + // Create program making an exit syscall"); >> + AttachedDaemonProcess child = new AttachedDaemonProcess (new String[] >> + { >> + getExecPrefix () + "funit-ppc64-regs" >> + }); >> + logger.finest("About to resume funit-ppc64-regs"); >> + child.resume(); >> + assertRunUntilStop ("run \"ppc64regs\" until exit"); >> + >> + if (t.isPPC64Isa) >> + { >> + assertEquals ("syscall", SyscallNum.SYSexit, t.syscallNum); >> + assertEquals ("gpr0 register", 1, t.gpr0); >> + assertEquals ("gpr3 register", 1, t.gpr3); >> + assertEquals ("gpr4 register", 4, t.gpr4); >> + // Left shift 36bits from 0x1 >> + assertEquals ("gpr5 register", 0x1000000000L, t.gpr5); >> + >> + assertTrue ("exited", t.exited); >> + } >> + } >> + >> + public void testRegs() >> + { >> + if (MachineType.getMachineType() == MachineType.IA32) >> + checkI386Regs(); >> + else if (MachineType.getMachineType() == MachineType.X8664) >> + checkX8664Regs(); >> + else if (MachineType.getMachineType() == MachineType.PPC64) >> + checkPPC64Regs(); >> + else >> + throw new UnsupportedOperationException(MachineType.getMachineType() + " is not supported now."); >> + } >> +} >> From cagney@redhat.com Mon Aug 28 02:24:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 28 Aug 2006 02:24:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <44EDBD32.3090608@cn.ibm.com> References: <1156413940.2172.63.camel@YZ_X86_64> <1156419492.2172.87.camel@YZ_X86_64> <44EDBD32.3090608@cn.ibm.com> Message-ID: <44F253CA.80701@redhat.com> Wu Zhou wrote: > Yong Zheng wrote: >> hi, >> >> The followings are some difference between the test results of cases in >> 64-bit mode and in 32-bit mode on 64-bit frysk. >> >> All tests are based on the cvs head(08-24). >> >> On X86_64, the following cases fail in 32-bit mode but pass in 64-bit >> mode on 64-bit frysk: >> >> 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: unknown >> word size for auxv (1|32l|64l|32b|64b 10000) >> at frysk.sys.proc.AuxvBuilder.construct(TestRunner) > > on ppc64, testGetAuxv fails in 32-bit testcase because there are three > AT_NULL at the end of aux vectors, which might be actually ok (because > I don't see any nagative impact it can bring up). I don't know what is > the situation in x86_64. This is interesting, the lower level frysk-sys/frysk/sys/proc/TestAuxv.java contains: /** * Check that an AUXV taken from a 32-bit PowerPC program running * on a 64-bit PowerPC machine (PPC970, altivec supported) can be * parsed. */ so it is attempting to test the case you describe, or at least based on the AUXV I extracted from an older kernel. You're saying that the tail end of the AUXV is now different? If it is then perhaps that lower level test should be augmented to also include the AUXV buffer that you're seeing. Andrew From cagney@redhat.com Mon Aug 28 02:34:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 28 Aug 2006 02:34:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <1156413940.2172.63.camel@YZ_X86_64> References: <1156413940.2172.63.camel@YZ_X86_64> Message-ID: <44F2561C.9090809@redhat.com> Hi Yong, Since the intent is to fully support 32 bit debugging on 64-bit, I think we need to find a more robust and consistent way to always run these (or at least a specific set of) tests. Perhaps consider it at two levels: - testing 32- x 64-bit features For instance: a 32-bit program exec-ing a 64-bit program and vice-versa; 32-bit registers read correctly when 64-bit frysk; ... - generic testing as either 32- or 64- bit This is less focused but what the below does. Unless it is going to be fully integrated and installed, I'm not sure how useful it is when compared to better focused tests. However, looking at a way to get funit (the installed JUnit TestRunner) to be able to do this might be useful. Andrew Yong Zheng wrote: > hi, > > On PPC64, all applications are compiled into 32-bit mode by default if > the compiling option "-m64" isn't explicitly given, which means most > applications running on PPC64 are in 32-bit mode. So it's necessary for > 64-bit frysk to debug 32-bit applications on PPC64. > > Currently, funit(in frysk-core/frysk/pkglibexecdir/) should be build in > 64-bit mode, since it is dependent on other 64-bit frysk libraries, such > as libfrysk-core.a. In order to build other test cases in 32-bit mode > without breaking the 64-bit funit, one rule in Makefile.am is added. > That is to say, we remove all existent test cases(64-bit) except funit, > and rebuild them in 32-bit mode. All these 32-bit test cases could be > run via TestRunner. > > On X86_64, although applications are compiled in 64-bit mode by default, > it's also necessary to do bi-arch test. The modifications will be > useful to 64-bit frysk on X86_64. > > Among the frysk's five main sub-directories, frysk-gtk, frsyk-gui, > frysk-import and frysk-sys needn't do the bi-arch tests for their less > arch-dependence. So no rules are added for them. If someone thinks it's > also necessary, we'd like to add rules for them. > > Please review, and any comments are welcome! > Thanks! > > 2006-08-24 Yong Zheng > > * frysk-core/Makefile.am: Add support for compiling 32bit > testcases. > > > Best regards > Yong Zheng > > > ------------------------------------------------------------------------ > > Index: frysk-core/Makefile.am > =================================================================== > RCS file: /cvs/frysk/frysk-core/Makefile.am,v > retrieving revision 1.61 > diff -u -r1.61 Makefile.am > --- frysk-core/Makefile.am 17 Aug 2006 01:54:27 -0000 1.61 > +++ frysk-core/Makefile.am 24 Aug 2006 07:24:18 -0000 > @@ -120,3 +120,7 @@ > .PHONY: installcheck-funit > installcheck-funit: > $(DESTDIR)$(pkglibexecdir)/funit > + > +64test32: > + -rm -fr frysk/pkglibexecdir/funit-* > + $(MAKE) $(pkglibexec_PROGRAMS) CC="gcc -m32" CCAS="gcc -m32" CXX="g++ -m32" > From woodzltc@cn.ibm.com Mon Aug 28 06:00:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 28 Aug 2006 06:00:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <44F253CA.80701@redhat.com> References: <1156413940.2172.63.camel@YZ_X86_64> <1156419492.2172.87.camel@YZ_X86_64> <44EDBD32.3090608@cn.ibm.com> <44F253CA.80701@redhat.com> Message-ID: <44F28641.40007@cn.ibm.com> Andrew, I have a check on x86_64, this is what I see on x86_64 when issuing "info auxv" on 32-bit program: 32 AT_SYSINFO Special system info/entry points 0xffffe400^M 33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0xffffe000^M 16 AT_HWCAP Machine-dependent CPU capability hints 0xbfebfbff^M 6 AT_PAGESZ System page size 4096^M 17 AT_CLKTCK Frequency of times() 100^M 3 AT_PHDR Program headers for program 0x8048034^M 4 AT_PHENT Size of program header entry 32^M 5 AT_PHNUM Number of program headers 7^M 7 AT_BASE Base address of interpreter 0x0^M 8 AT_FLAGS Flags 0x0^M 9 AT_ENTRY Entry point of program 0x80482f0^M 11 AT_UID Real user ID 0^M 12 AT_EUID Effective user ID 0^M 13 AT_GID Real group ID 0^M 14 AT_EGID Effective group ID 0^M 23 AT_SECURE Boolean, was exec setuid-like? 0^M 15 AT_PLATFORM String identifying platform 0xffffcceb "i686"^M 0 AT_NULL End of vector 0x0^M 0 AT_NULL End of vector 0x0^M 0 AT_NULL End of vector 0x0^M Please note that there are three AT_NULL at the end. This is the same as what I saw on ppc64 for 32-bit program. This patch can fix that. OK for commit? 2006-08-28 Wu Zhou * cni/AuxvBuilder.cxx (verify): There might be multiple AT_NULL at the end of auxv vector. --- proc/cni/AuxvBuilder.cxx.orig 2006-08-28 13:48:53.000000000 +0800 +++ proc/cni/AuxvBuilder.cxx 2006-08-28 13:49:13.000000000 +0800 @@ -110,9 +110,6 @@ // Reasonable value? if (type > 1024 || type < 0) return false; - // AT_NULL value only at end of buffer? - if (type == 0 && i + 2 * wordSize < buf->length) - return false; } return true; } Andrew Cagney wrote: > Wu Zhou wrote: >> Yong Zheng wrote: >>> hi, >>> >>> The followings are some difference between the test results of cases in >>> 64-bit mode and in 32-bit mode on 64-bit frysk. >>> >>> All tests are based on the cvs head(08-24). >>> >>> On X86_64, the following cases fail in 32-bit mode but pass in 64-bit >>> mode on 64-bit frysk: >>> >>> 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: unknown >>> word size for auxv (1|32l|64l|32b|64b 10000) >>> at frysk.sys.proc.AuxvBuilder.construct(TestRunner) >> >> on ppc64, testGetAuxv fails in 32-bit testcase because there are three >> AT_NULL at the end of aux vectors, which might be actually ok (because >> I don't see any nagative impact it can bring up). I don't know what is >> the situation in x86_64. > > This is interesting, the lower level > frysk-sys/frysk/sys/proc/TestAuxv.java contains: > > /** > * Check that an AUXV taken from a 32-bit PowerPC program running > * on a 64-bit PowerPC machine (PPC970, altivec supported) can be > * parsed. > */ > > so it is attempting to test the case you describe, or at least based on > the AUXV I extracted from an older kernel. You're saying that the tail > end of the AUXV is now different? If it is then perhaps that lower > level test should be augmented to also include the AUXV buffer that > you're seeing. We are on the latest FC5 kernels. So I guess this need to go into the lower level frysk-sys testcase too. But I don't know how to generate the "byte" array in routine "check". If you can tell me how, I can code a patch for that. Regards - Wu Zhou From woodzltc@cn.ibm.com Mon Aug 28 06:43:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 28 Aug 2006 06:43:00 -0000 Subject: Test result of utrace on PPC64(based on Fedoracore 6 Test 2 release). In-Reply-To: <20060822053004.9FDFF180064@magilla.sf.frob.com> References: <20060822053004.9FDFF180064@magilla.sf.frob.com> Message-ID: <44F29060.1020700@cn.ibm.com> Roland McGrath wrote: > Please try applying this patch to your gdb source. This is in my gdb tree > and I think it was to fix a latent testsuite bug I found. If it helps for > you, I'll make sure to get it in upstream. I applied your patch. This can fix one FAIL in gdb/auxv.exp when running in 32-bit mode, no matter that the kernel be ptrace or utrace. But the extra error (matching auxv data from live and gcore) of auxv.exp have no relation with this. The root cause is that the output of "info auxv" on gcore have one line different than that of live code: 15 AT_PLATFORM String identifying platform 0xfa61fa89
which should be: 15 AT_PLATFORM String identifying platform 0xff9e54a5 "power5+" > Also make sure you do "ulimit -c unlimited" before all test runs. > Some of the diffs look like one of the runs did not have that done. For 32-bit testcase, we did do that. A few failure on 64-bit testcase is attributed to not running "ulimit -c unlimited" before the testcase. > Please try using the most current rawhide kernel you can get. We had another run with kernel 2.6.17-1.2583.fc6. It is mostly the same, in fact, a few more regression in failing cases. Don't do any more analysis yet. We will try the test a few days later to see what will happen. Regards - Wu Zhou > > > Thanks, > Roland > > > --- testsuite/gdb.base/auxv.exp 24 Jul 2006 14:20:50 -0000 1.6 > +++ testsuite/gdb.base/auxv.exp 22 Aug 2006 05:25:37 -0000 > @@ -81,6 +81,7 @@ proc fetch_auxv {test} { > global gdb_prompt > > set auxv_lines {} > + set seen_null 0 > set bad -1 > if {[gdb_test_multiple "info auxv" $test { > -re "info auxv\[\r\n\]+" { > @@ -99,7 +100,15 @@ proc fetch_auxv {test} { > exp_continue > } > -re "^\[0-9\]+\[ \t\]+(AT_\[^ \t\]+)\[^\r\n\]+\[\r\n\]+" { > + if {$expect_out(1,string) == "AT_NULL"} { > + # We can ignore multiple terminators. > + set seen_null 1 > + } elseif {$seen_null} { > + warning "Element after AT_NULL: $expect_out(0,string)" > + set bad 1 > + } else { > lappend auxv_lines $expect_out(0,string) > + } > exp_continue > } > -re "^\[0-9\]+\[ \t\]+\\?\\?\\?\[^\r\n\]+\[\r\n\]+" { > @@ -122,6 +131,11 @@ proc fetch_auxv {test} { > return {} > } > > + if {!$seen_null} { > + warning "No AT_NULL terminator element" > + set bad 1 > + } > + > if {$bad} { > fail $test > return {} From woodzltc@cn.ibm.com Mon Aug 28 07:18:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 28 Aug 2006 07:18:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <44F2561C.9090809@redhat.com> References: <1156413940.2172.63.camel@YZ_X86_64> <44F2561C.9090809@redhat.com> Message-ID: <44F298B0.8080404@cn.ibm.com> Andrew Cagney wrote: > Hi Yong, > Since the intent is to fully support 32 bit debugging on 64-bit, I think > we need to find a more robust and consistent way to always run these (or > at least a specific set of) tests. Perhaps consider it at two levels: Yes. This is our thought too. > - testing 32- x 64-bit features > For instance: a 32-bit program exec-ing a 64-bit program and vice-versa; > 32-bit registers read correctly when 64-bit frysk; ... New testcases are needed to do these. We are adding a testcase for 64-bit Frysk to read/write 32-bit registers on ppc64. > - generic testing as either 32- or 64- bit > This is less focused but what the below does. Unless it is going to be > fully integrated and installed, I'm not sure how useful it is when > compared to better focused tests. However, looking at a way to get > funit (the installed JUnit TestRunner) to be able to do this might be > useful. We would like it to be fully integrated and installed into Frysk's code base. But we are not sure wihch way to take. Can you give us some more detail about how we can get funit to do this? We don't have much understanding about how TestRunner, funit, funit-* interact. Specifically I don't know what role funit plays in this game. (I can dive into the code, but it will save us some time if you can give a big picture first. :-) Regards - Wu Zhou > Yong Zheng wrote: >> hi, >> >> On PPC64, all applications are compiled into 32-bit mode by default if >> the compiling option "-m64" isn't explicitly given, which means most >> applications running on PPC64 are in 32-bit mode. So it's necessary for >> 64-bit frysk to debug 32-bit applications on PPC64. >> Currently, funit(in frysk-core/frysk/pkglibexecdir/) should be build in >> 64-bit mode, since it is dependent on other 64-bit frysk libraries, such >> as libfrysk-core.a. In order to build other test cases in 32-bit mode >> without breaking the 64-bit funit, one rule in Makefile.am is added. >> That is to say, we remove all existent test cases(64-bit) except funit, >> and rebuild them in 32-bit mode. All these 32-bit test cases could be >> run via TestRunner. >> >> On X86_64, although applications are compiled in 64-bit mode by default, >> it's also necessary to do bi-arch test. The modifications will be >> useful to 64-bit frysk on X86_64. >> >> Among the frysk's five main sub-directories, frysk-gtk, frsyk-gui, >> frysk-import and frysk-sys needn't do the bi-arch tests for their less >> arch-dependence. So no rules are added for them. If someone thinks it's >> also necessary, we'd like to add rules for them. >> >> Please review, and any comments are welcome! >> Thanks! >> >> 2006-08-24 Yong Zheng >> >> * frysk-core/Makefile.am: Add support for compiling 32bit >> testcases. >> >> >> Best regards >> Yong Zheng >> >> >> ------------------------------------------------------------------------ >> >> Index: frysk-core/Makefile.am >> =================================================================== >> RCS file: /cvs/frysk/frysk-core/Makefile.am,v >> retrieving revision 1.61 >> diff -u -r1.61 Makefile.am >> --- frysk-core/Makefile.am 17 Aug 2006 01:54:27 -0000 1.61 >> +++ frysk-core/Makefile.am 24 Aug 2006 07:24:18 -0000 >> @@ -120,3 +120,7 @@ >> .PHONY: installcheck-funit >> installcheck-funit: >> $(DESTDIR)$(pkglibexecdir)/funit >> + >> +64test32: >> + -rm -fr frysk/pkglibexecdir/funit-* >> + $(MAKE) $(pkglibexec_PROGRAMS) CC="gcc -m32" CCAS="gcc -m32" >> CXX="g++ -m32" >> > From woodzltc@cn.ibm.com Mon Aug 28 07:25:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 28 Aug 2006 07:25:00 -0000 Subject: Fedora Core 6 Test 3 In-Reply-To: <44F08B01.9020409@redhat.com> References: <44F08B01.9020409@redhat.com> Message-ID: <44F29A36.2010009@cn.ibm.com> I see that the GA date of FC6 is at the beginning of October. Could it be possible to ship frysk in FC6 for PPC/PPC64? To achieve this, we had some 64-bit libraries issue, GUI blank problem (maybe a little more) to resolve. But I guess the time frame is ok for us. Regards - Wu Zhou Andrew Cagney wrote: > FYI, > Ref: http://fedoraproject.org/wiki/Core/Schedule > Test 3 of fedora core is freezing on September 5th so some of us are > going to try to get Fedora's frysk rpm updated early this coming week > (29th?). > > I'll be going through all those pending patches this weekend. > > Andrew > From mark@klomp.org Mon Aug 28 09:12:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 28 Aug 2006 09:12:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <44F298B0.8080404@cn.ibm.com> References: <1156413940.2172.63.camel@YZ_X86_64> <44F2561C.9090809@redhat.com> <44F298B0.8080404@cn.ibm.com> Message-ID: <1156756269.3203.2.camel@dijkstra.wildebeest.org> On Mon, 2006-08-28 at 15:18 +0800, Wu Zhou wrote: > We would like it to be fully integrated and installed into Frysk's > code base. But we are not sure wihch way to take. Can you give us > some more detail about how we can get funit to do this? We > don't have much understanding about how TestRunner, funit, funit-* > interact. Specifically I don't know what role funit plays in this > game. (I can dive into the code, but it will save us some time if > you can give a big picture first. :-) The main difference between TestRunner and funit is that TestRunner will always use the tests from your current build, and funit will always use the installed tests. So you use TestRunner while developing and you use funit when frysk is installed. Cheers, Mark From qiyaoltc@cn.ibm.com Mon Aug 28 11:18:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 28 Aug 2006 11:18:00 -0000 Subject: get syscall num in updateSyscallExit Message-ID: <20060828111023.GA31608@GreenHouse.cn.ibm.com> Some of test cases get syscall num in updateSyscallExit by means of syscallEventInfo.number (task), but it seems that it is not right all the time. We find that we fail to get syscall number when EXIT rt_sigreturn and sigreturn on x86/x86-64/ppc64. On x86 and x86-64, the syscall number got when exit rt_sigreturn is -1. I am not sure it is the kernel problem or not. Any comments on this? Thanks! -- Yao Qi From zhengyo@cn.ibm.com Mon Aug 28 12:04:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Mon, 28 Aug 2006 12:04:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <44F250BD.3040008@redhat.com> References: <1155884638.7779.25.camel@YZ_X86_64> <44E5E21B.7080604@redhat.com> <1156132796.18109.13.camel@YZ_X86_64> <44F250BD.3040008@redhat.com> Message-ID: <1156766314.25356.11.camel@YZ_X86_64> On Sun, 2006-08-27 at 22:11 -0400, Andrew Cagney wrote: > Looking over the code I see you've inherited some older-nastier code. > Rather than attempt to also fix that in parallel, can you check this in > and then I'll sort out the old code's mess. During the new test on the patch based on the cvs head(08-28), we found one nasty bug on TestX8664Regs case. We have opened the bug(#3141): http://sourceware.org/bugzilla/show_bug.cgi?id=3141. Although the failed cases all pass after we do some modification on TestX8664Regs.java(the modificated TestX8664Regs.java can be got from the #1 reply in the above bug page), we are not sure the modification is proper or not. So we block the merging process. After the #3141 bug is fixed or the above modification is approved, we are very willing to resume it. Thanks. Best Regards Yong Zheng From ezannoni@redhat.com Mon Aug 28 12:38:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Mon, 28 Aug 2006 12:38:00 -0000 Subject: Fedora Core 6 Test 3 In-Reply-To: <44F29A36.2010009@cn.ibm.com> References: <44F08B01.9020409@redhat.com> <44F29A36.2010009@cn.ibm.com> Message-ID: <17650.57983.992139.940257@localhost.redhat.com> Yes we wanted to enable ppc, and were also wondering about the gtk bug. I saw no comments on the bug from the gtk community. Do you know what's going on there? thanks elena Wu Zhou writes: > I see that the GA date of FC6 is at the beginning of October. Could it be possible to ship frysk in > FC6 for PPC/PPC64? > > To achieve this, we had some 64-bit libraries issue, GUI blank problem (maybe a little more) to > resolve. But I guess the time frame is ok for us. > > Regards > - Wu Zhou > > Andrew Cagney wrote: > > FYI, > > Ref: http://fedoraproject.org/wiki/Core/Schedule > > Test 3 of fedora core is freezing on September 5th so some of us are > > going to try to get Fedora's frysk rpm updated early this coming week > > (29th?). > > > > I'll be going through all those pending patches this weekend. > > > > Andrew > > From cagney@redhat.com Mon Aug 28 13:11:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 28 Aug 2006 13:11:00 -0000 Subject: one frysk-core patch to add PPC64 testcases. In-Reply-To: <1156766314.25356.11.camel@YZ_X86_64> References: <1155884638.7779.25.camel@YZ_X86_64> <44E5E21B.7080604@redhat.com> <1156132796.18109.13.camel@YZ_X86_64> <44F250BD.3040008@redhat.com> <1156766314.25356.11.camel@YZ_X86_64> Message-ID: <44F2EB6F.4000207@redhat.com> Yong, so TestX8664 is failing. Can you modify your patch so that, for the x86-64 case, it does the brokenXXX() thing (but do include the merged code), and then check it in? Andrew Yong Zheng wrote: > On Sun, 2006-08-27 at 22:11 -0400, Andrew Cagney wrote: > > >> Looking over the code I see you've inherited some older-nastier code. >> Rather than attempt to also fix that in parallel, can you check this in >> and then I'll sort out the old code's mess. >> > During the new test on the patch based on the cvs head(08-28), we found > one nasty bug on TestX8664Regs case. We have opened the bug(#3141): > http://sourceware.org/bugzilla/show_bug.cgi?id=3141. > > Although the failed cases all pass after we do some modification on > TestX8664Regs.java(the modificated TestX8664Regs.java can be got from > the #1 reply in the above bug page), we are not sure the modification is > proper or not. So we block the merging process. After the #3141 bug is > fixed or the above modification is approved, we are very willing to > resume it. Thanks. > > Best Regards > Yong Zheng > > > From cagney@redhat.com Mon Aug 28 13:24:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 28 Aug 2006 13:24:00 -0000 Subject: bi-arch test patch for 64-bit frysk In-Reply-To: <44F28641.40007@cn.ibm.com> References: <1156413940.2172.63.camel@YZ_X86_64> <1156419492.2172.87.camel@YZ_X86_64> <44EDBD32.3090608@cn.ibm.com> <44F253CA.80701@redhat.com> <44F28641.40007@cn.ibm.com> Message-ID: <44F2EE74.8050107@redhat.com> Wu, Is this problem transient, or permanent? Its cases like this where adding a test, or test driven development, becomes critical. Can you do the following: - modify TestAuxv to include a new test that contains the Auxv buffer that you've seen; be sure to check that the test fails - add your patch - check that the failing test now passes (and none of the others now fail) The removed code should also be replaced with a comment explaining why a AT_NULL test can't be used (with, if needed reference to specific kernel versions). The ChangeLog should just explain what was changed, not why --> that's for comments in the code. The GNU Coding standard's ChangeLog section talks about that. Andrew Wu Zhou wrote: > Andrew, > > I have a check on x86_64, this is what I see on x86_64 when issuing > "info auxv" on 32-bit program: > > 32 AT_SYSINFO Special system info/entry points 0xffffe400^M > 33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0xffffe000^M > 16 AT_HWCAP Machine-dependent CPU capability hints > 0xbfebfbff^M > 6 AT_PAGESZ System page size 4096^M > 17 AT_CLKTCK Frequency of times() 100^M > 3 AT_PHDR Program headers for program 0x8048034^M > 4 AT_PHENT Size of program header entry 32^M > 5 AT_PHNUM Number of program headers 7^M > 7 AT_BASE Base address of interpreter 0x0^M > 8 AT_FLAGS Flags 0x0^M > 9 AT_ENTRY Entry point of program 0x80482f0^M > 11 AT_UID Real user ID 0^M > 12 AT_EUID Effective user ID 0^M > 13 AT_GID Real group ID 0^M > 14 AT_EGID Effective group ID 0^M > 23 AT_SECURE Boolean, was exec setuid-like? 0^M > 15 AT_PLATFORM String identifying platform 0xffffcceb > "i686"^M > 0 AT_NULL End of vector 0x0^M > 0 AT_NULL End of vector 0x0^M > 0 AT_NULL End of vector 0x0^M > > Please note that there are three AT_NULL at the end. This is the same > as what I saw on ppc64 for 32-bit program. > > This patch can fix that. OK for commit? > > 2006-08-28 Wu Zhou > > * cni/AuxvBuilder.cxx (verify): There might be multiple > AT_NULL at > the end of auxv vector. > > --- proc/cni/AuxvBuilder.cxx.orig 2006-08-28 13:48:53.000000000 > +0800 > +++ proc/cni/AuxvBuilder.cxx 2006-08-28 13:49:13.000000000 +0800 > @@ -110,9 +110,6 @@ > // Reasonable value? > if (type > 1024 || type < 0) > return false; > - // AT_NULL value only at end of buffer? > - if (type == 0 && i + 2 * wordSize < buf->length) > - return false; > } > return true; > } > > Andrew Cagney wrote: >> Wu Zhou wrote: >>> Yong Zheng wrote: >>>> hi, >>>> >>>> The followings are some difference between the test results of >>>> cases in >>>> 64-bit mode and in 32-bit mode on 64-bit frysk. >>>> >>>> All tests are based on the cvs head(08-24). >>>> >>>> On X86_64, the following cases fail in 32-bit mode but pass in 64-bit >>>> mode on 64-bit frysk: >>>> >>>> 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: >>>> unknown >>>> word size for auxv (1|32l|64l|32b|64b 10000) >>>> at frysk.sys.proc.AuxvBuilder.construct(TestRunner) >>> >>> on ppc64, testGetAuxv fails in 32-bit testcase because there are >>> three AT_NULL at the end of aux vectors, which might be actually ok >>> (because I don't see any nagative impact it can bring up). I don't >>> know what is the situation in x86_64. >> >> This is interesting, the lower level >> frysk-sys/frysk/sys/proc/TestAuxv.java contains: >> >> /** >> * Check that an AUXV taken from a 32-bit PowerPC program running >> * on a 64-bit PowerPC machine (PPC970, altivec supported) can be >> * parsed. >> */ >> >> so it is attempting to test the case you describe, or at least based >> on the AUXV I extracted from an older kernel. You're saying that the >> tail end of the AUXV is now different? If it is then perhaps that >> lower level test should be augmented to also include the AUXV buffer >> that you're seeing. > > We are on the latest FC5 kernels. So I guess this need to go into the > lower level frysk-sys testcase too. But I don't know how to generate > the "byte" array in routine "check". If you can tell me how, I can > code a patch for that. > > Regards > - Wu Zhou From pmuldoon@redhat.com Mon Aug 28 14:00:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 28 Aug 2006 14:00:00 -0000 Subject: Fedora Core 6 Test 3 In-Reply-To: <17650.57983.992139.940257@localhost.redhat.com> References: <44F08B01.9020409@redhat.com> <44F29A36.2010009@cn.ibm.com> <17650.57983.992139.940257@localhost.redhat.com> Message-ID: <44F2F6DB.3050700@redhat.com> I looked at the bug in detail over the weekend. I notice that all the reproducers require? Is it possible it is a vnc bug? Does the bug occur when you use the the machine - or any ppc64 machine - directly? Regards Phil Elena Zannoni wrote: > Yes we wanted to enable ppc, and were also wondering about the gtk > bug. I saw no comments on the bug from the gtk community. Do you know > what's going on there? > > thanks > elena > > > Wu Zhou writes: > > I see that the GA date of FC6 is at the beginning of October. Could it be possible to ship frysk in > > FC6 for PPC/PPC64? > > > > To achieve this, we had some 64-bit libraries issue, GUI blank problem (maybe a little more) to > > resolve. But I guess the time frame is ok for us. > > > > Regards > > - Wu Zhou > > > > Andrew Cagney wrote: > > > FYI, > > > Ref: http://fedoraproject.org/wiki/Core/Schedule > > > Test 3 of fedora core is freezing on September 5th so some of us are > > > going to try to get Fedora's frysk rpm updated early this coming week > > > (29th?). > > > > > > I'll be going through all those pending patches this weekend. > > > > > > Andrew > > > > From swagiaal@redhat.com Mon Aug 28 14:07:00 2006 From: swagiaal@redhat.com (Sami Wagiaalla) Date: Mon, 28 Aug 2006 14:07:00 -0000 Subject: get syscall num in updateSyscallExit In-Reply-To: <20060828111023.GA31608@GreenHouse.cn.ibm.com> References: <20060828111023.GA31608@GreenHouse.cn.ibm.com> Message-ID: <44F2F8AF.3010900@redhat.com> Yao Qi wrote: > Some of test cases get syscall num in updateSyscallExit by means of > syscallEventInfo.number (task), but it seems that it is not right all > the time. > > We find that we fail to get syscall number when EXIT rt_sigreturn and > sigreturn on x86/x86-64/ppc64. On x86 and x86-64, the syscall number > got when exit rt_sigreturn is -1. > > I am not sure it is the kernel problem or not. Any comments on this? > Thanks! > I dont think its a kernel bug. I have a feeling that we are not allowed to look at that value on syscallExit event only syscallEnter. Please file a bug and assign it to me :). If you have a test case that would be great Thanx, Sami From mark@klomp.org Mon Aug 28 14:24:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 28 Aug 2006 14:24:00 -0000 Subject: partial merge of syscall and non-syscall TaskStates Message-ID: <1156775042.3203.18.camel@dijkstra.wildebeest.org> Hi, This is the start of the merging of the syscall and non-syscall states. This merges all the "simple" states. It moves the logic from different state transitions into the TaskStates themselves. Adding a boolean to the TaskState to signal whether or not there are any syscall observers. 2006-08-28 Mark Wielaard * TaskState.java: Merge (syscall)WaitForContinueOrUnblock, (Syscall)BlockedSignal and (syscall)WaitForUnblocked states. All tests still pass with this change. Since it is mostly pretty simple/obvious I wanted to commit it now to separate it from the more intrusive changes to the main states. It does highlight a small difference between the syscall and non-syscall states. In some cases a pending signals seems to be discarded. Adding tests now to verify and fix if necessary. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: TaskState-merge1.patch Type: text/x-patch Size: 15749 bytes Desc: not available URL: From pmuldoon@redhat.com Mon Aug 28 15:30:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 28 Aug 2006 15:30:00 -0000 Subject: About the GUI blankness problem In-Reply-To: <20060828142315.82149.qmail@web55403.mail.re4.yahoo.com> References: <20060828142315.82149.qmail@web55403.mail.re4.yahoo.com> Message-ID: <44F30C23.4080704@redhat.com> > Phil, > > We had to use the GUI through vnc because all our > ppc64 machines are headless (this is to save expense). > We ever suspect the problem lies in vnc too, but > don't figure out any way to verify. The quickest way is to find a PPC64 that has a display attached to it, and test it there locally. A secondary test would be to run a remote session of Frysk via SSH and test that (ie ssh into the ppc64 box with ssh -X). Both of those would work around the need of vnc? Regards Phil From cagney@redhat.com Mon Aug 28 17:37:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 28 Aug 2006 17:37:00 -0000 Subject: frysk.junit.TestCase Message-ID: <44F329E8.8080407@redhat.com> Just a heads up, I moved the brokenXXX methods to frysk.junit.TestCase and had any code needing to pull that trick extend that object (there were many!) Andrew From cagney@redhat.com Mon Aug 28 23:42:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 28 Aug 2006 23:42:00 -0000 Subject: get syscall num in updateSyscallExit In-Reply-To: <44F2F8AF.3010900@redhat.com> References: <20060828111023.GA31608@GreenHouse.cn.ibm.com> <44F2F8AF.3010900@redhat.com> Message-ID: <44F37F53.3060804@redhat.com> Sami, you're correct. sigreturn, which is called when a signal handler exits, restores the state of a thread to what it was before an asynchronous signal was delivered. Consequently, it destroys all registers. Sami Wagiaalla wrote: > Yao Qi wrote: >> Some of test cases get syscall num in updateSyscallExit by means of >> syscallEventInfo.number (task), but it seems that it is not right all >> the time. >> >> We find that we fail to get syscall number when EXIT rt_sigreturn and >> sigreturn on x86/x86-64/ppc64. On x86 and x86-64, the syscall number >> got when exit rt_sigreturn is -1. >> >> I am not sure it is the kernel problem or not. Any comments on this? >> Thanks! >> > I dont think its a kernel bug. I have a feeling that we are not > allowed to look > at that value on syscallExit event only syscallEnter. Please file a > bug and assign > it to me :). If you have a test case that would be great > > Thanx, > Sami > From woodzltc@cn.ibm.com Tue Aug 29 01:42:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 29 Aug 2006 01:42:00 -0000 Subject: About the GUI blankness problem In-Reply-To: <44F30C23.4080704@redhat.com> References: <20060828142315.82149.qmail@web55403.mail.re4.yahoo.com> <44F30C23.4080704@redhat.com> Message-ID: <44F39B4D.2070904@cn.ibm.com> Hi, Phil, Thanks! We use "ssh -X" to forward X11 to our local machine. It works ok. Don't find any blankness till this time. Yeah, that is really great! But vnc is still a problem, I am thinking of filing a bug against vnc. Which is the most proper place to file this bug? Thanks! Regards - Wu Zhou Phil Muldoon wrote: > >> Phil, >> >> We had to use the GUI through vnc because all our >> ppc64 machines are headless (this is to save expense). >> We ever suspect the problem lies in vnc too, but >> don't figure out any way to verify. > > The quickest way is to find a PPC64 that has a display attached to it, > and test it there locally. A secondary test would be to run a remote > session of Frysk via SSH and test that (ie ssh into the ppc64 box with > ssh -X). Both of those would work around the need of vnc? > > Regards > > Phil > > From qiyaoltc@cn.ibm.com Tue Aug 29 02:57:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 29 Aug 2006 02:57:00 -0000 Subject: get syscall num in updateSyscallExit In-Reply-To: <44F37F53.3060804@redhat.com> References: <20060828111023.GA31608@GreenHouse.cn.ibm.com> <44F2F8AF.3010900@redhat.com> <44F37F53.3060804@redhat.com> Message-ID: <20060829024844.GB31608@GreenHouse.cn.ibm.com> On Mon, Aug 28, 2006 at 07:42:11PM -0400, Andrew Cagney wrote: > Sami, you're correct. sigreturn, which is called when a signal handler > exits, restores the state of a thread to what it was before an > asynchronous signal was delivered. Consequently, it destroys all > registers. Hi, Sami and Andrew, Thanks for your reply and clarification. I find this problem when I chase bug 3010. As Andrew mentioned above, all registers are destroyed when exit sys_rt_sigreturn or sys_sigreturn, we could not get syscall number from a certain register. On PPC64, when exit sys_rt_sigreturn, the value from gpr0(syscall number) is 3, which is sys_read, so test cases will regard it as an EXIT from sys_read instead of EXIT from sys_rt_sigreturn, and this will cause the problem described in #3010, "Read exit before enter". It is *NOT* always true to get syscall number from a certain register when exit a syscall. How about save syscall number when enter a syscall, and just return the saved value when get syscall number leaving syscall? -- Yao Qi From woodzltc@cn.ibm.com Tue Aug 29 08:45:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 29 Aug 2006 08:45:00 -0000 Subject: About testGetAuxv (in frysk-core) and TestAuxv (in frysk-sys) In-Reply-To: <44F2EE74.8050107@redhat.com> References: <1156413940.2172.63.camel@YZ_X86_64> <1156419492.2172.87.camel@YZ_X86_64> <44EDBD32.3090608@cn.ibm.com> <44F253CA.80701@redhat.com> <44F28641.40007@cn.ibm.com> <44F2EE74.8050107@redhat.com> Message-ID: <44F3FE92.7070502@cn.ibm.com> (I change the subject because it describes what we are discussing more precisely) Andrew Cagney wrote: > Wu, > Is this problem transient, or permanent? I am not sure if it is permanent. But it surely is not transient. I see this on FC5 kernel, FC6 test2 kernels, on both x86_64 and ppc64 platforms. > Its cases like this where adding a test, or test driven development, > becomes critical. Can you do the following: Yes. I can't be agree with you any more. Test driven development is critical for Frysk. The case Frysk has currently is not too much, it is relatively less I believe. > - modify TestAuxv to include a new test that contains the Auxv buffer > that you've seen; be sure to check that the test fails > > - add your patch > > - check that the failing test now passes (and none of the others now fail) I add a new case to TestAuxv as per your idea, it does fail with the original code. After applying my patch, the case can pass now. But it trigger another failure on case testPPC64. I did some anlysis, and found that routine "verify" will return true for get32l and get32b in this case after applying my patch. The further analysis shows that for byte array in testPPC64: new byte[] { 0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0, -128, 0, 0, 0, 0, 0, 0, 0, 20, 0, 0, 0, 0, 0, 0, 0, -128, 0, 0, 0, 0, 0, 0, 0, 21, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 33, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, -36, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 17, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 16, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 56, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 16, 1, 10, -40, 0, 0, 0, 0, 0, 0, 0, 11, 0, 0, 0, 0, 0, 0, 9, -12, 0, 0, 0, 0, 0, 0, 0, 12, 0, 0, 0, 0, 0, 0, 9, -12, 0, 0, 0, 0, 0, 0, 0, 13, 0, 0, 0, 0, 0, 0, 9, -7, 0, 0, 0, 0, 0, 0, 0, 14, 0, 0, 0, 0, 0, 0, 9, -7, 0, 0, 0, 0, 0, 0, 0, 23, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } the get32l and get32b will get 4 bytes first, and advance the buffer pointer for 8 bytes (2 * WordSize) and get the next 4 bytes, and go on like that. In this way, all the get32l/get32b will return 0, which will return false in original code and return true after applying my patch. So removing the check that AT_NULL can only be at the end of buffer will trigger error for this. But this check is not true for the 32-x-64 cases in x86_64 and ppc64. Can we figure out some other checks for this? > The removed code should also be replaced with a comment explaining why a > AT_NULL test can't be used (with, if needed reference to specific kernel > versions). The ChangeLog should just explain what was changed, not why > --> that's for comments in the code. The GNU Coding standard's > ChangeLog section talks about that. Thanks. I will keep that in mind when I submit patch later. Regards - Wu Zhou > > Andrew > > > Wu Zhou wrote: >> Andrew, >> >> I have a check on x86_64, this is what I see on x86_64 when issuing >> "info auxv" on 32-bit program: >> >> 32 AT_SYSINFO Special system info/entry points 0xffffe400^M >> 33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0xffffe000^M >> 16 AT_HWCAP Machine-dependent CPU capability hints >> 0xbfebfbff^M >> 6 AT_PAGESZ System page size 4096^M >> 17 AT_CLKTCK Frequency of times() 100^M >> 3 AT_PHDR Program headers for program 0x8048034^M >> 4 AT_PHENT Size of program header entry 32^M >> 5 AT_PHNUM Number of program headers 7^M >> 7 AT_BASE Base address of interpreter 0x0^M >> 8 AT_FLAGS Flags 0x0^M >> 9 AT_ENTRY Entry point of program 0x80482f0^M >> 11 AT_UID Real user ID 0^M >> 12 AT_EUID Effective user ID 0^M >> 13 AT_GID Real group ID 0^M >> 14 AT_EGID Effective group ID 0^M >> 23 AT_SECURE Boolean, was exec setuid-like? 0^M >> 15 AT_PLATFORM String identifying platform 0xffffcceb >> "i686"^M >> 0 AT_NULL End of vector 0x0^M >> 0 AT_NULL End of vector 0x0^M >> 0 AT_NULL End of vector 0x0^M >> >> Please note that there are three AT_NULL at the end. This is the same >> as what I saw on ppc64 for 32-bit program. >> >> This patch can fix that. OK for commit? >> >> 2006-08-28 Wu Zhou >> >> * cni/AuxvBuilder.cxx (verify): There might be multiple >> AT_NULL at >> the end of auxv vector. >> >> --- proc/cni/AuxvBuilder.cxx.orig 2006-08-28 13:48:53.000000000 >> +0800 >> +++ proc/cni/AuxvBuilder.cxx 2006-08-28 13:49:13.000000000 +0800 >> @@ -110,9 +110,6 @@ >> // Reasonable value? >> if (type > 1024 || type < 0) >> return false; >> - // AT_NULL value only at end of buffer? >> - if (type == 0 && i + 2 * wordSize < buf->length) >> - return false; >> } >> return true; >> } >> >> Andrew Cagney wrote: >>> Wu Zhou wrote: >>>> Yong Zheng wrote: >>>>> hi, >>>>> >>>>> The followings are some difference between the test results of >>>>> cases in >>>>> 64-bit mode and in 32-bit mode on 64-bit frysk. >>>>> >>>>> All tests are based on the cvs head(08-24). >>>>> >>>>> On X86_64, the following cases fail in 32-bit mode but pass in 64-bit >>>>> mode on 64-bit frysk: >>>>> >>>>> 1)testGetAuxv(frysk.proc.TestProcGet)java.lang.RuntimeException: >>>>> unknown >>>>> word size for auxv (1|32l|64l|32b|64b 10000) >>>>> at frysk.sys.proc.AuxvBuilder.construct(TestRunner) >>>> >>>> on ppc64, testGetAuxv fails in 32-bit testcase because there are >>>> three AT_NULL at the end of aux vectors, which might be actually ok >>>> (because I don't see any nagative impact it can bring up). I don't >>>> know what is the situation in x86_64. >>> >>> This is interesting, the lower level >>> frysk-sys/frysk/sys/proc/TestAuxv.java contains: >>> >>> /** >>> * Check that an AUXV taken from a 32-bit PowerPC program running >>> * on a 64-bit PowerPC machine (PPC970, altivec supported) can be >>> * parsed. >>> */ >>> >>> so it is attempting to test the case you describe, or at least based >>> on the AUXV I extracted from an older kernel. You're saying that the >>> tail end of the AUXV is now different? If it is then perhaps that >>> lower level test should be augmented to also include the AUXV buffer >>> that you're seeing. >> >> We are on the latest FC5 kernels. So I guess this need to go into the >> lower level frysk-sys testcase too. But I don't know how to generate >> the "byte" array in routine "check". If you can tell me how, I can >> code a patch for that. >> >> Regards >> - Wu Zhou > From qiyaoltc@cn.ibm.com Tue Aug 29 09:54:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 29 Aug 2006 09:54:00 -0000 Subject: SyscallNum.shjava miss some syscalls. Message-ID: <20060829094543.GC31608@GreenHouse.cn.ibm.com> regular expression "__NR_[a-z][a-z0-9]*" is applied to match Syscall number macros, but it could not cover all syscall number macros, such as, __NR_rt_sig*. We modify this regular expression like this, "__NR_[a-z_][a-z0-9_]*", the missed syscall macros could be matched, but get another problem on x86. Here is an example, #define __NR_timer_create 259 #define __NR_timer_settime (__NR_timer_create+1) __NR_timer_create will not be substitute by 259 in the second line, and so in the final java code, SyscallNum.java, it look like, static public final int SYStimer_create = 259; ...... static public final int SYStimer_settime = (__NR_timer_create+1); GCJ will emit an error on it. (B.T.W, SYStimer_settime is not a syscall on x86, but it is generated from /usr/include/syscall.h on x86. I am a little confused on this.) I browsed gcc man pages and could not find how to ask gcc to pre-process source code for more than one time, and substitute macros in a greedy way. What is the rule of syscall macro names should be on these different architectures? -- Yao Qi From mark@klomp.org Tue Aug 29 10:13:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 29 Aug 2006 10:13:00 -0000 Subject: frysk.junit.TestCase In-Reply-To: <44F329E8.8080407@redhat.com> References: <44F329E8.8080407@redhat.com> Message-ID: <1156846367.3010.5.camel@dijkstra.wildebeest.org> Hi Andrew, On Mon, 2006-08-28 at 13:37 -0400, Andrew Cagney wrote: > Just a heads up, I moved the brokenXXX methods to frysk.junit.TestCase > and had any code needing to pull that trick extend that object (there > were many!) Our build system picks up everything called Test* and tries to run it. But since TestCase doesn't actually contain any tests we get one failure in frysk-import: There was 1 failure: 1) warning(junit.framework.TestSuite$1)junit.framework.AssertionFailedError: No tests found in frysk.junit.TestCase at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) make check in other directories seems to work fine. It is probably easiest to rename this class. Or we can add some special case to common/Makefile.gen.sh (at the end). Cheers, Mark From mark@klomp.org Tue Aug 29 15:56:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 29 Aug 2006 15:56:00 -0000 Subject: partial merge of syscall and non-syscall TaskStates In-Reply-To: <1156775042.3203.18.camel@dijkstra.wildebeest.org> References: <1156775042.3203.18.camel@dijkstra.wildebeest.org> Message-ID: <1156866950.3010.19.camel@dijkstra.wildebeest.org> On Mon, 2006-08-28 at 16:24 +0200, Mark Wielaard wrote: > It does highlight a small difference between the syscall and non-syscall > states. In some cases a pending signals seems to be discarded. Adding > tests now to verify and fix if necessary. Creating a test for this was difficult since I couldn't figure out precisely when this code is triggered. It seems to only matter when a signal arrives when in the attaching state, which means we have done an sendAttach(), so we will then get a stopped event. Apparently there is a change we get a signal event (probably send externally) before that happens, but I couldn't figure out an reliable way to generate such a sequence. I did fixup the code so the syscall and non-syscall cases are similar. This doesn't impact any of the existing tests. 2006-08-29 Mark Wielaard * TaskState.java (transitionToSyscallRunningState): Add signal parameter. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: TaskState-transistion-syscall.patch Type: text/x-patch Size: 1445 bytes Desc: not available URL: From kasal@ucw.cz Tue Aug 29 18:59:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Tue, 29 Aug 2006 18:59:00 -0000 Subject: Are the java-gnome source zips used? Message-ID: <20060829185923.GA528@camelia.ucw.cz> Hello, the -devel rpms for java-gnome in Fedora contain zip files with java sources. Phil was surprised that it contains only these and not the C jni sources. The description used to say that the sources are useful in combination with Eclipse. Are these zips really used in practice by anyone? I apologize if this is a silly question. I'm about to do handle some problems in multilib packaging generated by these zip, and I'd like to check that the work is useful. Stepan Kasal From cagney@redhat.com Tue Aug 29 20:26:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 29 Aug 2006 20:26:00 -0000 Subject: Are the java-gnome source zips used? In-Reply-To: <20060829185923.GA528@camelia.ucw.cz> References: <20060829185923.GA528@camelia.ucw.cz> Message-ID: <44F4A2FA.50004@redhat.com> Stepan, that stuff is used by Eclipse, and yes it is useful. Andrew Stepan Kasal wrote: > Hello, > the -devel rpms for java-gnome in Fedora contain zip files with java > sources. Phil was surprised that it contains only these and not the > C jni sources. The description used to say that the sources are > useful in combination with Eclipse. > > Are these zips really used in practice by anyone? > > I apologize if this is a silly question. I'm about to do handle some > problems in multilib packaging generated by these zip, and I'd like > to check that the work is useful. > > Stepan Kasal > > From cagney@redhat.com Tue Aug 29 20:28:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 29 Aug 2006 20:28:00 -0000 Subject: frysk.junit.TestCase In-Reply-To: <1156846367.3010.5.camel@dijkstra.wildebeest.org> References: <44F329E8.8080407@redhat.com> <1156846367.3010.5.camel@dijkstra.wildebeest.org> Message-ID: <44F4A355.2020107@redhat.com> And I typed make check; wierd. Will fix now. Andrew Mark Wielaard wrote: > Hi Andrew, > > On Mon, 2006-08-28 at 13:37 -0400, Andrew Cagney wrote: > >> Just a heads up, I moved the brokenXXX methods to frysk.junit.TestCase >> and had any code needing to pull that trick extend that object (there >> were many!) >> > > Our build system picks up everything called Test* and tries to run it. > But since TestCase doesn't actually contain any tests we get one failure > in frysk-import: > > There was 1 failure: > 1) warning(junit.framework.TestSuite$1)junit.framework.AssertionFailedError: No tests found in frysk.junit.TestCase > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > > make check in other directories seems to work fine. It is probably > easiest to rename this class. Or we can add some special case to > common/Makefile.gen.sh (at the end). > > Cheers, > > Mark > > From pmuldoon@redhat.com Tue Aug 29 22:38:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 29 Aug 2006 22:38:00 -0000 Subject: Are the java-gnome source zips used? In-Reply-To: <20060829185923.GA528@camelia.ucw.cz> References: <20060829185923.GA528@camelia.ucw.cz> Message-ID: <44F4C1F8.2070104@redhat.com> Stepan Kasal wrote: > Hello, > the -devel rpms for java-gnome in Fedora contain zip files with java > sources. Phil was surprised that it contains only these and not the > C jni sources. The description used to say that the sources are > useful in combination with Eclipse. > They might be for other people, but I never use them in Eclipse. What would you do with them in Eclipse? > Are these zips really used in practice by anyone? > I can't see where I personally would use them as I invariably have to go and get the native bits as that is where the work is being done. Again I'm not saying they are not useful, they might be. I was just surprised they did not contain all the (considerable) amount of C code. I understand the multilib issue, so the issue is pretty moot. I'll just use the src.rpm from now - that seems more suited for my tasks. Regards Phil From pmuldoon@redhat.com Tue Aug 29 22:39:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 29 Aug 2006 22:39:00 -0000 Subject: Are the java-gnome source zips used? In-Reply-To: <44F4A2FA.50004@redhat.com> References: <20060829185923.GA528@camelia.ucw.cz> <44F4A2FA.50004@redhat.com> Message-ID: <44F4C22D.8020208@redhat.com> Andrew Cagney wrote: > Stepan, that stuff is used by Eclipse, and yes it is useful. In what context is it used by Eclipse? I'm honestly curious. Regards Phil From cagney@redhat.com Wed Aug 30 04:20:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 30 Aug 2006 04:20:00 -0000 Subject: About testGetAuxv (in frysk-core) and TestAuxv (in frysk-sys) In-Reply-To: <44F3FE92.7070502@cn.ibm.com> References: <1156413940.2172.63.camel@YZ_X86_64> <1156419492.2172.87.camel@YZ_X86_64> <44EDBD32.3090608@cn.ibm.com> <44F253CA.80701@redhat.com> <44F28641.40007@cn.ibm.com> <44F2EE74.8050107@redhat.com> <44F3FE92.7070502@cn.ibm.com> Message-ID: <44F51210.2050007@redhat.com> Wu Zhou wrote: > > I add a new case to TestAuxv as per your idea, it does fail with the > original code. After applying my patch, the case can pass now. But > it trigger another failure on case testPPC64. > > I did some anlysis, and found that routine "verify" will return true > for get32l and get32b in this case after applying my patch. > > The further analysis shows that for byte array in testPPC64: > > new byte[] { > 0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 22, > 0, 0, 0, 0, 0, 0, 0, 22, 0, 0, 0, 0, 0, 0, 0, 22, > 0, 0, 0, 0, 0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0, -128, > 0, 0, 0, 0, 0, 0, 0, 20, 0, 0, 0, 0, 0, 0, 0, -128, > 0, 0, 0, 0, 0, 0, 0, 21, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 33, 0, 0, 0, 0, 0, 16, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 16, 0, 0, 0, 0, -36, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 16, 0, > 0, 0, 0, 0, 0, 0, 0, 17, 0, 0, 0, 0, 0, 0, 0, 100, > 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 16, 0, 0, 64, > 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0, 56, > 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 7, > 0, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 16, 1, 10, -40, > 0, 0, 0, 0, 0, 0, 0, 11, 0, 0, 0, 0, 0, 0, 9, -12, > 0, 0, 0, 0, 0, 0, 0, 12, 0, 0, 0, 0, 0, 0, 9, -12, > 0, 0, 0, 0, 0, 0, 0, 13, 0, 0, 0, 0, 0, 0, 9, -7, > 0, 0, 0, 0, 0, 0, 0, 14, 0, 0, 0, 0, 0, 0, 9, -7, > 0, 0, 0, 0, 0, 0, 0, 23, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 > } > FYI, this array came from, I think, an FC-4 PPC64 machine. > the get32l and get32b will get 4 bytes first, and advance the buffer > pointer for 8 bytes (2 * WordSize) and get the next 4 bytes, and go on > like that. > > In this way, all the get32l/get32b will return 0, which will return > false in original code and return true after applying my patch. > > So removing the check that AT_NULL can only be at the end of buffer > will trigger error for this. But this check is not true for the > 32-x-64 cases in x86_64 and ppc64. Can we figure out some other > checks for this? > can the test instead check that the AT_NULL's (plural) are only at the end of the file? For instance, from the AT_NULL on everything is 0? Andrew From mark@klomp.org Wed Aug 30 09:11:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 30 Aug 2006 09:11:00 -0000 Subject: fc6/development packages status Message-ID: <1156929078.3015.15.camel@dijkstra.wildebeest.org> Hi, I saw new frysk and kernel packages for fc6/test so I tried them out. kernel-2.6.17-1.2597.fc6 and frysk-0.0.1.2006.08.28.rh1-1.fc6 The good news is that my machine doesn't crash anymore, which it did with older kernels when running the frysk testsuite. And I am no longer observing the "ghost" results mentioned in bug #3121. The bad new is that there are still lots of failures with this combination and the testsuite hangs in the middle of one test. Below is the tail of a the output of /usr/libexec/frysk/funit Cheers, Mark -------------- next part -------------- Running testGet(inua.eio.TestGet) ...PASS Running testMmap(inua.eio.TestMmap) ...PASS Running testPut(inua.eio.TestPut) ...PASS Running testGetWord(inua.eio.TestWordSize) ...PASS Running testRest(inua.eio.TestWordSize) ...PASS Running testParamaterlessPool(inua.util.TestPool) ...PASS Running testParameteredPool(inua.util.TestPool) ...PASS Running testGetLine(lib.dw.tests.TestDwfl) ...<>PASS Running testGetDie(lib.dw.tests.TestDwfl) ...FAIL junit.framework.AssertionFailedError Running testCore(lib.elf.tests.TestElf) ...ERROR lib.elf.ElfFileException: Could not open /builddir/build/BUILD/frysk-0.0.1.2006.08.28.rh1/frysk-imports/lib/elf/tests/test-core for reading Running testObjectFile(lib.elf.tests.TestElf) ...<>PASS Running testDisassembler(lib.opcodes.tests.TestOpcodes) ...PASS Running testIA32(frysk.sys.proc.TestAuxv) ...PASS Running testAMD64(frysk.sys.proc.TestAuxv) ...PASS Running testIA64(frysk.sys.proc.TestAuxv) ...PASS Running testPPC32(frysk.sys.proc.TestAuxv) ...PASS Running testPPC64(frysk.sys.proc.TestAuxv) ...PASS Running test(frysk.sys.proc.TestCmdLine) ...PASS Running test_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_0(frysk.sys.proc.TestCmdLine) ...PASS Running test_0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0(frysk.sys.proc.TestCmdLine) ...PASS Running test_a0_b0_c0(frysk.sys.proc.TestCmdLine) ...PASS Running testIA32(frysk.sys.proc.TestMaps) ...PASS Running testIA64(frysk.sys.proc.TestMaps) ...PASS Running testAMD64(frysk.sys.proc.TestMaps) ...PASS Running testPPC32(frysk.sys.proc.TestMaps) ...PASS Running testPPC64(frysk.sys.proc.TestMaps) ...PASS Running testParseStatusGetID(frysk.sys.proc.TestStatus) ...PASS Running testParseStatusNullBufferGetID(frysk.sys.proc.TestStatus) ...PASS Running testParseStatusInvalidBufferGetID(frysk.sys.proc.TestStatus) ...PASS Running testMapRead(frysk.sys.StressMapRead) ...<>PASS Running testChildContinue(frysk.sys.TestCallPtrace) ...PASS Running testAttach(frysk.sys.TestCallPtrace) ...PASS Running testTextVariable(frysk.sys.TestPtraceByteBuffer) ...PASS Running testDataFunction(frysk.sys.TestPtraceByteBuffer) ...PASS Running testAll(frysk.sys.TestPty) ...PASS Running testFillEmpty(frysk.sys.TestSigSet) ...PASS Running testAddRemove(frysk.sys.TestSigSet) ...PASS Running testList(frysk.sys.TestSigSet) ...PASS Running testProcMask(frysk.sys.TestSigSet) ...PASS Running testAllSet(frysk.cli.hpd.TestSetCreation) ...PASS Running testSubset(frysk.cli.hpd.TestSetCreation) ...PASS Running testReg(frysk.cli.hpd.TestSetParser) ...PASS Running testRange(frysk.cli.hpd.TestSetParser) ...PASS Running testState(frysk.cli.hpd.TestSetParser) ...PASS Running testExec(frysk.cli.hpd.TestSetParser) ...PASS Running testDOMFrysk(frysk.dom.TestDOM) ...PASS Running testDOMImage(frysk.dom.TestDOM) ...PASS Running testDOMFunction(frysk.dom.TestDOM) ...PASS Running testDOMsource(frysk.dom.TestDOM) ...PASS Running testDOMLine(frysk.dom.TestDOM) ...PASS Running testDOMInlineInstance(frysk.dom.TestDOM) ...PASS Running testEventLoop(frysk.event.TestEventLoop) ...PASS Running testPeriodicTimer(frysk.event.TestEventLoop) ...PASS Running testTimerRemoval(frysk.event.TestEventLoop) ...PASS Running testScheduleBeforeRun(frysk.event.TestEventLoop) ...PASS Running testSignalHandler(frysk.event.TestEventLoop) ...PASS Running testAsync(frysk.event.TestEventLoop) ...PASS Running testAAA(frysk.event.TestSigChild) ...PASS Running testBBB(frysk.event.TestSigChild) ...PASS Running test(frysk.proc.StressAttachDetachManyTasks) ...<>PASS Running test(frysk.proc.StressAttachDetachRapidlyCloningMainTask) ...<>PASS Running testTaskForkedObserver(frysk.proc.StressAttachDetachRapidlyForkingMainTask) ...<>PASS Running testForking(frysk.proc.StressAttachDetachSignaledTask) ...<>PASS Running testCloning(frysk.proc.StressAttachDetachSignaledTask) ...<>PASS Running testExecing(frysk.proc.StressAttachDetachSignaledTask) ...30-Aug-06 11:04:00 AM frysk.proc.LinuxHost$PollWaitOnSigChld$2 terminated WARNING: No task for pid 2,508 PASS Running testHitAndRun(frysk.proc.TestBreakpoints) ...PASS Running testInsertRemove(frysk.proc.TestBreakpoints) ...PASS Running testAddLots(frysk.proc.TestBreakpoints) ...PASS Running testProcBlockExec(frysk.proc.TestExec) ...PASS Running testTaskBlockExec(frysk.proc.TestExec) ...PASS Running testAttachedSingleExec(frysk.proc.TestExec) ...PASS Running testAttachedMultipleParentExec(frysk.proc.TestExec) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testAttachedMultipleChildExec(frysk.proc.TestExec) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testGetSelf(frysk.proc.TestHostGet) ...PASS Running testI386Modify(frysk.proc.TestI386Modify) ...<>PASS Running testI386Regs(frysk.proc.TestI386Regs) ...30-Aug-06 11:04:12 AM frysk.proc.LinuxHost$PollWaitOnSigChld$2 terminated WARNING: No task for pid 2,533 PASS Running testIdEquals(frysk.proc.TestId) ...PASS Running testIdCompareTo(frysk.proc.TestId) ...PASS Running testTaskId(frysk.proc.TestId) ...PASS Running testProcId(frysk.proc.TestId) ...PASS Running testModify(frysk.proc.TestModify) ...<>PASS Running testGetAuxv(frysk.proc.TestProcGet) ...PASS Running testGetCommand(frysk.proc.TestProcGet) ...PASS Running testGetTasks(frysk.proc.TestProcGet) ...PASS Running testGetChildren(frysk.proc.TestProcGet) ...PASS Running testGetCmdLine(frysk.proc.TestProcGet) ...PASS Running testGetExe(frysk.proc.TestProcGet) ...PASS Running testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testSingleExistingCloneAttached(frysk.proc.TestProcTasksObserver) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testCloneThenKillAttached(frysk.proc.TestProcTasksObserver) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testDeleteAttached(frysk.proc.TestProcTasksObserver) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testDoCloneAttached(frysk.proc.TestProcTasksObserver) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testSingleExistingThreadAttached(frysk.proc.TestProcTasksObserver) ...PASS Running testManyExistingThreadDetached(frysk.proc.TestProcTasksObserver) ...PASS Running testSingleExistingCloneDetached(frysk.proc.TestProcTasksObserver) ...PASS Running testCloneThenKillDetached(frysk.proc.TestProcTasksObserver) ...FAIL junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) Running testDeleteDetached(frysk.proc.TestProcTasksObserver) ...PASS Running testDoCloneDetached(frysk.proc.TestProcTasksObserver) ...<>PASS Running testSingleExistingThreadDetached(frysk.proc.TestProcTasksObserver) ...PASS Running testManyExistingThreadAckDaemon(frysk.proc.TestProcTasksObserver) ...PASS Running testSingleExistingCloneAckDaemon(frysk.proc.TestProcTasksObserver) ...PASS Running testCloneThenKillAckDaemon(frysk.proc.TestProcTasksObserver) ... From mark@klomp.org Wed Aug 30 09:17:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 30 Aug 2006 09:17:00 -0000 Subject: fc6/development packages status In-Reply-To: <1156929078.3015.15.camel@dijkstra.wildebeest.org> References: <1156929078.3015.15.camel@dijkstra.wildebeest.org> Message-ID: <1156929419.3015.18.camel@dijkstra.wildebeest.org> On Wed, 2006-08-30 at 11:11 +0200, Mark Wielaard wrote: > I saw new frysk and kernel packages for fc6/test so I tried them out. > kernel-2.6.17-1.2597.fc6 and frysk-0.0.1.2006.08.28.rh1-1.fc6 Forgot to mention the platform: Linux hermans.wildebeest.org 2.6.17-1.2597.fc6 #1 SMP Mon Aug 28 21:27:29 EDT 2006 i686 i686 i386 GNU/Linux This is a dual core intel T2400 laptop (thinkpad t60) Cheers, Mark From qiyaoltc@cn.ibm.com Wed Aug 30 10:23:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 30 Aug 2006 10:23:00 -0000 Subject: fc6/development packages status In-Reply-To: <1156929078.3015.15.camel@dijkstra.wildebeest.org> References: <1156929078.3015.15.camel@dijkstra.wildebeest.org> Message-ID: <20060830095018.GD31608@GreenHouse.cn.ibm.com> On Wed, Aug 30, 2006 at 11:11:18AM +0200, Mark Wielaard wrote: > Hi, > > I saw new frysk and kernel packages for fc6/test so I tried them out. > kernel-2.6.17-1.2597.fc6 and frysk-0.0.1.2006.08.28.rh1-1.fc6 Hi, Mark, How could you "see" frysk and kernel packages for fc6/test? Could you post the URL that we could have a look? Thanks! > > The good news is that my machine doesn't crash anymore, which it did > with older kernels when running the frysk testsuite. And I am no longer > observing the "ghost" results mentioned in bug #3121. > The bad new is that there are still lots of failures with this > combination and the testsuite hangs in the middle of one test. > > Below is the tail of a the output of /usr/libexec/frysk/funit > > Cheers, > > Mark > Running testGetDie(lib.dw.tests.TestDwfl) ...FAIL > junit.framework.AssertionFailedError > Running testCore(lib.elf.tests.TestElf) ...ERROR > lib.elf.ElfFileException: Could not open /builddir/build/BUILD/frysk-0.0.1.2006.08.28.rh1/frysk-imports/lib/elf/tests/test-core for reading This may be caused by this, public void testCore () throws ElfException, ElfFileException { Elf testElf = new Elf(Build.ABS_BUILDDIR +"/lib/elf/tests/test-core", ElfCommand.ELF_C_READ); I do not know to much about other failures, and I am not sure what is the result of frysk rpm package for ppc64, if any. -- Yao Qi From mark@klomp.org Wed Aug 30 10:43:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 30 Aug 2006 10:43:00 -0000 Subject: fc6/development packages status In-Reply-To: <20060830095018.GD31608@GreenHouse.cn.ibm.com> References: <1156929078.3015.15.camel@dijkstra.wildebeest.org> <20060830095018.GD31608@GreenHouse.cn.ibm.com> Message-ID: <1156934577.3015.37.camel@dijkstra.wildebeest.org> Hi Yao, On Wed, 2006-08-30 at 17:50 +0800, Yao Qi wrote: > On Wed, Aug 30, 2006 at 11:11:18AM +0200, Mark Wielaard wrote: > > I saw new frysk and kernel packages for fc6/test so I tried them out. > > kernel-2.6.17-1.2597.fc6 and frysk-0.0.1.2006.08.28.rh1-1.fc6 > How could you "see" frysk and kernel packages for fc6/test? Could you > post the URL that we could have a look? Thanks! I have a machine running FC6/development and it comes with a little notification application that, when connected to the internet, checks for updates (yum-updatesd). The packages are also available at: http://download.fedora.redhat.com/pub/fedora/linux/core/development/ Cheers, Mark From qiyaoltc@cn.ibm.com Wed Aug 30 12:14:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 30 Aug 2006 12:14:00 -0000 Subject: fc6/development packages status In-Reply-To: <1156934577.3015.37.camel@dijkstra.wildebeest.org> References: <1156929078.3015.15.camel@dijkstra.wildebeest.org> <20060830095018.GD31608@GreenHouse.cn.ibm.com> <1156934577.3015.37.camel@dijkstra.wildebeest.org> Message-ID: <20060830120610.GE31608@GreenHouse.cn.ibm.com> On Wed, Aug 30, 2006 at 12:42:56PM +0200, Mark Wielaard wrote: > > I have a machine running FC6/development and it comes with a little > notification application that, when connected to the internet, checks > for updates (yum-updatesd). The packages are also available at: > http://download.fedora.redhat.com/pub/fedora/linux/core/development/ Hi, Mark, Thanks for your information! I will try to install frysk-0.0.1.2006.08.28.rh1-1.fc6.i386.rpm on my desktop. frysk rpm for x86_64 also could be found. Unfortunately, frysk.rpm for ppc64 and ppc could not be found. :( When could frysk rpm for ppc64 is available? -- Yao Qi From zhengyo@cn.ibm.com Wed Aug 30 12:46:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 30 Aug 2006 12:46:00 -0000 Subject: One small patch to fix TestX8664Modify testcase(frysk-core/frysk/proc/TestX8664Modify.java). Message-ID: <1156941616.2807.23.camel@YZ_X86_64> hi, The TestX8664Modify test case will never be run because the following two reasons: 1)the case creates one AttachedDaemonProcess executing "funit-ia32-modify" which will do nothing when the platform is X86_64. 2) When the case adds observers to task, it will check whether the task's ISA is one instance object of LinuxIa32. On X86_64, the condition will never be meet, so no observers are added, which makes the case passed in our previous tests. During adding TestPPC64Modify case and merging the TestModify into one case, we found the above problem. After we corrected the above two problems, the case failed. So we traced down the source codes and did one patch to fix the case. In the patch, we move all operations on registers from the updateSyscallEnter() into updateSyscallExit(). During the tests, we find the register rcx's value will be modified after we put it in but before the funit-x8664-modify.S reads it(we guess it's done by syscall, but not sure). So we remove all operations on the rcx. 2006-08-30 Yong Zheng * frysk/proc/TestX8664Modify.java: Move all operations on registers from updateSyscallEnter() into updateSyscallExit(). * frysk/pkglibexecdir/funit-x8664-modify.S: Ignore the check on register "rcx". Rebuild the frysk based on the cvs head(08-30). please review. ok to commit? Thanks. Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_fix_x8664modify.patch Type: text/x-patch Size: 6269 bytes Desc: not available URL: From mark@klomp.org Wed Aug 30 13:08:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 30 Aug 2006 13:08:00 -0000 Subject: merge detaching and deatchingInSyscall states Message-ID: <1156943316.3015.48.camel@dijkstra.wildebeest.org> Hi, This patch merges the detaching and detachingInSyscall states. The only real difference between these states was that the detachingInSyscall state handled the case of a syscall event, but didn't handle any of the other events that might need "bubbling up" like Andrew recently added to the detached state. 2006-08-30 Mark Wielaard * TaskState.java: Merge detaching and detachingInSyscall states. Again it was not really possible to write a test to see whether or not the "bubbling up" of events now also correctly worked in the syscall case since it means creating an 'unexpected out of order' event stream which we only saw with some newer kernels afaik. But all existing tests of course pass with this change. Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: detachingInSyscall-merge.patch Type: text/x-patch Size: 2522 bytes Desc: not available URL: From cagney@redhat.com Wed Aug 30 15:01:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 30 Aug 2006 15:01:00 -0000 Subject: One small patch to fix TestX8664Modify testcase(frysk-core/frysk/proc/TestX8664Modify.java). In-Reply-To: <1156941616.2807.23.camel@YZ_X86_64> References: <1156941616.2807.23.camel@YZ_X86_64> Message-ID: <44F5A836.70809@redhat.com> Yong, I'm slightly confused. This is for TestModify, or TestModify? You mentioned merging things into one test? This is ok, but as for TestRegs, can you merge things (and make certain that the old Test tests are deleted). Andrew Yong Zheng wrote: > hi, > > The TestX8664Modify test case will never be run because the following > two reasons: > 1)the case creates one AttachedDaemonProcess executing > "funit-ia32-modify" which will do nothing when the platform is X86_64. > > 2) When the case adds observers to task, it will check whether the > task's ISA is one instance object of LinuxIa32. On X86_64, the condition > will never be meet, so no observers are added, which makes the case > passed in our previous tests. > > During adding TestPPC64Modify case and merging the TestModify into > one case, we found the above problem. After we corrected the above two > problems, the case failed. So we traced down the source codes and did > one patch to fix the case. > > In the patch, we move all operations on registers from the > updateSyscallEnter() into updateSyscallExit(). During the tests, we > find the register rcx's value will be modified after we put it in but > before the funit-x8664-modify.S reads it(we guess it's done by syscall, > but not sure). So we remove all operations on the rcx. > > 2006-08-30 Yong Zheng > > * frysk/proc/TestX8664Modify.java: Move all operations on > registers from updateSyscallEnter() into updateSyscallExit(). > * frysk/pkglibexecdir/funit-x8664-modify.S: Ignore the check on > register "rcx". > > Rebuild the frysk based on the cvs head(08-30). > > please review. ok to commit? Thanks. > From npremji@redhat.com Wed Aug 30 18:19:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Wed, 30 Aug 2006 18:19:00 -0000 Subject: Eventviewer Event Accessibility Message-ID: <1156961971.10405.2.camel@toad.toronto.redhat.com> Okay I've finally fixed up eventviewer event accessibility so we can do some testing with events. Attached is a screen-shot. -------------- next part -------------- A non-text attachment was scrubbed... Name: eventaccessibles.png Type: image/png Size: 157488 bytes Desc: not available URL: From tromey@redhat.com Wed Aug 30 18:20:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Wed, 30 Aug 2006 18:20:00 -0000 Subject: SyscallNum.shjava miss some syscalls. In-Reply-To: <20060829094543.GC31608@GreenHouse.cn.ibm.com> References: <20060829094543.GC31608@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: Yao> #define __NR_timer_create 259 Yao> #define __NR_timer_settime (__NR_timer_create+1) [...] Yao> static public final int SYStimer_create = 259; Yao> ...... Yao> static public final int SYStimer_settime = (__NR_timer_create+1); Yao> I browsed gcc man pages and could not find how to ask gcc to Yao> pre-process source code for more than one time, and substitute macros Yao> in a greedy way. One approach would be to run your regular expression to extract names like __NR_timer_settime, then construct a small file like: #include SYStimer_settime = __NR_timer_settime; [ one line per syscall ] ... and, finally, run that through 'gcc -E'. This can easily be automated. In the end you can paste the results into a .java file ... not pretty, but it works. Tom From zhengyo@cn.ibm.com Thu Aug 31 00:49:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Thu, 31 Aug 2006 00:49:00 -0000 Subject: One small patch to fix TestX8664Modify testcase(frysk-core/frysk/proc/TestX8664Modify.java). In-Reply-To: <44F5A836.70809@redhat.com> References: <1156941616.2807.23.camel@YZ_X86_64> <44F5A836.70809@redhat.com> Message-ID: <1156985009.29210.11.camel@YZ_X86_64> On Wed, 2006-08-30 at 11:01 -0400, Andrew Cagney wrote: > Yong, > I'm slightly confused. This is for TestModify, or TestModify? This is for TestModify, not for TestModify(In fact, the TestModify case passed on PPC64/X86/86_64 in our previous tests after we removed the broken instruction. So it needs no modification). > You > mentioned merging things into one test? Yes, we have done it several days ago. Before we submit it, we do the latest test but found TestX8664Modify failed. > This is ok, but as for > TestRegs, can you merge things (and make certain that the old > Test tests are deleted). The TestRegs has been checked in two days ago but we didnot delete the TestI386Regs.java and TestX8664Regs.java. I'm so sorry not to send email on that to you. I thought you would get to know because frysk-cvs mail list will inform us by emails after we checked the codes in. Now, should we delete the redundant files: TestI386Regs.java and TestX8664Regs.java? Best regards Yong Zheng From qiyaoltc@cn.ibm.com Thu Aug 31 03:16:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 31 Aug 2006 03:16:00 -0000 Subject: Test result of frysk on EM64T FC5 [frysk-core] Message-ID: <20060831031703.GA24582@GreenHouse.cn.ibm.com> It seems that the test result varies from CPU(em64t or amd64) and distro(FC5 or FC6T2) on X86_64. Here is the information about the machine that tests running on, and test result in frysk-core. [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ uname -a Linux YZ_X86_64 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 x86_64 x86_64 x86_64 GNU/Linux [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping : 1 cpu MHz : 3192.283 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr bogomips : 6394.91 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping : 1 cpu MHz : 3192.283 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr bogomips : 6384.48 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/x86_64-redhat-linux/4.1.1/libgcj.spec rename spec lib to liborig Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) Time: 29.294 There were 5 failures: 1) testTaskBlockExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: tmp file exists at frysk.proc.TestExec.testTaskBlockExec(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 2) testAttachedMultipleChildExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendExecWaitForAcks:9010 (Sig_USR1)) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib$AckHandler.assertAwait(TestRunner) at frysk.proc.TestLib$AckHandler.await(TestRunner) at frysk.proc.TestLib$AckProcess.assertSendExecWaitForAcks(TestRunner) at frysk.proc.TestExec.testAttachedMultipleChildExec(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 3) testSyscallLoop(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: inSyscall (last call doesn't exit) at frysk.proc.TestTaskSyscallObserver.testSyscallLoop(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 4) testSyscalls(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: syscall events at frysk.proc.TestTaskSyscallObserver.testSyscalls(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 5) testSyscallOpen(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: in syscall at frysk.proc.TestTaskSyscallObserver.testSyscallOpen(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 139, Failures: 5, Errors: 0 -- Yao Qi From rmoseley@redhat.com Thu Aug 31 03:48:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 31 Aug 2006 03:48:00 -0000 Subject: Test result of frysk on EM64T FC5 [frysk-core] In-Reply-To: <20060831031703.GA24582@GreenHouse.cn.ibm.com> References: <20060831031703.GA24582@GreenHouse.cn.ibm.com> Message-ID: <44F65BED.6030601@redhat.com> Yao Qi wrote: > It seems that the test result varies from CPU(em64t or amd64) and > distro(FC5 or FC6T2) on X86_64. Here is the information about the > machine that tests running on, and test result in frysk-core. > > [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ uname -a > Linux YZ_X86_64 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 > x86_64 x86_64 x86_64 GNU/Linux > Hmmmm, that is a pretty old kernel you have there. The latest FC5 kernel is 2.6.17-1.2174_FC5. > [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Pentium(R) 4 CPU 3.20GHz > stepping : 1 > cpu MHz : 3192.283 > cache size : 1024 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 1 > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall > nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr > bogomips : 6394.91 > clflush size : 64 > cache_alignment : 128 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 1 > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Pentium(R) 4 CPU 3.20GHz > stepping : 1 > cpu MHz : 3192.283 > cache size : 1024 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 1 > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall > nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr > bogomips : 6384.48 > clflush size : 64 > cache_alignment : 128 > address sizes : 36 bits physical, 48 bits virtual > power management: > > [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ gcj -v > Using built-in specs. > Reading specs from /usr/lib/gcc/x86_64-redhat-linux/4.1.1/libgcj.spec > rename spec lib to liborig > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-libgcj-multifile > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > --enable-java-awt=gtk --disable-dssi > --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre > --with-cpu=generic --host=x86_64-redhat-linux > Thread model: posix > gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) > The compiler looks to be the current one for FC5. Might want to try with the latest kernel and see what the results for you are on both FC5 and FC6t2. There was just a new kernel released for FC6t2 in the last day or so, it is 2.6.17-1.2600.fc6. The latest compiler for FC6t2 is gcc (GCC) 4.1.1 20060828 (Red Hat 4.1.1-20). Rick > > > Time: 29.294 > There were 5 failures: > 1) > testTaskBlockExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: > tmp file exists > at frysk.proc.TestExec.testTaskBlockExec(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > 2) > testAttachedMultipleChildExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: > event loop run explictly stopped (assertSendExecWaitForAcks:9010 > (Sig_USR1)) > at frysk.proc.TestLib.assertRunUntilStop(TestRunner) > at frysk.proc.TestLib.assertRunUntilStop(TestRunner) > at frysk.proc.TestLib$AckHandler.assertAwait(TestRunner) > at frysk.proc.TestLib$AckHandler.await(TestRunner) > at > frysk.proc.TestLib$AckProcess.assertSendExecWaitForAcks(TestRunner) > at frysk.proc.TestExec.testAttachedMultipleChildExec(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > 3) > testSyscallLoop(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: > inSyscall (last call doesn't exit) > at frysk.proc.TestTaskSyscallObserver.testSyscallLoop(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > 4) > testSyscalls(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: > syscall events > at frysk.proc.TestTaskSyscallObserver.testSyscalls(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > 5) > testSyscallOpen(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: > in syscall > at frysk.proc.TestTaskSyscallObserver.testSyscallOpen(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > > FAILURES!!! > Tests run: 139, Failures: 5, Errors: 0 > > From mark@klomp.org Thu Aug 31 10:15:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 31 Aug 2006 10:15:00 -0000 Subject: Test result of frysk on EM64T FC5 [frysk-core] In-Reply-To: <20060831031703.GA24582@GreenHouse.cn.ibm.com> References: <20060831031703.GA24582@GreenHouse.cn.ibm.com> Message-ID: <1157019316.3000.3.camel@dijkstra.wildebeest.org> Hi Yao, On Thu, 2006-08-31 at 11:17 +0800, Yao Qi wrote: > It seems that the test result varies from CPU(em64t or amd64) and > distro(FC5 or FC6T2) on X86_64. Here is the information about the > machine that tests running on, and test result in frysk-core. > > [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ uname -a > Linux YZ_X86_64 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 2006 > x86_64 x86_64 x86_64 GNU/Linux I have a slightly newer kernel here: uname -a Linux dijkstra.wildebeest.org 2.6.17-1.2174_FC5 #1 SMP Tue Aug 8 15:30:44 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux And a Pentium D instead of a Pentium 4. Same gcc version. All these 5 tests pass for me though. Cheers, Mark From mark@klomp.org Thu Aug 31 10:35:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 31 Aug 2006 10:35:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog cni/Wait.cxx In-Reply-To: <20060831021346.14715.qmail@sourceware.org> References: <20060831021346.14715.qmail@sourceware.org> Message-ID: <1157020532.3000.8.camel@dijkstra.wildebeest.org> Hi Chris, On Thu, 2006-08-31 at 02:13 +0000, cmoller@sourceware.org wrote: > Log message: > Added code to send diagnostics to cmoller@redhat.com if the 0xff > condition is detected. > > + // suppress local reporting of any 0xff status Could you make it so that it also puts a diagnostic for the local user? I am happy to send you email if it occurs and I happen to see it, even though I am not in the moller/redhat.com domain. Cheers, Mark From mark@klomp.org Thu Aug 31 11:58:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 31 Aug 2006 11:58:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog cni/Wait.cxx In-Reply-To: <44F6CBBA.4010400@redhat.com> References: <20060831021346.14715.qmail@sourceware.org> <1157020532.3000.8.camel@dijkstra.wildebeest.org> <44F6CBBA.4010400@redhat.com> Message-ID: <1157025510.3000.19.camel@dijkstra.wildebeest.org> Hi Chris, On Thu, 2006-08-31 at 07:44 -0400, Chris Moller wrote: > Mark Wielaard mumbled something on 08/31/2006 06:35 AM: > > On Thu, 2006-08-31 at 02:13 +0000, cmoller@sourceware.org wrote: > > But if you want to be notified somehow, that's fine with me. If I > just omit that conditional, a runtime exception will be thrown. Will > that work? Yes a RuntimeException is fine. That is precisely what it is, the runtime (or kernel) is utterly confused. Don't hide that from me. I want to feel the pain :) Cheers, Mark From ezannoni@redhat.com Thu Aug 31 13:29:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Thu, 31 Aug 2006 13:29:00 -0000 Subject: frysk mtg minutes 20060829 Message-ID: <17654.58091.990245.779626@localhost.redhat.com> Stepan: Enable the ppc64 build of Frysk in RHEL5 and Fedora. Add the ppc64 java-gnome packages to RHEL5 and Fedora. Libunwind Alex: adding remote features: shouldn't be too hard, but not being able to see how to offer them. If you are remote, the user is supposed to tell libunwind how to use the information. Possibly export some functions that the users can use as callback. Cagney says that the problem has been resolved for ia64. Ia64 uses itanium unwind info, which is in the remote process. Callback to read from remote memory were put in place when JeffJ made gdb use libunwind. Also need for callbacks to free remote memory that it allocates. It now just allocates local memory. But this memory will need to be freed explicitly once it is allocated remotely. Alex says that you need to cache information (didn't catch that, sorry). Mosberger is out on vacation until the end of august, which it may mean he is out until after labor day :-( utrace: Roland nothing to report. Chris: still not able to track down that 0xff problem. Will use heavy hammer of adding log messages. Mark: making progress. Trying to cleanup and writing tests. Gave up on rawhide, using fc5 as devel platform. Tim: register window cleanup for floating point registers. Interface issues because you need to be able to switch between different ways to read the registers (mmx regs). Andrew: done some workarounds in the code for kernel bugs. Mike: done fix for double parent/ghost Stan: can get dwarf info for current frame. Clean up the patch and post it. Then use libunwind to be able to get the dwarf info for other frames is next. Also writing tests for this part of the code. Extending on the Java interface for libdwarf that Adam started. Not sure how the gui is going to use this code though. Phil: rhel5, kernel bugs, ibm bug with ppc64 (due to VNC) Mike: glibc reported bug. Monitor refactoring. It seems to be a real memory corruption bug. Rick: misc bugfixes. eggtray icon fixes. working on documentation as well. Nurdin: evenviewer: accessibility, just figure out where a bug was. Then we can write dogtail tests. Suggest dumping WIP on a cvs branch, just to be safe. frysk bugzilla list: on sware: seems like its going to happen soon. please get going on the fc6t3 builds before the weekend!! From cmoller@redhat.com Thu Aug 31 13:36:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 31 Aug 2006 13:36:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog cni/Wait.cxx In-Reply-To: <1157020532.3000.8.camel@dijkstra.wildebeest.org> References: <20060831021346.14715.qmail@sourceware.org> <1157020532.3000.8.camel@dijkstra.wildebeest.org> Message-ID: <44F6E5DC.2010108@redhat.com> Mark Wielaard mumbled something on 08/31/2006 06:35 AM: > Hi Chris, > > On Thu, 2006-08-31 at 02:13 +0000, cmoller@sourceware.org wrote: > >> Log message: >> Added code to send diagnostics to cmoller@redhat.com if the 0xff >> condition is detected. >> >> + // suppress local reporting of any 0xff status >> > > Could you make it so that it also puts a diagnostic for the local user? > I am happy to send you email if it occurs and I happen to see it, even > though I am not in the moller/redhat.com domain. > You mean just leave out the if ((0xff & tail->status) != 0xff) condition on processStatus? Or use some other reporting technique for the local user? My thought was that since it may not be a real frysk error (e.g., it might be a kernel problem) there's no point in bugging the user about it. But if you want to be notified somehow, that's fine with me. If I just omit that conditional, a runtime exception will be thrown. Will that work? > Cheers, > > Mark > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cmoller@redhat.com Thu Aug 31 13:37:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 31 Aug 2006 13:37:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog cni/Wait.cxx In-Reply-To: <1157025510.3000.19.camel@dijkstra.wildebeest.org> References: <20060831021346.14715.qmail@sourceware.org> <1157020532.3000.8.camel@dijkstra.wildebeest.org> <44F6CBBA.4010400@redhat.com> <1157025510.3000.19.camel@dijkstra.wildebeest.org> Message-ID: <44F6E5FA.6040508@redhat.com> Mark Wielaard mumbled something on 08/31/2006 07:58 AM: > Hi Chris, > > On Thu, 2006-08-31 at 07:44 -0400, Chris Moller wrote: > >> Mark Wielaard mumbled something on 08/31/2006 06:35 AM: >> >>> On Thu, 2006-08-31 at 02:13 +0000, cmoller@sourceware.org wrote: >>> >> But if you want to be notified somehow, that's fine with me. If I >> just omit that conditional, a runtime exception will be thrown. Will >> that work? >> > > Yes a RuntimeException is fine. That is precisely what it is, the > runtime (or kernel) is utterly confused. Don't hide that from me. I want > to feel the pain :) > Such masochism! Okay, I'll take out the conditional. > Cheers, > > Mark > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cmoller@redhat.com Thu Aug 31 13:37:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 31 Aug 2006 13:37:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog cni/Wait.cxx In-Reply-To: <1157020532.3000.8.camel@dijkstra.wildebeest.org> References: <20060831021346.14715.qmail@sourceware.org> <1157020532.3000.8.camel@dijkstra.wildebeest.org> Message-ID: <44F6E612.20802@redhat.com> Mark Wielaard mumbled something on 08/31/2006 06:35 AM: > Hi Chris, > > On Thu, 2006-08-31 at 02:13 +0000, cmoller@sourceware.org wrote: > >> Log message: >> Added code to send diagnostics to cmoller@redhat.com if the 0xff >> condition is detected. >> >> + // suppress local reporting of any 0xff status >> > > Could you make it so that it also puts a diagnostic for the local user? > I am happy to send you email if it occurs and I happen to see it, even > though I am not in the moller/redhat.com domain. > You mean just leave out the if ((0xff & tail->status) != 0xff) condition on processStatus? Or use some other reporting technique for the local user? My thought was that since it may not be a real frysk error (e.g., it might be a kernel problem) there's no point in bugging the user about it. But if you want to be notified somehow, that's fine with me. If I just omit that conditional, a runtime exception will be thrown. Will that work? > Cheers, > > Mark > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From ezannoni@redhat.com Thu Aug 31 13:46:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Thu, 31 Aug 2006 13:46:00 -0000 Subject: ppc64 build in rawhide Message-ID: <17654.59142.534110.864652@localhost.redhat.com> FYI: There should now be a ppc64 version of frysk in rawhide, frysk-0.0.1.2006.08.30.rh1-1.fc6.ppc64.rpm From cagney@redhat.com Thu Aug 31 15:05:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 31 Aug 2006 15:05:00 -0000 Subject: frysk-sys/frysk/sys ChangeLog cni/Wait.cxx In-Reply-To: <1157020532.3000.8.camel@dijkstra.wildebeest.org> References: <20060831021346.14715.qmail@sourceware.org> <1157020532.3000.8.camel@dijkstra.wildebeest.org> Message-ID: <44F6FA9C.8050707@redhat.com> Chris, please revert this. The existing code already reported the failure; having frysk silently invoke a "mail" is not acceptable. Andrew Mark Wielaard wrote: > Hi Chris, > > On Thu, 2006-08-31 at 02:13 +0000, cmoller@sourceware.org wrote: > >> Log message: >> Added code to send diagnostics to cmoller@redhat.com if the 0xff >> condition is detected. >> >> + // suppress local reporting of any 0xff status >> > > Could you make it so that it also puts a diagnostic for the local user? > I am happy to send you email if it occurs and I happen to see it, even > though I am not in the moller/redhat.com domain. > > Cheers, > > Mark > > From cagney@redhat.com Thu Aug 31 15:10:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 31 Aug 2006 15:10:00 -0000 Subject: One small patch to fix TestX8664Modify testcase(frysk-core/frysk/proc/TestX8664Modify.java). In-Reply-To: <1156985009.29210.11.camel@YZ_X86_64> References: <1156941616.2807.23.camel@YZ_X86_64> <44F5A836.70809@redhat.com> <1156985009.29210.11.camel@YZ_X86_64> Message-ID: <44F6FBEA.7000009@redhat.com> Yong, I'm unfortunatly not 100% on top of my e-mail at present. Yes cvs rm the now redundant files. Andrew >> This is ok, but as for >> TestRegs, can you merge things (and make certain that the old >> Test tests are deleted). >> > The TestRegs has been checked in two days ago but we didnot delete the > TestI386Regs.java and TestX8664Regs.java. I'm so sorry not to send > email on that to you. I thought you would get to know because frysk-cvs > mail list will inform us by emails after we checked the codes in. Now, > should we delete the redundant files: TestI386Regs.java and > TestX8664Regs.java? > > Best regards > Yong Zheng > > > > From pmuldoon@redhat.com Thu Aug 31 15:23:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 31 Aug 2006 15:23:00 -0000 Subject: Console command, frysk interaction and more Message-ID: <44F6FEE7.3070205@redhat.com> The console is launched via the monitor UI of Frysk. Consequently when you open the console, you will get a CLI. When I type help in the console I get: (frysk) help alias - Create or view user-define commands. defset - Define a named proc/task set. focus - Change current set. set - Change or view a debugger variable. unalias - Create or view user-define commands. undefset - Undefine a named proc/task set. unset - Revert variable value to default. viewset - List members of a proc/task set. whichsets - List all user-defined set to which a proc/task belongs. assign Lhs Expression print Expression what Lhs help quit Can someone define what *set commands are. As the current incarnation of the console is launched via the monitor, and the monitor uses direct library APIs to manipulate the Frysk core, I worry the right-hand, left-hand effect is going on here. Some questions to kick of the conversation: Is a set a session? If I change a set will it change a session? Is the set api calling the session api? If I (sometime down the line) set an observer via the console, will it be reflected in the monitor, and vice versa. Right now they aren't. Should the console stand apart as two separate and unique tools? Lets kick off the discussion Regards Phil From scox@redhat.com Thu Aug 31 15:34:00 2006 From: scox@redhat.com (Stan Cox) Date: Thu, 31 Aug 2006 15:34:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <44F6FEE7.3070205@redhat.com> References: <44F6FEE7.3070205@redhat.com> Message-ID: <1157038491.10612.113.camel@multics.rdu.redhat.com> On Thu, 2006-08-31 at 10:23 -0500, Phil Muldoon wrote: > Can someone define what *set commands are. The requests are documented in the high performance debugging spec at: http://sources.redhat.com/frysk/documentation/hpd.pdf From cagney@redhat.com Thu Aug 31 15:57:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 31 Aug 2006 15:57:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <1157038491.10612.113.camel@multics.rdu.redhat.com> References: <44F6FEE7.3070205@redhat.com> <1157038491.10612.113.camel@multics.rdu.redhat.com> Message-ID: <44F706E4.6050803@redhat.com> I wonder, is there a pdf->html tool around? Having this accessible as part of the web would be nice. Andrew Stan Cox wrote: > On Thu, 2006-08-31 at 10:23 -0500, Phil Muldoon wrote: > > > >> Can someone define what *set commands are. >> > > The requests are documented in the high performance debugging spec at: > http://sources.redhat.com/frysk/documentation/hpd.pdf > > > > From pmuldoon@redhat.com Thu Aug 31 16:02:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 31 Aug 2006 16:02:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <1157038491.10612.113.camel@multics.rdu.redhat.com> References: <44F6FEE7.3070205@redhat.com> <1157038491.10612.113.camel@multics.rdu.redhat.com> Message-ID: <44F707F3.7060704@redhat.com> Stan Cox wrote: > On Thu, 2006-08-31 at 10:23 -0500, Phil Muldoon wrote: > > > >> Can someone define what *set commands are. >> > > The requests are documented in the high performance debugging spec at: > http://sources.redhat.com/frysk/documentation/hpd.pdf > > Great document. It's really well-written. However, the spec that defines it and how that relates to the UI, leaves me thinking that the HPD|Console and the Monitor UI are using distinctly different interfaces to do the same thing. The UI uses direct APIs from the Core to set and unset observers, read registers, and other tasks. The console, using this other interface, is taking a different approach. How/Can we reconcile the two? They are both at the same usage level - they provide the end user a direct means of manipulating the Frysk core. The more I read, the more I think that the console and the monitor should be separate tools (much like ftrace is a separate tool). Right now they only thing they have in common is they both talk directly to the Frysk Core api. Some possibilities are: 1) Define a "proxy" of some form (I use that word with lots of applied caution) that would act as a common clearing house for the console HPD interface, and the direct Frysk Core api interface the monitor uses. I don't like proxies as they crash, add another level of complexity. But it is an "idea". 2) Have the Frysk UI interact with the Frysk Core via the expression parser you are now working on, Stan. This would required a middle-ware rewrite, and we risk going down the path of placing interfaces onto top of the Frysk Core api and robbing it of bandwidth (I worry about the MI effect). 3) The expression parser uses the Frysk UI middle-ware components. 4) Two separate tools, stand alone. Those are just of the top of my head. They might all be wrong, right or there might be lots of other solutions. I'm looking forward to getting the discussion going with the community. Regards Phil From rmoseley@redhat.com Thu Aug 31 17:07:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Thu, 31 Aug 2006 17:07:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <44F706E4.6050803@redhat.com> References: <44F6FEE7.3070205@redhat.com> <1157038491.10612.113.camel@multics.rdu.redhat.com> <44F706E4.6050803@redhat.com> Message-ID: <44F7172D.3020604@redhat.com> Andrew Cagney wrote: > I wonder, is there a pdf->html tool around? Having this accessible as > part of the web would be nice. A dang good question Andrew. When I get through with the Frysk doc I want to put it on the website and would like to have such a tool. I'll ask our old friend Mike Behm if he knows of such. Rick > > Andrew > > Stan Cox wrote: >> On Thu, 2006-08-31 at 10:23 -0500, Phil Muldoon wrote: >> >> >> >>> Can someone define what *set commands are. >>> >> >> The requests are documented in the high performance debugging spec at: >> http://sources.redhat.com/frysk/documentation/hpd.pdf >> >> >> >> > From cmoller@redhat.com Thu Aug 31 18:00:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 31 Aug 2006 18:00:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <44F7172D.3020604@redhat.com> References: <44F6FEE7.3070205@redhat.com> <1157038491.10612.113.camel@multics.rdu.redhat.com> <44F706E4.6050803@redhat.com> <44F7172D.3020604@redhat.com> Message-ID: <44F723C2.7060804@redhat.com> Much better: pdftohtml *http://sourceforge.net/projects/pdftohtml/* Converts to text, not images, and can embed graphics. Rick Moseley mumbled something on 08/31/2006 01:06 PM: > Andrew Cagney wrote: >> I wonder, is there a pdf->html tool around? Having this accessible >> as part of the web would be nice. > A dang good question Andrew. When I get through with the Frysk doc I > want to put it on the website and would like to have such a tool. > I'll ask our old friend Mike Behm if he knows of such. > > Rick >> >> Andrew >> >> Stan Cox wrote: >>> On Thu, 2006-08-31 at 10:23 -0500, Phil Muldoon wrote: >>> >>> >>> >>>> Can someone define what *set commands are. >>>> >>> >>> The requests are documented in the high performance debugging spec at: >>> http://sources.redhat.com/frysk/documentation/hpd.pdf >>> >>> >>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From scox@redhat.com Thu Aug 31 18:02:00 2006 From: scox@redhat.com (Stan Cox) Date: Thu, 31 Aug 2006 18:02:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <44F7172D.3020604@redhat.com> References: <44F6FEE7.3070205@redhat.com> <1157038491.10612.113.camel@multics.rdu.redhat.com> <44F706E4.6050803@redhat.com> <44F7172D.3020604@redhat.com> Message-ID: <1157047386.10612.125.camel@multics.rdu.redhat.com> On Thu, 2006-08-31 at 12:06 -0500, Rick Moseley wrote: > Andrew Cagney wrote: > > I wonder, is there a pdf->html tool around? Having this accessible as > > part of the web would be nice. I tried pdftohtml but depending on options it either produced html that didn't work (no options) or produced a plethora of png files (-p -c). From cmoller@redhat.com Thu Aug 31 18:13:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 31 Aug 2006 18:13:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <1157047386.10612.125.camel@multics.rdu.redhat.com> References: <44F6FEE7.3070205@redhat.com> <1157038491.10612.113.camel@multics.rdu.redhat.com> <44F706E4.6050803@redhat.com> <44F7172D.3020604@redhat.com> <1157047386.10612.125.camel@multics.rdu.redhat.com> Message-ID: <44F726C6.9070502@redhat.com> I found two packages named "pdftohtml," the first one, from freshmeat, IIRC, did exactly as you describe, the second one, from sourceforge, is a completely different thing and worked fine. Stan Cox mumbled something on 08/31/2006 02:03 PM: > On Thu, 2006-08-31 at 12:06 -0500, Rick Moseley wrote: > >> Andrew Cagney wrote: >> >>> I wonder, is there a pdf->html tool around? Having this accessible as >>> part of the web would be nice. >>> > > I tried pdftohtml but depending on options it either produced html that > didn't work (no options) or produced a plethora of png files (-p -c). > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From scox@redhat.com Thu Aug 31 19:59:00 2006 From: scox@redhat.com (Stan Cox) Date: Thu, 31 Aug 2006 19:59:00 -0000 Subject: Console command, frysk interaction and more In-Reply-To: <44F726C6.9070502@redhat.com> References: <44F6FEE7.3070205@redhat.com> <1157038491.10612.113.camel@multics.rdu.redhat.com> <44F706E4.6050803@redhat.com> <44F7172D.3020604@redhat.com> <1157047386.10612.125.camel@multics.rdu.redhat.com> <44F726C6.9070502@redhat.com> Message-ID: <1157054357.10612.140.camel@multics.rdu.redhat.com> On Thu, 2006-08-31 at 14:13 -0400, Chris Moller wrote: > I found two packages named "pdftohtml," the first one, from freshmeat, > IIRC, did exactly as you describe, the second one, from sourceforge, is > a completely different thing and worked fine. Thanks for the pointer Chris. I added the html version to htdocs. From qiyaoltc@cn.ibm.com Fri Sep 1 00:49:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 01 Sep 2006 00:49:00 -0000 Subject: ppc64 build in rawhide In-Reply-To: <17654.59142.534110.864652@localhost.redhat.com> References: <17654.59142.534110.864652@localhost.redhat.com> Message-ID: <20060901004930.GC24582@GreenHouse.cn.ibm.com> On Thu, Aug 31, 2006 at 09:41:26AM -0400, Elena Zannoni wrote: > > FYI: > There should now be a ppc64 version of frysk in rawhide, > frysk-0.0.1.2006.08.30.rh1-1.fc6.ppc64.rpm > > Yep! It could be found on http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc64/os/Fedora/RPMS/frysk-0.0.1.2006.08.30.rh1-1.fc6.ppc64.rpm Thanks Stepan for building ppc64 Frysk and java-gnome packages to RHEL5 and Fedora. -- Yao Qi From woodzltc@cn.ibm.com Fri Sep 1 02:44:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 01 Sep 2006 02:44:00 -0000 Subject: TestI386Regs.java and TestX8664Regs.java are deleted now In-Reply-To: <44F6FBEA.7000009@redhat.com> References: <1156941616.2807.23.camel@YZ_X86_64> <44F5A836.70809@redhat.com> <1156985009.29210.11.camel@YZ_X86_64> <44F6FBEA.7000009@redhat.com> Message-ID: <44F79E6E.7080201@cn.ibm.com> Andrew Cagney wrote: > Yong, I'm unfortunatly not 100% on top of my e-mail at present. > Yes cvs rm the now redundant files. Yong encountered some problem with his public key. So I helped check in that patch. Please use the general TestRegs afterwards. Regards - Wu Zhou From woodzltc@cn.ibm.com Fri Sep 1 04:01:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 01 Sep 2006 04:01:00 -0000 Subject: frysk mtg minutes 20060829 In-Reply-To: <17654.58091.990245.779626@localhost.redhat.com> References: <17654.58091.990245.779626@localhost.redhat.com> Message-ID: <44F7B091.4090003@cn.ibm.com> Elena Zannoni wrote: > > Stepan: Enable the ppc64 build of Frysk in RHEL5 and Fedora. Add the > ppc64 java-gnome packages to RHEL5 and Fedora. Thanks for that. We are updating our ppc64 box to test this. > > Libunwind Alex: adding remote features: shouldn't be too hard, but not > being able to see how to offer them. If you are remote, the user is > supposed to tell libunwind how to use the information. Possibly export > some functions that the users can use as callback. Cagney says that > the problem has been resolved for ia64. Ia64 uses itanium unwind info, > which is in the remote process. Callback to read from remote memory > were put in place when JeffJ made gdb use libunwind. Also need for > callbacks to free remote memory that it allocates. It now just > allocates local memory. But this memory will need to be freed > explicitly once it is allocated remotely. Alex says that you need to > cache information (didn't catch that, sorry). Is there any code available right now? If yes, we would be very happy to have a look at that first. > Mosberger is out on vacation until the end of august, which it may > mean he is out until after labor day :-( That is unfortunate. BTW, when is your labor day? We want to have a rough grasp about when most of you are on vacation. At China, we will have a one-week vacation from Oct, 1 to Oct, 10 (that is our national days). Most of us will take a break in that period. > utrace: Roland nothing to report. Chris: still not able to track down that > 0xff problem. Will use heavy hammer of adding log messages. any detail about this 0xff problem? > Mark: making progress. Trying to cleanup and writing tests. Gave up > on rawhide, using fc5 as devel platform. We met some problem on rawhide too. On ppc64, FryskGui just reports SEGV and doesn't show anything else. > > Tim: register window cleanup for floating point registers. Interface > issues because you need to be able to switch between different ways to > read the registers (mmx regs). > > Andrew: done some workarounds in the code for kernel bugs. > Mike: done fix for double parent/ghost > > Stan: can get dwarf info for current frame. Clean up the patch and > post it. Then use libunwind to be able to get the dwarf info for other > frames is next. Also writing tests for this part of the code. > Extending on the Java interface for libdwarf that Adam started. > Not sure how the gui is going to use this code though. > > Phil: rhel5, kernel bugs, ibm bug with ppc64 (due to VNC) Thanks for the excellent problem determination work, Phil! This isn't a blocker any more. But I'd like to open a bug against the vnc server now. Which is the proper way to handle this? on the upstream site, or on the sourceware bugzilla? > > Mike: glibc reported bug. Monitor refactoring. It seems to be a real > memory corruption bug. > > Rick: misc bugfixes. eggtray icon fixes. > working on documentation as well. > > Nurdin: evenviewer: accessibility, just figure out where a bug was. > Then we can write dogtail tests. Suggest dumping WIP on a cvs branch, > just to be safe. > > frysk bugzilla list: on sware: seems like its going to happen soon. > > please get going on the fc6t3 builds before the weekend!! We will try fc6 test3 once it is out. If it is stable enough, we will switch our development to that. Regards - Wu Zhou From mark@klomp.org Fri Sep 1 07:34:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 01 Sep 2006 07:34:00 -0000 Subject: frysk mtg minutes 20060829 In-Reply-To: <44F7B091.4090003@cn.ibm.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> Message-ID: <1157096038.3062.7.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-09-01 at 12:01 +0800, Wu Zhou wrote: > BTW, when is your labor day? We want to have a rough grasp about when > most of you are on vacation. > At China, we will have a one-week vacation from Oct, 1 to Oct, 10 > (that is our national days). Most of us will take a break in that > period. I always thought labor-day was May 1st, which it is in the Netherlands (but it isn't a vacation day, to celebrate labor, you surely should work!) But in the USA it is on Monday, September 4th. I don't know what they will do in Canada. > > utrace: Roland nothing to report. Chris: still not able to track down that > > 0xff problem. Will use heavy hammer of adding log messages. > > any detail about this 0xff problem? http://sourceware.org/bugzilla/show_bug.cgi?id=3091 Cheers, Mark From rmoseley@redhat.com Fri Sep 1 11:38:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Fri, 01 Sep 2006 11:38:00 -0000 Subject: frysk mtg minutes 20060829 In-Reply-To: <44F7B091.4090003@cn.ibm.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> Message-ID: <44F81BAE.30703@redhat.com> Wu Zhou wrote: > Elena Zannoni wrote: >> >> Stepan: Enable the ppc64 build of Frysk in RHEL5 and Fedora. Add the >> ppc64 java-gnome packages to RHEL5 and Fedora. > > Thanks for that. We are updating our ppc64 box to test this. >> >> Libunwind Alex: adding remote features: shouldn't be too hard, but not >> being able to see how to offer them. If you are remote, the user is >> supposed to tell libunwind how to use the information. Possibly export >> some functions that the users can use as callback. Cagney says that >> the problem has been resolved for ia64. Ia64 uses itanium unwind info, >> which is in the remote process. Callback to read from remote memory >> were put in place when JeffJ made gdb use libunwind. Also need for >> callbacks to free remote memory that it allocates. It now just >> allocates local memory. But this memory will need to be freed >> explicitly once it is allocated remotely. Alex says that you need to >> cache information (didn't catch that, sorry). > > Is there any code available right now? If yes, we would be very happy > to have a look at that first. > >> Mosberger is out on vacation until the end of august, which it may >> mean he is out until after labor day :-( > > That is unfortunate. > > BTW, when is your labor day? We want to have a rough grasp about when > most of you are on vacation. At China, we will have a one-week > vacation from Oct, 1 to Oct, 10 (that is our national days). Most of > us will take a break in that period. > >> utrace: Roland nothing to report. Chris: still not able to track >> down that >> 0xff problem. Will use heavy hammer of adding log messages. > > any detail about this 0xff problem? > >> Mark: making progress. Trying to cleanup and writing tests. Gave up >> on rawhide, using fc5 as devel platform. > > We met some problem on rawhide too. On ppc64, FryskGui just reports > SEGV and doesn't show anything else. >> >> Tim: register window cleanup for floating point registers. Interface >> issues because you need to be able to switch between different ways to >> read the registers (mmx regs). >> >> Andrew: done some workarounds in the code for kernel bugs. >> Mike: done fix for double parent/ghost >> >> Stan: can get dwarf info for current frame. Clean up the patch and >> post it. Then use libunwind to be able to get the dwarf info for other >> frames is next. Also writing tests for this part of the code. >> Extending on the Java interface for libdwarf that Adam started. >> Not sure how the gui is going to use this code though. >> >> Phil: rhel5, kernel bugs, ibm bug with ppc64 (due to VNC) > > Thanks for the excellent problem determination work, Phil! This isn't > a blocker any more. But I'd like to open a bug against the vnc server > now. Which is the proper way to handle this? on the upstream site, > or on the sourceware bugzilla? Please file a bug upstream, but also file a tracker bug in sourceware bugzilla with a URL pointing to the upstream bug.. Rick > >> >> Mike: glibc reported bug. Monitor refactoring. It seems to be a real >> memory corruption bug. >> >> Rick: misc bugfixes. eggtray icon fixes. >> working on documentation as well. >> >> Nurdin: evenviewer: accessibility, just figure out where a bug was. >> Then we can write dogtail tests. Suggest dumping WIP on a cvs branch, >> just to be safe. >> >> frysk bugzilla list: on sware: seems like its going to happen soon. >> >> please get going on the fc6t3 builds before the weekend!! > > We will try fc6 test3 once it is out. If it is stable enough, we will > switch our development to that. > > Regards > - Wu Zhou From cmoller@redhat.com Fri Sep 1 11:44:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Fri, 01 Sep 2006 11:44:00 -0000 Subject: frysk mtg minutes 20060829 In-Reply-To: <44F7B091.4090003@cn.ibm.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> Message-ID: <44F81CFA.8020004@redhat.com> Wu Zhou mumbled something on 09/01/2006 12:01 AM: > >> utrace: Roland nothing to report. Chris: still not able to track >> down that >> 0xff problem. Will use heavy hammer of adding log messages. > > any detail about this 0xff problem? I am utterly unable to reproduce the problem, but did find a possibility. See the last comment in the bz: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203056 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From mark@klomp.org Fri Sep 1 12:36:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 01 Sep 2006 12:36:00 -0000 Subject: Test and fix for syscall observer adding (bug #3147) Message-ID: <1157114157.3062.16.camel@dijkstra.wildebeest.org> Hi, Here is a test and a fix for bug #3147. This code needs to be redesigned to also handle CodeObservers. I'll expand the testcase to also check that and other interactions with syscalls/signals/breakpoints. But this fix should be enough for now to make bug #3147 not happen anymore. 2006-09-01 Mark Wielaard * TaskState.java (runningInSyscall): Handle adding of Observer and SyscallObserver. * TestSyscallRunning.java: New file. 2006-09-01 Mark Wielaard * funit-syscall-running.c: New test prog. Phil, I wasn't able to actually trigger the bug as you described in the bug report, but I believe my testcase (which fails before and succeeds after this patch) is what actually happens. Can you try this? I have committed it. Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: runninginsyscall-add-observer.patch Type: text/x-patch Size: 14547 bytes Desc: not available URL: From mark@klomp.org Fri Sep 1 13:26:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 01 Sep 2006 13:26:00 -0000 Subject: Test and fix for syscall observer adding (bug #3147) In-Reply-To: <1157114157.3062.16.camel@dijkstra.wildebeest.org> References: <1157114157.3062.16.camel@dijkstra.wildebeest.org> Message-ID: <1157117181.6659.4.camel@hermans.wildebeest.org> Hi, On Fri, 2006-09-01 at 14:35 +0200, Mark Wielaard wrote: > Here is a test and a fix for bug #3147. I removed the test since it fails to compile on x86. Sorry about that. ../../frysk/frysk-core/frysk/proc/TestSyscallRunning.java:243: error: No variable ?SYSaccept? defined in type ?frysk.sys.SyscallNum?. if (syscallNum == SyscallNum.SYSaccept) ^ 2006-09-01 Mark Wielaard * TestSyscallRunning.java: Removed doesn't compile on x86. As soon as SyscallNum is fixed, I'll add it back. Cheers, Mark From cmoller@redhat.com Fri Sep 1 15:19:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Fri, 01 Sep 2006 15:19:00 -0000 Subject: 0xff bug Message-ID: <44F84F6E.2090704@redhat.com> Turns out I actually did get hit by this bug about two weeks ago, but I expect wasn't looking for it at the time. Anyway, my one and only personal hit has one thing in common with the only other log of it I've seen, the one on the bz. The thing both of these hits have in common is the following sequence: {frysk.proc.LinuxTask@10fe4e0,pid=4715,tid=4715,state=running} handleTerminatingEvent {frysk.proc.LinuxTask@10fe4e0,pid=4715,tid=4715,state=running} sendContinue {frysk.proc.LinuxHost$PollWaitOnSigChld@55bb40,sig=Sig_CHLD} execute frysk.sys.Wait pid 4715 status 0xff frysk.sys.Wait pid 0 errno 0 with different values for the pid, etc. This looks to me like a process has been terminated (the handleTerminatingEvent thing) but then continued (the sendContinue thing). I may be mis-reading this, but it would be handy if everyone could check their frysk logs for that sequence and let me know if, (a) it occurs, and (b) if a handleTerminatingEvent/sendContinue sequence inevitably leads to the 0xff. cm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cmoller@redhat.com Fri Sep 1 17:13:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Fri, 01 Sep 2006 17:13:00 -0000 Subject: 0xff bug In-Reply-To: <44F84F6E.2090704@redhat.com> References: <44F84F6E.2090704@redhat.com> Message-ID: <44F86A23.9040002@redhat.com> Hmm... Wild guess: is it possible the handleTerminatingEvent/sendContinue sequence is another manifestation of the out-of-order stuff observed in bz 202115? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202115 cm Chris Moller mumbled something on 09/01/2006 11:19 AM: > Turns out I actually did get hit by this bug about two weeks ago, but I > expect wasn't looking for it at the time. Anyway, my one and only > personal hit has one thing in common with the only other log of it I've > seen, the one on the bz. > > The thing both of these hits have in common is the following sequence: > > {frysk.proc.LinuxTask@10fe4e0,pid=4715,tid=4715,state=running} > handleTerminatingEvent > {frysk.proc.LinuxTask@10fe4e0,pid=4715,tid=4715,state=running} sendContinue > {frysk.proc.LinuxHost$PollWaitOnSigChld@55bb40,sig=Sig_CHLD} execute > frysk.sys.Wait pid 4715 status 0xff > frysk.sys.Wait pid 0 errno 0 > > with different values for the pid, etc. > > This looks to me like a process has been terminated (the > handleTerminatingEvent thing) but then continued (the sendContinue thing). > > I may be mis-reading this, but it would be handy if everyone could check > their frysk logs for that sequence and let me know if, (a) it occurs, > and (b) if a handleTerminatingEvent/sendContinue sequence inevitably > leads to the 0xff. > > cm > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From mark@klomp.org Fri Sep 1 21:01:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 01 Sep 2006 21:01:00 -0000 Subject: Test and fix for syscall observer adding (bug #3147) In-Reply-To: <1157117181.6659.4.camel@hermans.wildebeest.org> References: <1157114157.3062.16.camel@dijkstra.wildebeest.org> <1157117181.6659.4.camel@hermans.wildebeest.org> Message-ID: <1157144484.6659.18.camel@hermans.wildebeest.org> Hi, On Fri, 2006-09-01 at 15:26 +0200, Mark Wielaard wrote: > On Fri, 2006-09-01 at 14:35 +0200, Mark Wielaard wrote: > > Here is a test and a fix for bug #3147. > > I removed the test since it fails to compile on x86. Sorry about that. > > ../../frysk/frysk-core/frysk/proc/TestSyscallRunning.java:243: error: No > variable ?SYSaccept? defined in type ?frysk.sys.SyscallNum?. > if (syscallNum == SyscallNum.SYSaccept) > ^ > 2006-09-01 Mark Wielaard > > * TestSyscallRunning.java: Removed doesn't compile on x86. > > As soon as SyscallNum is fixed, I'll add it back. This is trickier than I thought. On x86_64 there is a real accept() syscall (#43). But on x86 there is one syscall socketcall (#102) that takes an argument to indicate whether the user wants either the socket(), bind(), connect(), listen(), accept(), etc. "subcalls". For the testcase I can of course do some tricks and see if accept() is a syscall or, if not, whether socketcall() is available and then select based on the first argument of the syscall to see if it really is accept (#5). But this seems 1) fragile and 2) looks like a general problem people will have when using Syscall Observers. Question is if we want to provide the user with the raw syscalls or try to present the user with the same syscall (names) on all platforms. Or is this a task for something higher level? strace for example presents the socketcall subcalls as if they are real system calls on systems that don't have real bind(), accept(), listen(), connect() syscalls. Ideas? Cheers, Mark From qiyaoltc@cn.ibm.com Sun Sep 3 07:43:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Sun, 03 Sep 2006 07:43:00 -0000 Subject: Rewrite Disassembler and enable TestOpcodes for PPC64. Message-ID: <20060903074353.GA13314@GreenHouse.cn.ibm.com> Some changes are applied to make Disassembler output instructions one by one, and TestOpcodes are modified correspondingly for disassembler test on different architectures, including x86, x86_64, and ppc64. 2006-09-03 Yao Qi * tests/TestOpcodes.java: Enable test for PPC64. * tests/DummyByteBuffer.java: Set byte array different values on different architectures. * cni/Disassembler.cxx (disassemble): Make disassembler output in a AT&T format for i386 and X86_64. Apply GNU formating. * Instruction.java (Instruction): New construction. New member to save instruction length. Apply GNU formating. * Disassembler.java (setCurrentInstruction): append instruction to avoid overwrite. (setCurrentInstructionLength) : New method to set the length of instruction. Tested this patch on x86/x86_64/ppc64 with frysk cvs head. OK to commit? Thanks! -- Yao Qi -------------- next part -------------- Index: frysk-imports/lib/opcodes/Disassembler.java =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/opcodes/Disassembler.java,v retrieving revision 1.4 diff -u -r1.4 Disassembler.java --- frysk-imports/lib/opcodes/Disassembler.java 14 Jul 2006 14:51:29 -0000 1.4 +++ frysk-imports/lib/opcodes/Disassembler.java 3 Sep 2006 06:53:31 -0000 @@ -59,7 +59,7 @@ } public LinkedList disassembleInstructions (long address, long count) - throws OpcodesException + throws OpcodesException { this.isnList = new LinkedList(); current = new Instruction(); @@ -79,7 +79,15 @@ // It is not private because it is called from CNI protected void setCurrentInstruction (String inst) { - current.instruction = inst; + // libopcdes will call this function for more than one time to print + // one instruction. So append INST to INSTRUCTION to avoid overwrite. + current.instruction += inst; + } + // THIS SHOULD NOT BE CALLED FROM JAVA! + // It is not private because it is called from CNI + protected void setCurrentInstructionLength (int len) + { + current.length = len; } // THIS SHOULD NOT BE CALLED FROM JAVA! Index: frysk-imports/lib/opcodes/Instruction.java =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/opcodes/Instruction.java,v retrieving revision 1.2 diff -u -r1.2 Instruction.java --- frysk-imports/lib/opcodes/Instruction.java 15 May 2006 20:31:42 -0000 1.2 +++ frysk-imports/lib/opcodes/Instruction.java 3 Sep 2006 06:53:32 -0000 @@ -38,12 +38,21 @@ // exception. package lib.opcodes; -public class Instruction { +public class Instruction +{ + public long address; + public int length; + public String instruction; - public long address; - public String instruction; - - public String toString(){ - return "0x"+Long.toHexString(address)+"\t"+instruction; - } + public String toString() + { + return "0x"+Long.toHexString(address)+"\t"+instruction; + } + + Instruction() + { + address = -1; + length = 0; + instruction = new String(); + } } Index: frysk-imports/lib/opcodes/cni/Disassembler.cxx =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/opcodes/cni/Disassembler.cxx,v retrieving revision 1.6 diff -u -r1.6 Disassembler.cxx --- frysk-imports/lib/opcodes/cni/Disassembler.cxx 14 Jul 2006 14:51:29 -0000 1.6 +++ frysk-imports/lib/opcodes/cni/Disassembler.cxx 3 Sep 2006 06:53:33 -0000 @@ -64,7 +64,7 @@ // reads number of bytes from the byte buffer int read_from_byte_buffer(bfd_vma memaddr, bfd_byte* myadd, unsigned int length, - struct disassemble_info *info); + struct disassemble_info *info); // throws an OpcodesException void error_func(int status, bfd_vma memaddr, struct disassemble_info *info); @@ -79,79 +79,84 @@ lib::opcodes::Disassembler::disassemble (jlong address, jlong instructions) { - disassemble_info disasm_info; - int (*disasm_func) (bfd_vma, disassemble_info*); + disassemble_info disasm_info; + int (*disasm_func) (bfd_vma, disassemble_info*); + int instr_length; - ::init_disassemble_info (&disasm_info, (void*) this, save_instruction); + ::init_disassemble_info (&disasm_info, (void*) this, save_instruction); - disasm_info.flavour = bfd_target_unknown_flavour; + disasm_info.flavour = bfd_target_unknown_flavour; #ifdef __x86_64__ - disasm_info.arch = bfd_arch_i386; - disasm_info.mach = bfd_mach_x86_64; - disasm_func = &(::print_insn_i386_intel); + disasm_info.arch = bfd_arch_i386; + disasm_info.mach = bfd_mach_x86_64; + disasm_func = &(::print_insn_i386_att); #elif defined (__i386__) - disasm_info.arch = bfd_arch_i386; - disasm_info.mach = bfd_mach_i386_i386; - disasm_func = &(::print_insn_i386_intel); + disasm_info.arch = bfd_arch_i386; + disasm_info.mach = bfd_mach_i386_i386; + disasm_func = &(::print_insn_i386_att); #elif defined (__powerpc64__) - disasm_info.arch = bfd_arch_powerpc; - disasm_info.mach = bfd_mach_ppc64; - disasm_func = &(::print_insn_big_powerpc); + disasm_info.arch = bfd_arch_powerpc; + disasm_info.mach = bfd_mach_ppc64; + disasm_func = &(::print_insn_big_powerpc); #elif defined (__powerpc__) - disasm_info.arch = bfd_arch_powerpc; - disasm_info.mach = bfd_mach_ppc; - disasm_func = &(::print_insn_big_powerpc); + disasm_info.arch = bfd_arch_powerpc; + disasm_info.mach = bfd_mach_ppc; + disasm_func = &(::print_insn_big_powerpc); #elif defined (__ia64__) - disasm_info.arch = bfd_arch_ia64; - disasm_info.mach = bfd_mach_ia64_elf64; // TODO: which mach? elf32 or elf64? - disasm_func =&(::print_insn_ia64); + disasm_info.arch = bfd_arch_ia64; + disasm_info.mach = bfd_mach_ia64_elf64; // TODO: which mach? elf32 or elf64? + disasm_func =&(::print_insn_ia64); #elif defined (__s390__) - disasm_info.arch = bfd_arch_s390; - disasm_info.mach = bfd_mach_s390_31; - disasm_func = &(::print_insn_s390); + disasm_info.arch = bfd_arch_s390; + disasm_info.mach = bfd_mach_s390_31; + disasm_func = &(::print_insn_s390); #elif defined (__s390x__) - disasm_info.arch = bfd_arch_s390; - disasm_info.mach = bfd_mach_s390_64; - disasm_func = &(::print_insn_s390); + disasm_info.arch = bfd_arch_s390; + disasm_info.mach = bfd_mach_s390_64; + disasm_func = &(::print_insn_s390); #endif - if (!disasm_func) - throw new lib::opcodes::OpcodesException( - JvNewStringUTF("Error: Unsupported architechture")); + if (!disasm_func) + throw new lib::opcodes::OpcodesException(JvNewStringUTF("Error: Unsupported architechture")); - disasm_info.read_memory_func = read_from_byte_buffer; - disasm_info.memory_error_func = error_func; - disasm_info.print_address_func = print_addr; - - bfd_vma current_address = (bfd_vma) address; - - for (int i = 0; i < instructions; i++) - { - this->setCurrentAddress(current_address); - current_address += disasm_func(current_address, &disasm_info); - this->moveToNext(); - } + disasm_info.read_memory_func = read_from_byte_buffer; + disasm_info.memory_error_func = error_func; + disasm_info.print_address_func = print_addr; + + bfd_vma current_address = (bfd_vma) address; + + for (int i = 0; i < instructions; i++) + { + this->setCurrentAddress(current_address); + instr_length = disasm_func(current_address, &disasm_info); + current_address += instr_length; + + this->setCurrentInstructionLength(instr_length); + this->moveToNext(); + } } /* * Instead of copying memory from memaddr to myadd, we get the section * starting at memaddr in the ByteBuffer. */ -int read_from_byte_buffer (bfd_vma memaddr, bfd_byte* myadd, unsigned int length, - struct disassemble_info *info) +int read_from_byte_buffer (bfd_vma memaddr, bfd_byte* myadd, + unsigned int length, + struct disassemble_info *info) { - lib::opcodes::Disassembler *obj = (lib::opcodes::Disassembler*) info->stream; - inua::eio::ByteBuffer *buffer = obj->buffer; - - char tmp[length]; - for(unsigned int i = 0; i < length; i++){ - long offset = ((long) memaddr) + i; - tmp[i] = (char) buffer->getByte (offset); - } - - memcpy ((void*) myadd, (void*) tmp, length); - - return 0; + lib::opcodes::Disassembler *obj = (lib::opcodes::Disassembler*) info->stream; + inua::eio::ByteBuffer *buffer = obj->buffer; + + char tmp[length]; + for(unsigned int i = 0; i < length; i++) + { + long offset = ((long) memaddr) + i; + tmp[i] = (char) buffer->getByte (offset); + } + + memcpy ((void*) myadd, (void*) tmp, length); + + return 0; } /* @@ -159,9 +164,12 @@ */ void error_func (int status, bfd_vma memaddr, struct disassemble_info *info) { - throw new lib::opcodes::OpcodesException( - JvNewStringUTF("Error occured while disassembling."), (jint) status, (jlong) memaddr - ); + throw new + lib::opcodes::OpcodesException( + JvNewStringUTF("Error occured while disassembling."), + (jint) status, + (jlong) memaddr + ); } void print_addr (bfd_vma addr, struct disassemble_info *info) {} @@ -171,23 +179,24 @@ */ int save_instruction (void* disassembler, const char *args, ...) { - lib::opcodes::Disassembler* obj = (lib::opcodes::Disassembler*) disassembler; - - va_list ap; - ::va_start (ap, args); - char * mystr; - if(::vasprintf (&mystr, args, ap) > 0){ - obj->setCurrentInstruction (JvNewStringUTF (mystr)); - ::free (mystr); - } - else - { - throw new lib::opcodes::OpcodesException( - JvNewStringUTF("Could not parse variable argument list")); - } - ::va_end(ap); + lib::opcodes::Disassembler* obj = (lib::opcodes::Disassembler*) disassembler; - int len = strlen (mystr); + va_list ap; + ::va_start (ap, args); + char * mystr; + if(::vasprintf (&mystr, args, ap) > 0) + { + obj->setCurrentInstruction (JvNewStringUTF (mystr)); + ::free (mystr); + } + else + { + throw new + lib::opcodes::OpcodesException(JvNewStringUTF("Could not parse variable argument list")); + } + ::va_end(ap); - return len; + int len = strlen (mystr); + + return len; } Index: frysk-imports/lib/opcodes/tests/DummyByteBuffer.java =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/opcodes/tests/DummyByteBuffer.java,v retrieving revision 1.2 diff -u -r1.2 DummyByteBuffer.java --- frysk-imports/lib/opcodes/tests/DummyByteBuffer.java 24 May 2006 19:07:27 -0000 1.2 +++ frysk-imports/lib/opcodes/tests/DummyByteBuffer.java 3 Sep 2006 06:53:33 -0000 @@ -39,25 +39,68 @@ package lib.opcodes.tests; import inua.eio.ByteBuffer; +import frysk.imports.Build; -public class DummyByteBuffer extends ByteBuffer { +public class DummyByteBuffer + extends ByteBuffer +{ - private byte[] bytes = {0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7}; - - public DummyByteBuffer(){ - super(0, 8); - } - - protected int peek(long caret) { - if(caret < bytes.length && caret > 0) - return bytes[(int) caret]; - - return -1; - } - - protected void poke(long caret, int val) { - if(caret < bytes.length && caret > 0) - bytes[(int) caret] = (byte) val; - } + private byte bytes[]; + + public DummyByteBuffer() + { + super(0, 8); + if (Build.BUILD_ARCH.indexOf("powerpc") != - 1) + { + bytes = new byte[] + { + 0x4e, (byte)0x80, 0x04, 0x20, // bctr + 0x44, 0x00, 0x00, 0x02, // sc + 0x4e, (byte)0x80, 0x00, 0x20, // blr + 0x60, 0x00, 0x00, 0x00, // nop + 0x38, 0x00, 0x00, 0x02, // li r0,2 + 0x39, (byte)0x8c, 0x03, 0x68, // addi r12,r12,872 + 0x38, 0x21, 0x00, 0x70, // addi r1,r1,112 + (byte)0x7d, 0x69, 0x03, (byte)0xa6, // mtctr r11 + (byte)0x78, (byte)0xa5, 0x26, (byte) 0xc6 // rldicr r5,r5,36,27 + }; + + } + else if (Build.BUILD_ARCH.indexOf("_64") != - 1) + { + bytes = new byte[] + { + 0, 1, // add %al,(%rcx) + 2, 3, // add (%rbx),%al + 4, 5, // add $0x5,%al + 6, // (bad) + 7 // (bad) + }; + } + else + { + bytes = new byte[] + { + 0, 1, // add %al,(%ecx) + 2, 3, // add (%ebx),$al + 4, 5, // add $0x5,%al + 6, // push %es + 7 // pop %es + }; + } + } + + protected int peek(long caret) + { + if(caret < bytes.length && caret >= 0) + return bytes[(int) caret]; + return -1; + } + + protected void poke(long caret, int val) + { + if(caret < bytes.length && caret >= 0) + bytes[(int) caret] = (byte) val; + } } Index: frysk-imports/lib/opcodes/tests/TestOpcodes.java =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/opcodes/tests/TestOpcodes.java,v retrieving revision 1.10 diff -u -r1.10 TestOpcodes.java --- frysk-imports/lib/opcodes/tests/TestOpcodes.java 28 Aug 2006 17:36:37 -0000 1.10 +++ frysk-imports/lib/opcodes/tests/TestOpcodes.java 3 Sep 2006 06:53:33 -0000 @@ -51,17 +51,10 @@ import frysk.imports.Build; public class TestOpcodes - extends TestCase + extends TestCase { - /* - * Note: this test is expected to fail on anything but i386 for the time - * being. TODO: come up with a way of doing the correct assertEquals for other - * archs - */ public void testDisassembler () { - if (brokenPpcXXX(2712)) - return; ByteBuffer buffer = new DummyByteBuffer(); final int numInstructions = 16; @@ -81,39 +74,62 @@ assertNotNull(list); assertEquals(list.size(), numInstructions); - String[] addrs = { "0", "2", "4", "6", "7", "8", "a", "c", "e", "f", "10", - "12", "14", "16", "17", "18" }; + String[] insts = new String[0]; + // Address for DummyByteBuffer is started at 0x00. + int address = 0; - String[] insts; - - boolean is64 = Build.BUILD_ARCH.indexOf("_64") != - 1; - - if (! is64) + // for powerpc and powerpc64. + if (Build.BUILD_ARCH.indexOf("powerpc") != - 1) { - insts = new String[] { "DWORD PTR [ecx]", "BYTE PTR [ebx]", "0x5", - "es", "es", "al", "BYTE PTR [ebx]", "0x5", "es", - "es", "al", "BYTE PTR [ebx]", "0x5", "es", "es", - "al" }; - + insts = new String[] + { + "bctr", + "sc", + "blr", + "nop", + "li r0,2", + "addi r12,r12,872", + "addi r1,r1,112", + "mtctr r11", + "rldicr r5,r5,36,27" + }; } - else + // for X86_64. + else if (Build.BUILD_ARCH.indexOf("_64") != - 1) { - insts = new String[] { "DWORD PTR [rcx]", "BYTE PTR [rbx]", "0x5", - "(bad) ", "(bad) ", "al", "BYTE PTR [rbx]", - "0x5", "(bad) ", "(bad) ", "al" }; + insts = new String[] + { + "add %al,(%rcx)", + "add (%rbx),%al", + "add $0x5,%al", + "(bad)", + "(bad)" + }; + } + // for X86. + else if(Build.BUILD_ARCH.indexOf("86") != - 1) + { + insts = new String[] + { "add %al,(%ecx)", + "add (%ebx),%al", + "add $0x5,%al", + "push %es", + "pop %es", + }; } assertNotNull(insts); - int instCount = is64 ? 11 : 16; - - for (int i = 0; i < instCount; i++) + for (int i = 0; i < insts.length; i++) { Instruction inst = (Instruction) list.get(i); assertNotNull(inst); - assertEquals(addrs[i], Long.toHexString(inst.address)); - assertEquals(insts[i], inst.instruction); + assertEquals(address, inst.address); + // Remve tailing whiespace before compare. + assertEquals(insts[i], inst.instruction.trim()); + + address += inst.length; } } } From aoliva@redhat.com Mon Sep 4 04:08:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Mon, 04 Sep 2006 04:08:00 -0000 Subject: remote dwarf info using libunwind (was: Re: frysk mtg minutes 20060829) In-Reply-To: <44F7B091.4090003@cn.ibm.com> (Wu Zhou's message of "Fri, 01 Sep 2006 12:01:21 +0800") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> Message-ID: On Sep 1, 2006, Wu Zhou wrote: > Elena Zannoni wrote: >> Libunwind Alex: adding remote features: shouldn't be too hard, but >> not >> being able to see how to offer them. If you are remote, the user is >> supposed to tell libunwind how to use the information. Possibly export >> some functions that the users can use as callback. Cagney says that >> the problem has been resolved for ia64. Ia64 uses itanium unwind info, >> which is in the remote process. Callback to read from remote memory >> were put in place when JeffJ made gdb use libunwind. Also need for >> callbacks to free remote memory that it allocates. It now just >> allocates local memory. But this memory will need to be freed >> explicitly once it is allocated remotely. Alex says that you need to >> cache information (didn't catch that, sorry). > Is there any code available right now? If yes, we would be very happy to have a look at that first. Here's the patch I've just completed, that works on x86, and fixes a potential libunwind memory leak while at that. As it turns out, libunwind already has all that we need, we were just missing the proper way to use it. dwarf_find_proc_info() was not it, since it's specifically designed to operate on the local process. Part of the libunwind-ptrace interface offers access to everything we need as far as locating unwind tables et al is concerned, while still using our own callbacks to interact with the process using ptrace or whatever. I'm not sure why we don't just bite the bullet and use all of the libunwind interface (it looks like it would be much simpler and would get us what we want), but I figured I wouldn't remove any such code for now. Ok to install the patch in bug 3070, attached below for reference? -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-dwarf-find-info-4.patch Type: text/x-patch Size: 20063 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From zhengyo@cn.ibm.com Mon Sep 4 07:29:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Mon, 04 Sep 2006 07:29:00 -0000 Subject: One patch to fix the TestX8664Modify case and merge TestModify into one case. Message-ID: <1157352603.10315.31.camel@YZ_X86_64> hi, In frysk-core, there are two platform specific test cases: TestX8664Modify.java and TestI386Modify.java. As for the TestX8664Modify, we submitted one patch to fix the problems in it, which can be read here: http://sources.redhat.com/ml/frysk/2006-q3/msg00333.html. In this patch, all modifications mentioned above are included, and one new PPC64 specific case TestPPC64Modify is added. Just as Andrew said, it's better to merge all TestRegs into one case. So we do the same to TestModify cases. 2006-09-04 Yong Zheng * frysk-core/Makefile.am: Add funit-ppc64-modify test program. * frysk-core/frysk/proc/TestRegMemModify.java: New file to add PPC64 specific case and merge TestModify into one case. * frysk-core/frysk/pkglibexecdir/funit-ppc64-modify.S: New PPC64 specific program * frysk-core/frysk/pkglibexecdir/funit-x8664-modify.S: Correct the syscall number on X8664 and do some modifications to keep synch with TestRegMemModify. Rebuild frysk based on the cvs head(09-04) and tested. Please review it. And if no any objection, we will check it in later. Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_merge_modify_latest.patch Type: text/x-patch Size: 27065 bytes Desc: not available URL: From woodzltc@cn.ibm.com Mon Sep 4 10:16:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 04 Sep 2006 10:16:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> Message-ID: <44FBFCE2.8030505@cn.ibm.com> Alexandre Oliva wrote: > Here's the patch I've just completed, that works on x86, and fixes a > potential libunwind memory leak while at that. > > As it turns out, libunwind already has all that we need, we were just > missing the proper way to use it. dwarf_find_proc_info() was not it, > since it's specifically designed to operate on the local process. > Part of the libunwind-ptrace interface offers access to everything we > need as far as locating unwind tables et al is concerned, while still > using our own callbacks to interact with the process using ptrace or > whatever. I am not sure too why we didn't use libunwind-ptrace.a directly before. One reason might be that it is not really a part of libunwind API. But my point is, as long as it is general enough, why can't we make it part of libunwind API? > I'm not sure why we don't just bite the bullet and use all > of the libunwind interface (it looks like it would be much simpler and > would get us what we want), but I figured I wouldn't remove any such > code for now. > + > +void > +lib::unwind::StackTraceCreator::unwind_destroy (unwargs *args) > +{ > + unw_destroy_addr_space ((unw_addr_space_t)args->unwas); > + args->unwas = 0; > + _UPT_destroy ((void*)args->UPTarg); > + args->UPTarg = 0; > +} This should be unwind_finish, I guess. There is no member function named unwind_destroy in lib/unwind/StackTraceCreator.java, there is a member named unwind_finish instead. Regards - Wu Zhou From qiyaoltc@cn.ibm.com Mon Sep 4 11:46:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 04 Sep 2006 11:46:00 -0000 Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures Message-ID: <20060904114640.GC13314@GreenHouse.cn.ibm.com> It is very convenient to generate SyscallNum.java by SyscallNum.shjava in a automatic way, but there are some shortcomings for this script now. Mark, add you in CC list for d). a) SyscallNum.shjava miss some syscalls. I posted this problem here, http://sources.redhat.com/ml/frysk/2006-q3/msg00319.html regular expression in SyscallNum.shjava could not cover all syscall names. Actually, this point is not strong enough to remove this script, but the following ones are persuasive, IMO. b) SyscallNum.shjava is for "host", instead of for "target". The scheme in SyscallNum.shjava is to extract syscall num from the output of GCC extension on "host". Mostly, syscall num is different when "target" != "host". For example, when a i386 program running on a X86_64 machine, SyscallNum.SYSread should be the number of SYSCALL read on i386, instead of X86_64.(SyscallNum.SYSread on X86_64 is 0) c) syscallList in Syscall.java is hardwired to Linux+i386. If we could extend syscallList for other platforms(of course, we should), syscallList could replace SyscallNum.java produced by SyscallNum.shjava. d) Some "sub-syscalls", such as connect() and listen(), could not be listed by SyscallNum.shjava. Mark present this problem here, http://sources.redhat.com/ml/frysk/2006-q3/msg00370.html We could add "bind", "listen", to syscallList with the same syscall number, and Syscall.java provides some methods, such as isSyscall(String), for Syscall Observers, like this, public Action updateSyscallEnter (Task task) { ...... syscall = Syscall.getSyscall (int syscallNum); // A Factory maybe. // Yao is not sure he could get first syscall argument in Syscall. if (syscall.isSyscall("bind")) { ..... } } Any comments are welcome. Thanks! -- Yao Qi From mark@klomp.org Mon Sep 4 12:32:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 04 Sep 2006 12:32:00 -0000 Subject: Test and fix for syscall observer adding (bug #3147) In-Reply-To: <1157144484.6659.18.camel@hermans.wildebeest.org> References: <1157114157.3062.16.camel@dijkstra.wildebeest.org> <1157117181.6659.4.camel@hermans.wildebeest.org> <1157144484.6659.18.camel@hermans.wildebeest.org> Message-ID: <1157373132.2965.85.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-09-01 at 23:01 +0200, Mark Wielaard wrote: > For the testcase I can of course do some tricks and see if accept() is a > syscall or, if not, whether socketcall() is available and then select > based on the first argument of the syscall to see if it really is accept > (#5). But this seems 1) fragile and 2) looks like a general problem > people will have when using Syscall Observers. I worked around it for the test case by just using the SYSread call for now: 2006-09-04 Mark Wielaard * funit-syscall-running.c: Accept socket and read() for it. 2006-09-04 Mark Wielaard * TestSyscallRunning.java: Added back, use SYSread and write to Socket. For the testcase this is OK since it just tests something low-level. But I think in general we have to look how people will want to use the syscalls and whether or not to provide something more portable and higher level. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: syscall-running-test.patch Type: text/x-patch Size: 11333 bytes Desc: not available URL: From mark@klomp.org Mon Sep 4 13:06:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 04 Sep 2006 13:06:00 -0000 Subject: linux.syscall.h vs errno Message-ID: <1157375182.2965.93.camel@dijkstra.wildebeest.org> Hi, On my fc6 machine I got some compilation errors since linux.syscall.h includes linux/asm/unistd.h which defines _syscall with a macro that uses errno. Since errno.h is never explicitly included this makes the compile fail when these macros are used. The following adds a #include to linux.syscall.h to make everything compile again. 2006-09-04 Mark Wielaard * include/linux.syscall.h: include errno.h. Also tested on fc5 (x86_64). But unfortunately on fc6 the testsuite is still not in a good state and I did manage to lock up the kernel on that machine again (2.6.17-1.2611.fc6) so I am not 100% sure it works perfectly. Please yell and scream if it does break things in unexpected ways. Cheers, Mark diff -u -r1.3 linux.syscall.h --- frysk-imports/include/linux.syscall.h 23 Jun 2006 20:59:00 -0000 1.3 +++ frysk-imports/include/linux.syscall.h 4 Sep 2006 13:03:03 -0000 @@ -37,8 +37,10 @@ // version and license this file solely under the GPL without // exception. -/* Declares __NR_*. Moreover it might define _syscall2 and such, so it is - * safer to make sure it gets included first. */ +/* linux/unistd.h declares __NR_*. Moreover it might define _syscall2 and + * such, so it is safer to make sure it gets included first. Might refer + * to errno variable, so better also include that. */ +#include #include /* Declares syscall() */ From mark@klomp.org Mon Sep 4 13:51:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 04 Sep 2006 13:51:00 -0000 Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures In-Reply-To: <20060904114640.GC13314@GreenHouse.cn.ibm.com> References: <20060904114640.GC13314@GreenHouse.cn.ibm.com> Message-ID: <1157377857.3629.16.camel@dijkstra.wildebeest.org> Hi Yao, On Mon, 2006-09-04 at 19:46 +0800, Yao Qi wrote: > It is very convenient to generate SyscallNum.java by SyscallNum.shjava > in a automatic way, but there are some shortcomings for this script > now. > Mark, add you in CC list for d). [...] > c) syscallList in Syscall.java is hardwired to Linux+i386. > If we could extend syscallList for other platforms(of course, we > should), syscallList could replace SyscallNum.java produced by > SyscallNum.shjava. > > d) Some "sub-syscalls", such as connect() and listen(), could not be > listed by SyscallNum.shjava. > Mark present this problem here, > http://sources.redhat.com/ml/frysk/2006-q3/msg00370.html > > We could add "bind", "listen", to syscallList with the same syscall > number, and Syscall.java provides some methods, such as > isSyscall(String), for Syscall Observers, like this, It seems that other projects (strace, systemtap) also maintain these by hand. It is a little unfortunate that there is no canonical list of syscalls and numbers per architecture. But it seems to make sense to maintain them by hand in Syscall (including then mapping name and number mappings). For some of these "sub-syscalls" I think it would be better to treat them as if they were really syscalls for those that are real syscalls on some other architecture (that is what strace and systemtap do). And I would propose minimize the usage of numbers. So only have a factory getSyscall(String) and not one based on numbers (since those differ between architectures and make it impossible to get any 'sub-syscalls'). If so then we should also drop the number() from SyscallEventInfo and replace it with a syscall() method that just returns the Syscall object. Cheers, Mark From aoliva@redhat.com Mon Sep 4 18:45:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Mon, 04 Sep 2006 18:45:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <44FBFCE2.8030505@cn.ibm.com> (Wu Zhou's message of "Mon, 04 Sep 2006 18:16:02 +0800") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 4, 2006, Wu Zhou wrote: > I am not sure too why we didn't use libunwind-ptrace.a directly > before. One reason might be that it is not really a part of libunwind > API. But my point is, as long as it is general enough, why can't we > make it part of libunwind API? What do you mean, not part of the libunwind API? It's certainly not part of the run-time-for-local-process-unwinding API, but it definitely is part of the documented API of libunwind. >> +lib::unwind::StackTraceCreator::unwind_destroy (unwargs *args) > This should be unwind_finish, I guess. Yes, sorry. I failed to refresh the patch file after renaming the method. I'm not sure whether I missed any other change, so here's the patch generated out of what I actually tested. -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-dwarf-find-info-4.patch Type: text/x-patch Size: 20062 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From woodzltc@cn.ibm.com Tue Sep 5 02:07:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 05 Sep 2006 02:07:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: <44FCDBE0.6040608@cn.ibm.com> Alexandre Oliva wrote: > On Sep 4, 2006, Wu Zhou wrote: > >> I am not sure too why we didn't use libunwind-ptrace.a directly >> before. One reason might be that it is not really a part of libunwind >> API. But my point is, as long as it is general enough, why can't we >> make it part of libunwind API? > > What do you mean, not part of the libunwind API? It's certainly not > part of the run-time-for-local-process-unwinding API, but it > definitely is part of the documented API of libunwind. Below is a segment of comment from libunwind-ptrace.h: /* Helper routines which make it easy to use libunwind via ptrace(). They're available only if UNW_REMOTE_ONLY is _not_ defined and they aren't really part of the libunwind API. They are implemented in a archive library called libunwind-ptrace.a. */ It seems that libunwind developers are not sure how they expect these routines to be used. >>> +lib::unwind::StackTraceCreator::unwind_destroy (unwargs *args) > >> This should be unwind_finish, I guess. > > Yes, sorry. I failed to refresh the patch file after renaming the > method. I'm not sure whether I missed any other change, so here's the > patch generated out of what I actually tested. Good. I had a test with your patch. TestStackBackTrace works ok with this patch. Here are the output: ./TestRunner frysk.rt.tests.TestStackBacktrace Running testBacktrace(frysk.rt.tests.TestStackBacktrace) ...Frame 1 File: ../../frysk-clean/frysk-core/frysk/pkglibexecdir/funit-rt-looper.c Func: baz Line: 69 Col: 0 Addr: 134514264 Frame 2 File: ../../frysk-clean/frysk-core/frysk/pkglibexecdir/funit-rt-looper.c Func: bar Line: 72 Col: 0 Addr: 134514286 Frame 3 File: ../../frysk-clean/frysk-core/frysk/pkglibexecdir/funit-rt-looper.c Func: foo Line: 53 Col: 0 Addr: 134514315 Frame 4 File: null Func: main Line: 0 Col: 0 Addr: 134514973 Frame 5 File: null Func: Line: 0 Col: 0 Addr: 12773156 Frame 6 File: null Func: Line: 0 Col: 0 Addr: 134514081 PASS Time: 0.274 OK (1 test) Regards - Wu Zhou From qiyaoltc@cn.ibm.com Tue Sep 5 02:42:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 05 Sep 2006 02:42:00 -0000 Subject: [htdocs patch] Build 64-bit frysk on PPC64 Message-ID: <20060905024257.GD13314@GreenHouse.cn.ibm.com> It is a little different on PPC64 to build a 64-bit frysk. This patch adds some instructions for building 64-bit frysk on htdocs/build/index.html. Free to tell me if ChangeLog is needed here. OK to commit? Thanks! -- Yao Qi -------------- next part -------------- Index: htdocs/build/index.html =================================================================== RCS file: /cvs/frysk/htdocs/build/index.html,v retrieving revision 1.105 diff -u -r1.105 index.html --- htdocs/build/index.html 24 Aug 2006 22:55:41 -0000 1.105 +++ htdocs/build/index.html 5 Sep 2006 02:31:49 -0000 @@ -220,10 +220,22 @@

Configure and Build

- +
+
  • On X86 or X86_64.
     $ ( mkdir build && cd build && ../frysk/autogen.sh && make -j2 )
     
    +
  • + +
  • On PPC64. +
    +$ ( export PKG_CONFIG_PATH=/usr/lib64/pkgconfig )
    +$ ( mkdir build && cd build )
    +$ ( CC='gcc -m64' GCJ='gcj -m64' GCJLINK='gcj -m64' CXX='g++ -m64' ../frysk/autogen.sh )
    +$ ( make -j2 )
    +
    +
  • +

    Verify the build environment (optional)

    From skasal@redhat.com Tue Sep 5 07:07:00 2006 From: skasal@redhat.com (Stepan Kasal) Date: Tue, 05 Sep 2006 07:07:00 -0000 Subject: build on ppc, not only ppc64 Message-ID: <20060902153652.GA24465@camelia.ucw.cz> Hello, are there any plans to build frysk on 32bit ppc? Background: As you know, there is only one ISO for ppc Fedora, which is used both on 32bit and 64bit machines. I verified that the daily build of the tree for the ISO contains all java-gnome packaged for ppc64. But when I submitted a request to add ppc64 version of frysk, I was asked why there is no build for 32bit ppc machines. Can this be done? I can try to make ppc stubs for libunwind from the ppc64 ones, would that be enough? Thanks, Stepan Kasal From woodzltc@cn.ibm.com Tue Sep 5 09:32:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 05 Sep 2006 09:32:00 -0000 Subject: build on ppc, not only ppc64 In-Reply-To: <20060902153652.GA24465@camelia.ucw.cz> References: <20060902153652.GA24465@camelia.ucw.cz> Message-ID: <44FD4409.9000205@cn.ibm.com> Hi Stepan, Stepan Kasal wrote: > Hello, > are there any plans to build frysk on 32bit ppc? We can build frysk ok on ppc64 as a 32-bit binary. But our intention is for a 64-bit frysk to debug 32-bit and 64-bit application at the same time. So we don't do that. We are building frysk in 64-bit mode on ppc64 right now. For 32bit ppc machines, we don't have plan to build frysk on them right now. We are mainly working on ppc64 platforms. To make frysk build on ppc, libunwind stubs are needed. I guess that is enough, but not very sure. Maybe you can have a try. :-) If frysk is available on 32bit ppc, I am also not sure how to support frysk on them. Regards - Wu Zhou > > Background: > As you know, there is only one ISO for ppc Fedora, which is used > both on 32bit and 64bit machines. > > I verified that the daily build of the tree for the ISO contains all > java-gnome packaged for ppc64. > > But when I submitted a request to add ppc64 version of frysk, I was > asked why there is no build for 32bit ppc machines. > > Can this be done? I can try to make ppc stubs for libunwind from the > ppc64 ones, would that be enough? > > Thanks, > Stepan Kasal > From mark@klomp.org Tue Sep 5 11:47:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 05 Sep 2006 11:47:00 -0000 Subject: [htdocs patch] Build 64-bit frysk on PPC64 In-Reply-To: <20060905024257.GD13314@GreenHouse.cn.ibm.com> References: <20060905024257.GD13314@GreenHouse.cn.ibm.com> Message-ID: <1157456806.3112.13.camel@dijkstra.wildebeest.org> On Tue, 2006-09-05 at 10:42 +0800, Yao Qi wrote: > It is a little different on PPC64 to build a 64-bit frysk. This patch > adds some instructions for building 64-bit frysk on > htdocs/build/index.html. > [...] > +$ ( export PKG_CONFIG_PATH=/usr/lib64/pkgconfig ) > +$ ( mkdir build && cd build ) > +$ ( CC='gcc -m64' GCJ='gcj -m64' GCJLINK='gcj -m64' CXX='g++ -m64' ../frysk/autogen.sh ) The idea seems to be that we always want a 64 bit version of frysk when we are on ppc64 (and 32bit ppc isn't supported atm it seems). So doesn't it make more sense to adapt autogen to recognizes this and put in the right flags by default? Then the user doesn't need to remember any special flags while building. Cheers, Mark From rmoseley@redhat.com Tue Sep 5 15:09:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Tue, 05 Sep 2006 15:09:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> Message-ID: <44FD9314.8010505@redhat.com> Alexandre Oliva wrote: > On Sep 1, 2006, Wu Zhou wrote: > > >> Elena Zannoni wrote: >> > > >>> Libunwind Alex: adding remote features: shouldn't be too hard, but >>> not >>> being able to see how to offer them. If you are remote, the user is >>> supposed to tell libunwind how to use the information. Possibly export >>> some functions that the users can use as callback. Cagney says that >>> the problem has been resolved for ia64. Ia64 uses itanium unwind info, >>> which is in the remote process. Callback to read from remote memory >>> were put in place when JeffJ made gdb use libunwind. Also need for >>> callbacks to free remote memory that it allocates. It now just >>> allocates local memory. But this memory will need to be freed >>> explicitly once it is allocated remotely. Alex says that you need to >>> cache information (didn't catch that, sorry). >>> > > >> Is there any code available right now? If yes, we would be very happy to have a look at that first. >> > > Here's the patch I've just completed, that works on x86, and fixes a > potential libunwind memory leak while at that. > > As it turns out, libunwind already has all that we need, we were just > missing the proper way to use it. dwarf_find_proc_info() was not it, > since it's specifically designed to operate on the local process. > Part of the libunwind-ptrace interface offers access to everything we > need as far as locating unwind tables et al is concerned, while still > using our own callbacks to interact with the process using ptrace or > whatever. I'm not sure why we don't just bite the bullet and use all > of the libunwind interface (it looks like it would be much simpler and > would get us what we want), but I figured I wouldn't remove any such > code for now. > Well, I'm not sure either. I'm all for the easiest/simplest/most maintainable solution and I'm not sure where that is. I'm not sure why that is exactly unless it is the upcoming utrace interface we are trying to get to. Maybe Andrew has some insight here as to what the "big picture" thinking is. Rick > Ok to install the patch in bug 3070, attached below for reference? > > > ------------------------------------------------------------------------ > > for frysk-imports/libunwind/ChangeLog > from Alexandre Oliva > > * src/os-linux (tdep_get_elf_image): Define for remote only too. > > for frysk-imports/lib/unwind/ChangeLog > from Alexandre Oliva > > * StackTraceCreator.java (UnwindArgs): New inner class. > (createStackTrace): Instantiate it. > (unwind_setup): Take it as argument. > (unwind_finish): New native method. > * cni/StackTraceCreator.cxx: Include libunwind-ptrace.h and > header for new inner class. > (find_proc_info, put_unwind_info, get_dyn_info_list_addr): Use > implementation from libunwind-ptrace. > (access_mem, access_reg, access_fpreg, resume, get_proc_name): > Adjust. > (unwind_setup): Set up libunwind-ptrace opaque args and > UnwindArgs fields that need native finalization. > (unwind_finish): Finalize them. > > for frysk-imports/ChangeLog > from Alexandre Oliva > > * Makefile.am (GEN_GCJ_LDADD): Link in libunwind-ptrace.a. > * Makefile.in: Rebuild. > > for frysk-core/ChangeLog > from Alexandre Oliva > > * Makefile.am (GEN_GCJ_LDADD): Link in libunwind-ptrace.a. > * Makefile.in: Rebuild. > > for frysk-core/frysk/rt/ChangeLog > from Alexandre Oliva > > * tests/TestStackBacktrace.java (testBacktrace): Remove > expected failure marker. > > for frysk-gtk/ChangeLog > from Alexandre Oliva > > * Makefile.am (GEN_GCJ_LDADD): Link in libunwind-ptrace.a. > * Makefile.in: Rebuild. > > for frysk-gui/ChangeLog > from Alexandre Oliva > > * Makefile.am (GEN_GCJ_LDADD): Link in libunwind-ptrace.a. > * Makefile.in: Rebuild. > > for frysk-sys/ChangeLog > from Alexandre Oliva > > * Makefile.am (GEN_GCJ_LDADD): Link in libunwind-ptrace.a. > * Makefile.in: Rebuild. > > Index: frysk-imports/lib/unwind/cni/StackTraceCreator.cxx > =================================================================== > --- frysk-imports/lib/unwind/cni/StackTraceCreator.cxx.orig 2006-09-04 00:29:47.000000000 -0300 > +++ frysk-imports/lib/unwind/cni/StackTraceCreator.cxx 2006-09-04 00:37:46.000000000 -0300 > @@ -37,14 +37,18 @@ > // version and license this file solely under the GPL without > // exception. > #include > +#include > #include > #include > #include > > #include "lib/unwind/StackTraceCreator.h" > +#include "lib/unwind/StackTraceCreator$UnwindArgs.h" > #include "lib/unwind/FrameCursor.h" > #include "lib/unwind/UnwindCallbacks.h" > > +typedef lib::unwind::StackTraceCreator$UnwindArgs unwargs; > + > /*************************** > * CALLBACKS > * See the UnwindCallbacks > @@ -59,14 +63,8 @@ > int find_proc_info (::unw_addr_space_t as, ::unw_word_t ip, > ::unw_proc_info_t *pip, int need_unwind_info, void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > - // delegate to the java interface > - jboolean retval = cb->findProcInfo ((jlong) pip, (jlong) &as, (jlong) ip, need_unwind_info != 0); > - > - if(!retval) > - return -UNW_ENOINFO; > - > - return 0; > + return _UPT_find_proc_info (as, ip, pip, need_unwind_info, > + (void *)((unwargs *)arg)->UPTarg); > } > > /* > @@ -75,8 +73,8 @@ int find_proc_info (::unw_addr_space_t a > void put_unwind_info (::unw_addr_space_t as, ::unw_proc_info_t *pip, > void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > - cb->putUnwindInfo ((jlong) as, (jlong) pip); > + return _UPT_put_unwind_info (as, pip, > + (void *)((unwargs *)arg)->UPTarg); > } > > /* > @@ -85,14 +83,8 @@ void put_unwind_info (::unw_addr_space_t > int get_dyn_info_list_addr (::unw_addr_space_t as, ::unw_word_t *dilap, > void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > - jlong retval = cb->getDynInfoListAddr ((jlong) as); > - if(retval) > - *dilap = retval; > - else > - dilap = 0; > - > - return 0; > + return _UPT_get_dyn_info_list_addr (as, dilap, > + (void *)((unwargs *)arg)->UPTarg); > } > > /* > @@ -101,7 +93,7 @@ int get_dyn_info_list_addr (::unw_addr_s > int access_mem (::unw_addr_space_t as, ::unw_word_t addr, > ::unw_word_t *valp, int write, void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > + lib::unwind::UnwindCallbacks *cb = ((unwargs *)arg)->CBarg; > > // we've separated read and write in the java interface for simplicity > if(write == 0){ > @@ -122,7 +114,7 @@ int access_reg(::unw_addr_space_t as, > ::unw_regnum_t regnum, ::unw_word_t *valp, > int write, void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > + lib::unwind::UnwindCallbacks *cb = ((unwargs *)arg)->CBarg; > > // read and write are separated in the java interface > if(write == 0){ > @@ -143,7 +135,7 @@ int access_fpreg(::unw_addr_space_t as, > ::unw_regnum_t regnum, ::unw_fpreg_t *fpvalp, > int write, void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > + lib::unwind::UnwindCallbacks *cb = ((unwargs *)arg)->CBarg; > > if(write == 0){ > jdouble retval = cb->accessFpreg ((jlong) as, (jlong) regnum); > @@ -162,7 +154,7 @@ int access_fpreg(::unw_addr_space_t as, > int resume(::unw_addr_space_t as, > ::unw_cursor_t *cp, void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > + lib::unwind::UnwindCallbacks *cb = ((unwargs *)arg)->CBarg; > > return (int) cb->resume ((jlong) as, (jlong) cp); > } > @@ -175,7 +167,7 @@ int get_proc_name(::unw_addr_space_t as, > ::unw_word_t addr, char *bufp, > size_t buf_len, ::unw_word_t *offp, void *arg) > { > - lib::unwind::UnwindCallbacks *cb = (lib::unwind::UnwindCallbacks*) arg; > + lib::unwind::UnwindCallbacks *cb = ((unwargs *)arg)->CBarg; > > jstring name = cb->getProcName ((jlong) as, (jlong) addr); > jlong offset = cb->getProcOffset ((jlong) as, (jlong) addr); > @@ -194,7 +186,7 @@ int get_proc_name(::unw_addr_space_t as, > } > > lib::unwind::FrameCursor* > -lib::unwind::StackTraceCreator::unwind_setup (lib::unwind::UnwindCallbacks *cbs) > +lib::unwind::StackTraceCreator::unwind_setup (unwargs *args) > { > /* > * We don't need to malloc this, since according to the libunwind docs this callback > @@ -205,8 +197,11 @@ lib::unwind::StackTraceCreator::unwind_s > > // Initialize libunwind > ::unw_addr_space_t addr_space = ::unw_create_addr_space(&accessors, 0); > + args->unwas = (jlong)addr_space; > ::unw_cursor_t cursor; > - ::unw_init_remote(&cursor, addr_space, (void*) cbs); > + /* Since we're not actually using ptrace, the PID below is unused. */ > + args->UPTarg = (jlong)_UPT_create (/* PID = */ 0); > + ::unw_init_remote(&cursor, addr_space, args); > ::unw_set_caching_policy(addr_space, UNW_CACHE_PER_THREAD); > > // Create the frame objects and return the top (most recent one) > @@ -224,3 +219,12 @@ lib::unwind::StackTraceCreator::unwind_s > > return base_frame; > } > + > +void > +lib::unwind::StackTraceCreator::unwind_destroy (unwargs *args) > +{ > + unw_destroy_addr_space ((unw_addr_space_t)args->unwas); > + args->unwas = 0; > + _UPT_destroy ((void*)args->UPTarg); > + args->UPTarg = 0; > +} > Index: frysk-core/Makefile.am > =================================================================== > --- frysk-core/Makefile.am.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-core/Makefile.am 2006-09-04 00:31:42.000000000 -0300 > @@ -85,7 +85,8 @@ GEN_GCJ_LDADD += ../frysk-imports/elfuti > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a > if USE_LIBUNWIND > -GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > + ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > endif > # Stub bfd_getb32 and bfd_getl32 for PPC64. Unconditionally > # link -lbfd_get just for simplification. > Index: frysk-core/Makefile.in > =================================================================== > --- frysk-core/Makefile.in.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-core/Makefile.in 2006-09-04 00:31:42.000000000 -0300 > @@ -168,7 +168,9 @@ pkglibexec_PROGRAMS = frysk/pkglibexecdi > frysk/pkglibexecdir/funit-child-alias$(EXEEXT) > check_PROGRAMS = > solib_PROGRAMS = libfrysk-core.so$(EXEEXT) > -@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > + > subdir = . > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > am__aclocal_m4_deps = $(top_srcdir)/common/m4/frysk-use-libunwind.m4 \ > @@ -371,7 +373,8 @@ PROGRAMS = $(bin_PROGRAMS) $(libexec_PRO > $(pkglibexec_PROGRAMS) $(sbin_PROGRAMS) $(solib_PROGRAMS) > nodist_TestRunner_OBJECTS = TestRunner.$(OBJEXT) > TestRunner_OBJECTS = $(nodist_TestRunner_OBJECTS) > -@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > am__DEPENDENCIES_2 = libfrysk-core.a ../frysk-sys/libfrysk-sys.a \ > ../frysk-imports/libfrysk-imports.a \ > ../frysk-imports/libfrysk-jline.a \ > Index: frysk-core/frysk/rt/tests/TestStackBacktrace.java > =================================================================== > --- frysk-core/frysk/rt/tests/TestStackBacktrace.java.orig 2006-09-04 00:29:47.000000000 -0300 > +++ frysk-core/frysk/rt/tests/TestStackBacktrace.java 2006-09-04 00:31:53.000000000 -0300 > @@ -60,9 +60,6 @@ public class TestStackBacktrace > > public void testBacktrace () throws TaskException > { > - if (brokenXXX(2936)) > - return; > - > class TaskCreatedObserver extends TaskObserverBase > implements TaskObserver.Attached > { > Index: frysk-gtk/Makefile.am > =================================================================== > --- frysk-gtk/Makefile.am.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-gtk/Makefile.am 2006-09-04 00:31:42.000000000 -0300 > @@ -59,7 +59,8 @@ GEN_GCJ_LDADD += ../frysk-imports/elfuti > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a > if USE_LIBUNWIND > -GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > + ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > endif > # Stub bfd_getb32 and bfd_getl32 for PPC64. Unconditionally > # link -lbfd_get just for simplification. > Index: frysk-gtk/Makefile.in > =================================================================== > --- frysk-gtk/Makefile.in.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-gtk/Makefile.in 2006-09-04 00:31:42.000000000 -0300 > @@ -135,7 +135,9 @@ pkglibexec_PROGRAMS = > check_PROGRAMS = > solib_PROGRAMS = libfrysk-ftk.so$(EXEEXT) libfrysk-gtk.so$(EXEEXT) \ > EggTrayIcon/libEggTrayIcon.so$(EXEEXT) > -@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > + > subdir = . > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > am__aclocal_m4_deps = $(top_srcdir)/common/m4/frysk-use-libunwind.m4 \ > @@ -197,7 +199,8 @@ am__DEPENDENCIES_1 = > EggTrayIcon_libEggTrayIcon_so_DEPENDENCIES = $(am__DEPENDENCIES_1) > nodist_TestRunner_OBJECTS = TestRunner.$(OBJEXT) > TestRunner_OBJECTS = $(nodist_TestRunner_OBJECTS) > -@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_2 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_2 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > am__DEPENDENCIES_3 = libfrysk-gtk.a \ > ../frysk-imports/libfrysk-imports.a \ > ../frysk-imports/libfrysk-junit.a \ > Index: frysk-gui/Makefile.am > =================================================================== > --- frysk-gui/Makefile.am.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-gui/Makefile.am 2006-09-04 00:31:42.000000000 -0300 > @@ -75,7 +75,8 @@ GEN_GCJ_LDADD += ../frysk-imports/elfuti > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a > if USE_LIBUNWIND > -GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > + ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > endif > GEN_GCJ_LDADD += ../frysk-gtk/libfrysk-ftk.a > GEN_GCJ_LDADD += -L../frysk-gtk/EggTrayIcon > Index: frysk-gui/Makefile.in > =================================================================== > --- frysk-gui/Makefile.in.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-gui/Makefile.in 2006-09-04 00:31:42.000000000 -0300 > @@ -136,7 +136,9 @@ libexec_PROGRAMS = > pkglibexec_PROGRAMS = > check_PROGRAMS = > solib_PROGRAMS = libfrysk-gui.so$(EXEEXT) > -@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > + > subdir = . > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > am__aclocal_m4_deps = $(top_srcdir)/common/m4/frysk-use-libunwind.m4 \ > @@ -369,7 +371,8 @@ PROGRAMS = $(bin_PROGRAMS) $(libexec_PRO > $(pkglibexec_PROGRAMS) $(sbin_PROGRAMS) $(solib_PROGRAMS) > nodist_TestRunner_OBJECTS = TestRunner.$(OBJEXT) > TestRunner_OBJECTS = $(nodist_TestRunner_OBJECTS) > -@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > am__DEPENDENCIES_2 = > am__DEPENDENCIES_3 = libfrysk-gui.a ../frysk-gtk/libfrysk-gtk.a \ > ../frysk-core/libfrysk-core.a ../frysk-sys/libfrysk-sys.a \ > Index: frysk-imports/Makefile.am > =================================================================== > --- frysk-imports/Makefile.am.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-imports/Makefile.am 2006-09-04 00:31:42.000000000 -0300 > @@ -49,7 +49,7 @@ CHECK_SUBDIRS = \ > elfutils > > SUBDIRS = $(CHECK_SUBDIRS) > - > + > # Add in libunwind only for certain arches > if USE_LIBUNWIND > SUBDIRS += libunwind > @@ -82,7 +82,8 @@ GEN_GCJ_LDADD += ./elfutils/libelf/libel > > # Add in libunwind only for certain arches > if USE_LIBUNWIND > -GEN_GCJ_LDADD += ./libunwind/src/libunwind-$(libunwind_cpu).a > +GEN_GCJ_LDADD += ./libunwind/src/libunwind-ptrace.a \ > + ./libunwind/src/libunwind-$(libunwind_cpu).a > endif > > # Stub bfd_getb32 and bfd_getl32 for PPC64. Unconditionally > Index: frysk-imports/Makefile.in > =================================================================== > --- frysk-imports/Makefile.in.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-imports/Makefile.in 2006-09-04 00:31:42.000000000 -0300 > @@ -147,7 +147,9 @@ solib_PROGRAMS = libfrysk-junit.so$(EXEE > @USE_LIBUNWIND_TRUE@am__append_1 = libunwind > > # Add in libunwind only for certain arches > -@USE_LIBUNWIND_TRUE@am__append_2 = ./libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__append_2 = ./libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ./libunwind/src/libunwind-$(libunwind_cpu).a > + > subdir = . > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > am__aclocal_m4_deps = $(top_srcdir)/common/m4/ac_find_file.m4 \ > @@ -315,7 +317,9 @@ PROGRAMS = $(bin_PROGRAMS) $(libexec_PRO > $(pkglibexec_PROGRAMS) $(sbin_PROGRAMS) $(solib_PROGRAMS) > nodist_TestRunner_OBJECTS = TestRunner.$(OBJEXT) > TestRunner_OBJECTS = $(nodist_TestRunner_OBJECTS) > -@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = ./libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = \ > +@USE_LIBUNWIND_TRUE@ ./libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ./libunwind/src/libunwind-$(libunwind_cpu).a > am__DEPENDENCIES_2 = libfrysk-imports.a libfrysk-jargs.a \ > libfrysk-junit.a ./elfutils/libdwfl/libdwfl.a \ > ./elfutils/libdw/libdw.a ./elfutils/libebl/libebl.a \ > Index: frysk-imports/lib/unwind/StackTraceCreator.java > =================================================================== > --- frysk-imports/lib/unwind/StackTraceCreator.java.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-imports/lib/unwind/StackTraceCreator.java 2006-09-04 00:37:01.000000000 -0300 > @@ -51,8 +51,28 @@ public class StackTraceCreator > */ > public static FrameCursor createStackTrace (UnwindCallbacks callbacks) > { > - return unwind_setup(callbacks); > + return unwind_setup(new UnwindArgs (callbacks)); > } > > - private static native FrameCursor unwind_setup (UnwindCallbacks callbacks); > + private static native FrameCursor unwind_setup (UnwindArgs args); > + > + private static native void unwind_finish (UnwindArgs args); > + > + private static class UnwindArgs > + { > + public UnwindCallbacks CBarg; > + public long UPTarg; > + public long unwas; > + > + public UnwindArgs (UnwindCallbacks CBarg) > + { > + this.CBarg = CBarg; > + this.UPTarg = 0; > + this.unwas = 0; > + } > + > + public void finalize () { > + unwind_finish (this); > + } > + } > } > Index: frysk-imports/libunwind/src/os-linux.c > =================================================================== > --- frysk-imports/libunwind/src/os-linux.c.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-imports/libunwind/src/os-linux.c 2006-09-04 00:31:42.000000000 -0300 > @@ -23,8 +23,6 @@ LIABLE FOR ANY CLAIM, DAMAGES OR OTHER L > OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION > WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ > > -#ifndef UNW_REMOTE_ONLY > - > #include > #include > > @@ -54,5 +52,3 @@ tdep_get_elf_image (struct elf_image *ei > > return elf_map_image (ei, path); > } > - > -#endif /* UNW_REMOTE_ONLY */ > Index: frysk-sys/Makefile.am > =================================================================== > --- frysk-sys/Makefile.am.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-sys/Makefile.am 2006-09-04 00:31:42.000000000 -0300 > @@ -57,7 +57,8 @@ GEN_GCJ_LDADD += ../frysk-imports/elfuti > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a > GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a > if USE_LIBUNWIND > -GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > + ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > endif > # Stub bfd_getb32 and bfd_getl32 for PPC64. Unconditionally > # link -lbfd_get just for simplification. > Index: frysk-sys/Makefile.in > =================================================================== > --- frysk-sys/Makefile.in.orig 2006-09-04 00:29:46.000000000 -0300 > +++ frysk-sys/Makefile.in 2006-09-04 00:31:42.000000000 -0300 > @@ -133,7 +133,9 @@ libexec_PROGRAMS = > pkglibexec_PROGRAMS = > check_PROGRAMS = > solib_PROGRAMS = libfrysk-sys.so$(EXEEXT) > -@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__append_1 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > + > subdir = . > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > am__aclocal_m4_deps = $(top_srcdir)/common/m4/frysk-use-libunwind.m4 \ > @@ -216,7 +218,8 @@ PROGRAMS = $(bin_PROGRAMS) $(libexec_PRO > $(pkglibexec_PROGRAMS) $(sbin_PROGRAMS) $(solib_PROGRAMS) > nodist_TestRunner_OBJECTS = TestRunner.$(OBJEXT) > TestRunner_OBJECTS = $(nodist_TestRunner_OBJECTS) > -@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > +@USE_LIBUNWIND_TRUE@am__DEPENDENCIES_1 = ../frysk-imports/libunwind/src/libunwind-ptrace.a \ > +@USE_LIBUNWIND_TRUE@ ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a > am__DEPENDENCIES_2 = libfrysk-sys.a \ > ../frysk-imports/libfrysk-imports.a \ > ../frysk-imports/libfrysk-junit.a \ > > ------------------------------------------------------------------------ > > > From scox@redhat.com Tue Sep 5 17:08:00 2006 From: scox@redhat.com (Stan Cox) Date: Tue, 05 Sep 2006 17:08:00 -0000 Subject: dwarf support for expressions Message-ID: <1157476135.10612.199.camel@multics.rdu.redhat.com> Here is what I have thus far for dwarf support just to get feedback as to the general direction. There are still some rough edges. Example: % cat /home/scox/accu/src/loop.c int j = 7; bar () { int i = 8; while (i) { } } foo () { bar (); } main () { foo (); } % (hpd) attach /home/scox/accu/src/loop.x 31826 (hpd) what j int j (hpd) what i int i (hpd) print j 7 (hpd) print i # No DW_AT_frame_base support so value is wrong 0 (hpd) assign j 9 9 (hpd) print j # Need to actually put the value with ptrace 7 (hpd) quit Changes: 0. Add frysk-core/frysk/cli/hpd/hpd.java (Command line interface to CLI.java, makes testing easier) 1. frysk-core/frysk/cli/hpd/CLI.java Add attach/detach to attach to a process 2. Move PrintHandler.java to SymTab.java 3. SymTab A. class symTab callback to frysk-core/frysk/expr - put not fully implemented but will be similar to get - get implemented for static int Need: DW_AT_frame_base support for local variables Need: Complex addressing support Need: add types other than int B. class SymTab - 'what' gives variable type Need: Expand for more complex types - 'print' interfaces to expr, no changes 4. frysk-core/frysk/lang/Endian.java A. Remove and change all callers to use inua/eio/ByteOrder.java B. Add CppSymTab interface for 3-A above (This is independent of everything else) 5. frysk-imports/lib/dw/DwarfDie.java A. Add getScopesVar to return dwarf scoping info B. Add getAddr to return the address of a variable Possibly need to refactor this to accomodate more complex address modes C. getType to return the type of a variable D. fbregVariable to say if a variable is local off of frame ptr 6. frysk-imports/lib/dw/cni/DwarfDie.cxx For 5 above Index: frysk-core/frysk/cli/hpd/CLI.java =================================================================== diff -u -p -r1.12 CLI.java --- frysk-core/frysk/cli/hpd/CLI.java 14 Jul 2006 22:24:56 -0000 1.12 +++ frysk-core/frysk/cli/hpd/CLI.java 5 Sep 2006 16:33:48 -0000 @@ -48,5 +48,11 @@ import java.util.Iterator; public class CLI { + private Dwfl dwfl; + Proc proc; + Task task; + int pid = 0; + SymTab symtab; + /* * Command handlers */ @@ -255,6 +277,55 @@ public class CLI } } + class AttachHandler implements CommandHandler + { + public void handle(Command cmd) throws ParseException + { + Vector params = cmd.getParameters(); + String executable = ""; + + if (params.size() != 2) + { + cmd.getOut().println ("Usage " + cmd.getAction() + "Executable PID"); + return; + } + Manager.eventLoop.runPolling (5 * 1000); + + executable = ((String)params.elementAt(0)); + pid = Integer.parseInt((String)params.elementAt(1)); + + try { + Ptrace.attach(pid); + } + catch (Errno errno) { + addMessage(new Message("No such process.", Message.TYPE_ERROR)); + } + + Manager.host.requestRefreshXXX (true); + Manager.eventLoop.runPending (); + proc = Manager.host.getProc (new ProcId (pid)); + task = proc.getMainTask(); + SymTab symtab = new SymTab(pid, proc, task); + } + } + + class DetachHandler implements CommandHandler + { + public void handle(Command cmd) throws ParseException + { + Vector params = cmd.getParameters(); + String sInput = cmd.getFullCommand().substring(cmd.getAction().length()).trim(); + + if (params.size() > 0) + { + cmd.getOut().println ("Usage " + cmd.getAction()); + return; + } + + Manager.eventLoop.requestStop(); + } + } + class UnaliasHandler implements CommandHandler { public void handle(Command cmd) throws ParseException Index: frysk-core/frysk/cli/hpd/SymTab.java =================================================================== // This file is part of the program FRYSK. // ... import ... class symTab implements CppSymTab { static Map symTab = new HashMap(); public void put(String s, Variable v) { symTab.put(s, v);} public Variable get(String s) { Dwfl dwfl; long address; try { address = SymTab.task.getIsa().pc(SymTab.task) - 1; } catch (TaskException tte) { throw new RuntimeException(tte); } dwfl = new Dwfl(SymTab.pid); DwflLine line = null; DwflDieBias bias = dwfl.getDie(address); DwarfDie die = bias.die; DwarfDie[] allDies = die.getScopes(die.getLowPC() - bias.bias); String sInput = s; DwarfDie varDie = die.getScopesVar(allDies, sInput); long addr = varDie.getAddr(); if (varDie.fbregVariable()) { long regval = 0; try { if (MachineType.getMachineType() == MachineType.X8664) regval = SymTab.task.getIsa().getRegisterByName("rbp").get (SymTab.task); else if (MachineType.getMachineType() == MachineType.IA32) regval = SymTab.task.getIsa().getRegisterByName("ebp").get (SymTab.task); } catch (TaskException tte) { throw new RuntimeException(tte); } // Need to use DW_AT_frame_base here addr += regval; } ByteBuffer buffer; buffer = new PtraceByteBuffer(SymTab.pid, PtraceByteBuffer.Area.DATA, 0xffffffffl); try { buffer = buffer.order(SymTab.task.getIsa().getByteOrder()); } catch (TaskException tte) { throw new RuntimeException(tte); } if (varDie.getType().compareTo("int") == 0) { int intVal; intVal = buffer.getInt(addr); Variable v; try { IntegerType intType = new IntegerType(SymTab.task.getIsa().getWordSize(), SymTab.task.getIsa().getByteOrder()); v = IntegerType.newIntegerVariable(intType, intVal); } catch (TaskException tte) { throw new RuntimeException(tte); } return v; } return null; } } public class SymTab { static Proc proc; static Task task; static int pid; static symTab hpdsymTab = new symTab(); public SymTab (int pid_p, Proc proc_p, Task task_p) { pid = pid_p; proc = proc_p; task = task_p; } static public void what(Command cmd) throws ParseException { long address; Dwfl dwfl; try { address = task.getIsa().pc(task) - 1; } catch (TaskException tte) { throw new RuntimeException(tte); } dwfl = new Dwfl(pid); DwflLine line = null; DwflDieBias bias = dwfl.getDie(address); DwarfDie die = bias.die; DwarfDie[] allDies = die.getScopes(die.getLowPC() - bias.bias); String sInput = cmd.getFullCommand().substring(4).trim(); DwarfDie varDie = die.getScopesVar(allDies, sInput); if (varDie == null) { System.out.println(sInput + " not found in scope."); return; } long addr = varDie.getAddr(); String type = varDie.getType(); System.out.println(type + " " + varDie.getName()); } private static final int DECIMAL = 10; private static final int HEX = 16; private static final int OCTAL = 8; static public void print(Command cmd) throws ParseException { ...Moved from PrintHandler otherwise mostly unchanged } } Index: frysk-imports/lib/dw/DwarfDie.java =================================================================== diff -u -p -r1.4 DwarfDie.java @@ -94,10 +94,43 @@ public class DwarfDie return dies; } + public DwarfDie getScopesVar (DwarfDie[] scopes, String variable) + { + long[] vals = new long[scopes.length]; + for(int i = 0; i < scopes.length; i++) + vals[i] = scopes[i].getPointer(); + + DwarfDie die = null; + long val = get_scopesvar(vals, scopes.length, variable); + if (val != 0) + die = new DwarfDie(val, this.parent); + return die; + } + + + public long getAddr () + { + return get_addr(this.getPointer()); + } + + public String getType () + { + return get_type(this.getPointer()); + } + protected long getPointer () { return this.pointer; } + + public boolean fbregVariable () + { + long is_fb = fbreg_variable (this.getPointer()); + if (is_fb == 1) + return true; + else + return false; + } // protected native long dwarf_diecu(); private native long get_lowpc (); @@ -107,4 +140,12 @@ public class DwarfDie private native String get_diename (); private native long[] get_scopes (long addr); + + private native long get_scopesvar (long[] scopes, long nscopes, String variable); + + private native long get_addr (long addr); + + private native String get_type (long addr); + + private native long fbreg_variable (long addr); } Index: frysk-imports/lib/dw/cni/DwarfDie.cxx =================================================================== diff -u -p -r1.3 DwarfDie.cxx @@ -78,3 +82,96 @@ lib::dw::DwarfDie::get_scopes(jlong addr return longs; } + +Dwarf_Die *var_die; + +jlong +lib::dw::DwarfDie::get_scopesvar (jlongArray scopes, jlong nscopes, + jstring variable) +{ + // alloc this in java + var_die = (Dwarf_Die*)malloc(sizeof(Dwarf_Die)); + + Dwarf_Die *dies[nscopes]; + jlong* scopesp = elements(scopes); + + for(int i = 0; i < nscopes; i++) + { + jlong dieptr = scopesp[i]; + dies[i] = (Dwarf_Die*)dieptr; + } + + // have this return int declaring_scope + int code = dwarf_getscopevar (*dies, nscopes, + (const char*)JvGetStringChars(variable), + 0, NULL, 0, 0, var_die); + if (code >= 0) + return (jlong)var_die; + else + return 0; +} + +jlong +lib::dw::DwarfDie::get_addr (jlong var_die) +{ + Dwarf_Die *die = (Dwarf_Die*) var_die; + Dwarf_Block block; + Dwarf_Attribute loc_attr; + Dwarf_Op *fb_expr; + size_t fb_len; + + if (dwarf_attr_integrate (die, DW_AT_location, &loc_attr)) + { + dwarf_formblock (&loc_attr, &block); + dwarf_getlocation (&loc_attr, &fb_expr, &fb_len); + FILE *f = fopen ("/tmp/,dwarfdie", "w"); + fprintf (f, "fb_len %d atom %x operand %d offset %d\n", (int)fb_len, (int)fb_expr[0].atom, (int)fb_expr[0].number, (int)fb_expr[0].offset); + fclose (f); + return fb_expr[0].number; + } + else + return 0; +} + +jstring +lib::dw::DwarfDie::get_type (jlong var_die) +{ + Dwarf_Die *die = (Dwarf_Die*) var_die; + Dwarf_Die *type_die, type_mem_die; + Dwarf_Attribute type_attr; + + if (dwarf_attr_integrate (die, DW_AT_type, &type_attr)) + { + type_die = dwarf_formref_die (&type_attr, &type_mem_die); + if (dwarf_tag (type_die) == DW_TAG_base_type) + { + return JvNewStringLatin1 + (dwarf_formstring (dwarf_attr_integrate + (type_die, DW_AT_name, &type_attr))); + } + } + return 0; +} + +jlong +lib::dw::DwarfDie::fbreg_variable (jlong var_die) +{ + Dwarf_Die *die = (Dwarf_Die*) var_die; + Dwarf_Block block; + Dwarf_Attribute loc_attr; + Dwarf_Op *fb_expr; + size_t fb_len; + + if (dwarf_attr_integrate (die, DW_AT_location, &loc_attr)) + { + dwarf_formblock (&loc_attr, &block); + dwarf_getlocation (&loc_attr, &fb_expr, &fb_len); + FILE *f = fopen ("/tmp/,dwarfdie", "w"); + fprintf (f, "fb_len %d atom %x operand %d offset %d\n", (int)fb_len, (int)fb_expr[0].atom, (int)fb_expr[0].number, (int)fb_expr[0].offset); + fclose (f); + if (fb_expr[0].atom == DW_OP_fbreg) + return 1; + } + return 0; +} + From rmoseley@redhat.com Tue Sep 5 18:46:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Tue, 05 Sep 2006 18:46:00 -0000 Subject: Preliminary Documentation checked in Message-ID: <44FDC602.8000705@redhat.com> Hi all, I have checked in my first cut at the documentation. I checked in both a pdf and odt version(frysk_doc_1.0) in the htdocs/documentation directory. I had hoped to get it converted to html before I left on vacation, but, alas, that did not happen. I will try to do that when I get back from vacation on Sept. 18th. Rick From cmoller@redhat.com Tue Sep 5 18:51:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Tue, 05 Sep 2006 18:51:00 -0000 Subject: Preliminary Documentation checked in In-Reply-To: <44FDC602.8000705@redhat.com> References: <44FDC602.8000705@redhat.com> Message-ID: <44FDC742.7010308@redhat.com> I'll take a crack at that if you like--I grabbed a pdf2html converter Fridaythat seems to work well. Chris Rick Moseley mumbled something on 09/05/2006 02:46 PM: > Hi all, > > I have checked in my first cut at the documentation. I checked in > both a pdf and odt version(frysk_doc_1.0) in the htdocs/documentation > directory. I had hoped to get it converted to html before I left on > vacation, but, alas, that did not happen. I will try to do that when > I get back from vacation on Sept. 18th. > > Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From rmoseley@redhat.com Tue Sep 5 18:59:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Tue, 05 Sep 2006 18:59:00 -0000 Subject: Preliminary Documentation checked in In-Reply-To: <44FDC742.7010308@redhat.com> References: <44FDC602.8000705@redhat.com> <44FDC742.7010308@redhat.com> Message-ID: <44FDC92A.8030502@redhat.com> Chris Moller wrote: > I'll take a crack at that if you like--I grabbed a pdf2html converter > Fridaythat seems to work well. > > Chris > Sure, if you have the time. Thanks. Do you need the screenshots/graphics separately for the or can the converter take care of that? Rick > Rick Moseley mumbled something on 09/05/2006 02:46 PM: > >> Hi all, >> >> I have checked in my first cut at the documentation. I checked in >> both a pdf and odt version(frysk_doc_1.0) in the htdocs/documentation >> directory. I had hoped to get it converted to html before I left on >> vacation, but, alas, that did not happen. I will try to do that when >> I get back from vacation on Sept. 18th. >> >> Rick >> From ezannoni@redhat.com Tue Sep 5 19:08:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Tue, 05 Sep 2006 19:08:00 -0000 Subject: Frysk minutes 20060905 Message-ID: <17661.51678.659095.25687@localhost.redhat.com> testing: we need to get latest test coverage: Stan will do today Dogtail status: still no headless mode. Please Phil, file a bug against rhel5 and make it a beta2 blocker Problem also having dogtail rpms built often enough for fc6 and fc5. There are also bugs in the playback functionality, it doesn't work. File bugs against RHEL5. After that: increase coverage of gui testing. Phil says: please use the gui more often, to find more bugs. Let's not wait until we have to do a demo. Nurdin: write tests for eventviewer as well. Phil: increase coverage of monitor tests. Andrew: will try to record/play a demo with dogtail. Phil: more intelligent handling of the core exceptions/panic: need to improve that. Currently it's not really doing the right thing. Is there a way to figure out a severity of the error coming? Not really. Please have discussion on mailing list. Chris: is it possible to do automated testings via cron jobs. Roland suggests to run everyday in rhts. Can rhts run rawhide? Len: do you know? Is this possible? Is anybody running on fc6? Phil is still yum updating. Please run make check. Mark runs make check on fc6. Some improvements with the latest patches from Roland. This is from last week. Are there anymore "the whole machine hangs" kind of failures? Roland thinks no. Are there more "make check errors" probably yes. Yum update can be automated which would pull in the latest kernel, frysk cvs update and rebuild can be automated Chris to try to complete the automation of the above. Chris: 0xff: can anybody see the same sequence in the frysk logs? Please reply to Chris. libunwind: please test Alex patches. Andrew: to review. We can start plug it into the sourcewindow, in the space reserved for it already. The patches from Alex are not checked in yet. Please review and check in asap. Backtrace window: how does the stack backtrace deal with the inlined fnctions. Need to tink about this. Libunwind backtrace will not have inline info at all, you'll need to get this from the debuginfo. So the frame model for frysk will need to have that information in it. Rick: on vacation Sept 6 through Sept 18 Adam will have to pick that one up. Together with Mike. We cannot wait for Rick. Stan: posted what he has so far. Please review: using CNI, what's in Java, what's in C++: Comments? Display statics and locals. No frame support yet. Need to add more addressing modes. Interfacing to libdw is in frysk/imports. How about the command line interface? you can use print at the moment, but the GUI is not hooked up. GUI: hovering over a variable should display values: Hooks are there, Adam did them. So we need to use those to call into the expression evaluator. Also have an expression window in the source window: so that could do cut and paste of expressions. Eventviewer: fixing scrollbars. Weird errors, if focus is in a different window. Goes from longer scrollbar to shorter one. Consult with other teams, desktop, gnome. GTK textview code used. Only these bugs are left. And writing tests. Try to wrap things up in a week and a half. Mark: Breakpoints: Mark: cleaning up syscalls and signals interoperability with breakpoints. Writing tests too. Low level stuff should be done now. Does the source window have all the necessary stuff in the DOM? to map addresses to line numbers and vice versa. One to many? Many to one? Need to make sure we handle multiple breakpoints for one line. Tim: the high level breakpoint task it doesn't need GUI interaction right now, just manipulate from cli. User in gui will want to click on source line and set a breakpoint there. DOM has information to handle that. First: file:line-->address is first that we should be targetting, because that is the type of request when user clicks on line in the source window. The break "foo" stuff is more complicated. column information is emitted by the dwarf library, but gcc has no info about this. Did the syscall tracing get finished? ftrace you cannot track an already running process. It can ftrace a newly created program, started under ftrace. ftrace only works on x86, it doesn't really know about the syscalls on other arches. Didn't IBM have patches for ppc? It's just the syscall table missing. 32/64: Table for 32 bit syscalls on 64 bit machines, is different from pure 32 bit case(?). Mapping of 32-bit registers in 64-bit mode is also different. How do we test this? transition of a 64 bit to a 32 bit back and forth (forking a 32 bit from a 64 bit process and vice versa). Lots of corner cases. Could IBM look at this for ppc? But Tim should finish this as he started it. Disassembly: should it go in the source window as well? Yes. As a separate pane. This can be started now. Adam? Phil: concern about Java gnome: spent lot of time tracking a bug in it, and java-gnome people weren't really helpful. Memory management problem (premature free). Still not finished. Bug is still there. From pmuldoon@redhat.com Tue Sep 5 19:16:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 05 Sep 2006 19:16:00 -0000 Subject: Frysk minutes 20060905 In-Reply-To: <17661.51678.659095.25687@localhost.redhat.com> References: <17661.51678.659095.25687@localhost.redhat.com> Message-ID: <44FDCD2A.4040903@redhat.com> > Phil: concern about Java gnome: spent lot of time tracking a bug in > it, and java-gnome people weren't really helpful. Memory management > problem (premature free). Still not finished. Bug is still there. > > Sorry if I made this sound wrong. They were very helpful, it just seemed that the area of memory management did not have a lot of expertize associated with it. It leaves me somewhat worried about other areas of coverage. Going forward with future bugs, I have a concern that we do not have a huge amount of expertise in-house, and it leaves open how we can address similar situations, in the future. Regards Phil From cagney@redhat.com Tue Sep 5 20:07:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 05 Sep 2006 20:07:00 -0000 Subject: dogtail-20060905-branch with modified script Message-ID: <44FDD8F1.4030107@redhat.com> Len, I created dogtail-20060905-branch and committed my tweaks to your .py file there. (the tweaks are to get dogtail working using the pyunit test framework) Andrew From tromey@redhat.com Tue Sep 5 20:51:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 05 Sep 2006 20:51:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: Alexandre> Yes, sorry. I failed to refresh the patch file after Alexandre> renaming the method. I'm not sure whether I missed any Alexandre> other change, so here's the patch generated out of what I Alexandre> actually tested. I updated, applied this and built frysk. I'm using x86 FC5. Then I tried my 'fdtrace' program. I get somewhat weird results: opsy. ./frysk-core/frysk/bindir/fdtrace ../Closer bad close() call at: val = frysk.rt.StackFrame@157de0; in function: (Unknown file at line 0) val = frysk.rt.StackFrame@157db0; in function: (Unknown file at line 0) val = frysk.rt.StackFrame@157d80; in function: (Unknown file at line 0) This is an improvement since stack tracing used to just crash. And it is clearly doing something correctly, because that looks like a reasonable number of stack frames. But, it isn't finding the function name, file name, or line number properly. I've appended fdtrace.java... it is just a naively hacked copy of ftrace. 'Closer' is just a program that does a sequence of invalid closes: #include #include int main() { close(73); close(74); return 0; } Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: fdtrace.java Type: application/octet-stream Size: 6385 bytes Desc: fdtrace.java URL: From cmoller@redhat.com Tue Sep 5 21:22:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Tue, 05 Sep 2006 21:22:00 -0000 Subject: Preliminary Documentation checked in In-Reply-To: <44FDC92A.8030502@redhat.com> References: <44FDC602.8000705@redhat.com> <44FDC742.7010308@redhat.com> <44FDC92A.8030502@redhat.com> Message-ID: <44FDEA73.20400@redhat.com> Rick Moseley mumbled something on 09/05/2006 02:59 PM: > Chris Moller wrote: >> I'll take a crack at that if you like--I grabbed a pdf2html converter >> Fridaythat seems to work well. >> >> Chris >> > Sure, if you have the time. Thanks. > > Do you need the screenshots/graphics separately for the or can the > converter take care of that? The converter seems to extract the graphics directly from the PDF, but I'll check that tonight. Either way, between the PDF and the odt, I'll be able to extract them if I need to. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From pmuldoon@redhat.com Tue Sep 5 21:34:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 05 Sep 2006 21:34:00 -0000 Subject: Test and fix for syscall observer adding (bug #3147) In-Reply-To: <1157373132.2965.85.camel@dijkstra.wildebeest.org> References: <1157114157.3062.16.camel@dijkstra.wildebeest.org> <1157117181.6659.4.camel@hermans.wildebeest.org> <1157144484.6659.18.camel@hermans.wildebeest.org> <1157373132.2965.85.camel@dijkstra.wildebeest.org> Message-ID: <44FDED5E.1060502@redhat.com> I just managed to take a look at this. A smoke test from the ui (where the problem is seen) shows that the error has been fixed. However I'd like to test it a little more before I close the bug. For reference, could you have a stab at explaining how this was not caught in the core testsuite, but the ui exposed it? When a bug only happens in the ui it is very tricky to write up a deterministic failure-reproducer, so we are somewhat stuck when we see situations like this. :( Regards Phil Mark Wielaard wrote: > Hi, > > On Fri, 2006-09-01 at 23:01 +0200, Mark Wielaard wrote: > >> For the testcase I can of course do some tricks and see if accept() is a >> syscall or, if not, whether socketcall() is available and then select >> based on the first argument of the syscall to see if it really is accept >> (#5). But this seems 1) fragile and 2) looks like a general problem >> people will have when using Syscall Observers. >> > > I worked around it for the test case by just using the SYSread call for > now: > > 2006-09-04 Mark Wielaard > > * funit-syscall-running.c: Accept socket and read() for it. > > 2006-09-04 Mark Wielaard > > * TestSyscallRunning.java: Added back, use SYSread and write to > Socket. > > For the testcase this is OK since it just tests something low-level. But > I think in general we have to look how people will want to use the > syscalls and whether or not to provide something more portable and > higher level. > > Cheers, > > Mark > > ------------------------------------------------------------------------ > > Index: frysk-core/frysk/pkglibexecdir/funit-syscall-running.c > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/pkglibexecdir/funit-syscall-running.c,v > retrieving revision 1.1 > diff -u -u -r1.1 funit-syscall-running.c > --- frysk-core/frysk/pkglibexecdir/funit-syscall-running.c 1 Sep 2006 12:34:10 -0000 1.1 > +++ frysk-core/frysk/pkglibexecdir/funit-syscall-running.c 4 Sep 2006 12:16:40 -0000 > @@ -40,6 +40,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -74,32 +75,27 @@ > printf("%d\n", ntohs (addr.sin_port)); > fflush(stdout); > > - int runs; > - // Go round and round. > - while (1) > + struct sockaddr_in sai; > + len = sizeof (sai); > + fflush(stderr); > + int f = accept (fd, (struct sockaddr *) &sai, &len); > + if (f == -1) > { > - // Wait till we are OK to go! > - runs = getchar(); > - if (runs == 0) > - break; > - if (runs < 0) > - { > - fprintf(stderr, "Couldn't read runs\n"); > - break; > - } > - > - while(runs--) > - { > - struct sockaddr_in c; > - len = sizeof (c); > - fflush(stderr); > - if (accept (fd, (struct sockaddr *) &c, &len) == -1) > - { > - perror ("accept"); > - exit (-1); > - } > - } > + perror ("accept"); > + exit (-1); > } > > - return runs; > + // Wait for the start sign > + getchar(); > + > + char cs[1]; > + // Keep reading from the socket till it is closed. > + ssize_t c = 1; > + while (c > 0) > + c = read(f, &cs, 1); > + > + if (c < 0) > + perror ("read"); > + > + return c; > } > Index: frysk-core/frysk/proc/TestSyscallRunning.java > =================================================================== > RCS file: frysk-core/frysk/proc/TestSyscallRunning.java > diff -N frysk-core/frysk/proc/TestSyscallRunning.java > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ frysk-core/frysk/proc/TestSyscallRunning.java 4 Sep 2006 12:16:40 -0000 > @@ -0,0 +1,371 @@ > +// This file is part of the program FRYSK. > +// > +// Copyright 2006, Red Hat Inc. > +// > +// FRYSK is free software; you can redistribute it and/or modify it > +// under the terms of the GNU General Public License as published by > +// the Free Software Foundation; version 2 of the License. > +// > +// FRYSK is distributed in the hope that it will be useful, but > +// WITHOUT ANY WARRANTY; without even the implied warranty of > +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +// General Public License for more details. > +// > +// You should have received a copy of the GNU General Public License > +// along with FRYSK; if not, write to the Free Software Foundation, > +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. > +// > +// In addition, as a special exception, Red Hat, Inc. gives You the > +// additional right to link the code of FRYSK with code not covered > +// under the GNU General Public License ("Non-GPL Code") and to > +// distribute linked combinations including the two, subject to the > +// limitations in this paragraph. Non-GPL Code permitted under this > +// exception must only link to the code of FRYSK through those well > +// defined interfaces identified in the file named EXCEPTION found in > +// the source code files (the "Approved Interfaces"). The files of > +// Non-GPL Code may instantiate templates or use macros or inline > +// functions from the Approved Interfaces without causing the > +// resulting work to be covered by the GNU General Public > +// License. Only Red Hat, Inc. may make changes or additions to the > +// list of Approved Interfaces. You must obey the GNU General Public > +// License in all respects for all of the FRYSK code and other code > +// used in conjunction with FRYSK except the Non-GPL Code covered by > +// this exception. If you modify this file, you may extend this > +// exception to your version of the file, but you are not obligated to > +// do so. If you do not wish to provide this exception without > +// modification, you must delete this exception statement from your > +// version and license this file solely under the GPL without > +// exception. > + > +package frysk.proc; > + > +import java.io.*; > +import java.net.*; > + > +import frysk.sys.SyscallNum; > + > +public class TestSyscallRunning > + extends TestLib > +{ > + // Process id and Proc representation of our test program. > + int pid; > + Proc proc; > + > + // How we communicate with the test program. > + BufferedReader in; > + DataOutputStream out; > + > + // The thread that handles the event loop. > + EventLoopRunner eventloop; > + > + // Monitor to notify and wait on for state of event changes.. > + static Object monitor = new Object(); > + > + /** > + * Launch our test program and setup clean environment with a runner > + * eventloop. > + */ > + public void setUp() > + { > + // Make sure everything is setup so spawned processes are recognized > + // and destroyed in tearDown(). > + super.setUp(); > + > + // Create a process that we will communicate with through stdin/out. > + String command = TestLib.getExecPrefix() + "funit-syscall-running"; > + ForkTestLib.ForkedProcess process; > + process = ForkTestLib.fork(new String[] { command }); > + pid = process.pid; > + > + in = new BufferedReader(new InputStreamReader(process.in)); > + out = new DataOutputStream(process.out); > + > + // Make sure the core knows about it. > + Manager.host.requestRefreshXXX(true); > + Manager.eventLoop.runPending(); > + proc = Manager.host.getProc(new ProcId(pid)); > + > + // Start an EventLoop so we don't have to poll for events all the time. > + eventloop = new EventLoopRunner(); > + eventloop.start(); > + } > + > + /** > + * Make sure the test program is really gone and the event loop is > + * stopped. Individual tests are responsible for nice termination > + * if the want to. > + */ > + public void tearDown() > + { > + // Make sure event loop is gone. > + eventloop.requestStop(); > + synchronized (monitor) > + { > + while (!eventloop.isStopped()) > + { > + try > + { > + monitor.wait(); > + } > + catch (InterruptedException ie) > + { > + // Ignored > + } > + } > + } > + > + // And kill off any remaining processes we spawned > + super.tearDown(); > + } > + > + public void testSyscallRunning() throws IOException > + { > + // Get the port that will be listened on and connect to it. > + String line = in.readLine(); > + int port = Integer.decode(line).intValue(); > + Socket s = new Socket("localhost", port); > + > + final Task task = proc.getMainTask(); > + > + final SyscallObserver syso = new SyscallObserver(); > + task.requestAddSyscallObserver(syso); > + > + // Make sure the observer is properly installed. > + synchronized (monitor) > + { > + while (! syso.isAdded()) > + { > + try > + { > + monitor.wait(); > + } > + catch (InterruptedException ie) > + { > + // ignored > + } > + } > + } > + > + // Tell the process to go some rounds! > + out.writeByte(1); > + out.flush(); > + > + // Wait till our syscall observer triggers and blocks > + synchronized (monitor) > + { > + while (! syso.getEntered()) > + { > + try > + { > + monitor.wait(); > + } > + catch (InterruptedException ie) > + { > + // ignored > + } > + } > + } > + > + // Now unblock and then attach another observer. > + // Do all this on the eventloop so properly serialize calls. > + final SyscallObserver syso2 = new SyscallObserver(); > + Manager.eventLoop.add(new TaskEvent() > + { > + public void execute () > + { > + // Continue running (inside syscall), > + // while attaching another syscall observer > + task.requestUnblock(syso); > + task.requestAddSyscallObserver(syso2); > + } > + }); > + > + // Wait till we are properly added... > + synchronized (monitor) > + { > + while (! syso2.isAdded()) > + { > + try > + { > + monitor.wait(); > + } > + catch (InterruptedException ie) > + { > + // ignored > + } > + } > + } > + > + // Sanity check > + assertTrue(syso.getEntered()); > + assertFalse(syso.getExited()); > + assertFalse(syso2.getEntered()); > + assertFalse(syso2.getExited()); > + > + // Write something to the socket and close it so the syscall exits. > + OutputStream out = s.getOutputStream(); > + out.write(1); > + out.flush(); > + s.close(); > + > + // And check that the observers trigger > + synchronized (monitor) > + { > + while (! syso.getExited() || ! syso2.getExited()) > + { > + try > + { > + monitor.wait(); > + } > + catch (InterruptedException ie) > + { > + // ignored > + } > + } > + } > + } > + > + /** > + * Observer that looks for open and close syscalls. > + * After a given number of calls it will BLOCK from the syscall enter. > + */ > + class SyscallObserver implements TaskObserver.Syscall > + { > + private boolean entered; > + private boolean exited; > + private boolean added; > + private boolean removed; > + > + SyscallObserver() > + { > + } > + > + public Action updateSyscallEnter(Task task) > + { > + SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task); > + int syscallNum = syscallEventInfo.number (task); > + if (syscallNum == SyscallNum.SYSread) > + { > + entered = true; > + synchronized(monitor) > + { > + monitor.notifyAll(); > + return Action.BLOCK; > + } > + } > + return Action.CONTINUE; > + } > + > + public Action updateSyscallExit(Task task) > + { > + SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task); > + int syscallNum = syscallEventInfo.number (task); > + if (syscallNum == SyscallNum.SYSread) > + { > + exited = true; > + synchronized(monitor) > + { > + monitor.notifyAll(); > + } > + } > + return Action.CONTINUE; > + } > + > + boolean getEntered() > + { > + return entered; > + } > + > + boolean getExited() > + { > + return exited; > + } > + > + public void addFailed(Object observable, Throwable w) > + { > + w.printStackTrace(); > + fail(w.getMessage()); > + } > + > + public void addedTo(Object observable) > + { > + // Hurray! Lets notify everybody. > + synchronized (monitor) > + { > + added = true; > + removed = false; > + monitor.notifyAll(); > + } > + } > + > + public boolean isAdded() > + { > + return added; > + } > + > + public void deletedFrom(Object observable) > + { > + synchronized (monitor) > + { > + removed = true; > + added = true; > + monitor.notifyAll(); > + } > + } > + > + public boolean isRemoved() > + { > + return removed; > + } > + > + private SyscallEventInfo getSyscallEventInfo(Task task) > + { > + try > + { > + return task.getSyscallEventInfo(); > + } > + catch (TaskException e) > + { > + fail("task exception " + e); > + return null; // not reached > + } > + } > + } > + > + static class EventLoopRunner extends Thread > + { > + private boolean stopped; > + > + public void run() > + { > + stopped = false; > + try > + { > + Manager.eventLoop.run(); > + } > + finally > + { > + synchronized (monitor) > + { > + stopped = true; > + monitor.notifyAll(); > + } > + } > + } > + > + public void requestStop() > + { > + Manager.eventLoop.requestStop(); > + } > + > + public boolean isStopped() > + { > + return stopped; > + } > + > + public String toString() > + { > + return "EventLoop-" + super.toString(); > + } > + } > +} > From mark@klomp.org Tue Sep 5 22:08:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 05 Sep 2006 22:08:00 -0000 Subject: Test and fix for syscall observer adding (bug #3147) In-Reply-To: <44FDED5E.1060502@redhat.com> References: <1157114157.3062.16.camel@dijkstra.wildebeest.org> <1157117181.6659.4.camel@hermans.wildebeest.org> <1157144484.6659.18.camel@hermans.wildebeest.org> <1157373132.2965.85.camel@dijkstra.wildebeest.org> <44FDED5E.1060502@redhat.com> Message-ID: <1157494050.6876.39.camel@dijkstra.wildebeest.org> Hi Phil, On Tue, 2006-09-05 at 16:34 -0500, Phil Muldoon wrote: > I just managed to take a look at this. A smoke test from the ui (where > the problem is seen) shows that the error has been fixed. However I'd > like to test it a little more before I close the bug. Great, thanks for testing. > For reference, could you have a stab at explaining how this was not > caught in the core testsuite, but the ui exposed it? When a bug only > happens in the ui it is very tricky to write up a deterministic > failure-reproducer, so we are somewhat stuck when we see situations like > this. :( I don't know. This was just one case for which there was no explicit testcase. There is one now to make sure it stays fixed. I wasn't actually able to reproduce it using FryskGui, but since you attached a log I was able to deduce what was happening and write a core test that replicated the issue. Cheers, Mark From tromey@redhat.com Tue Sep 5 22:40:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 05 Sep 2006 22:40:00 -0000 Subject: Patch: StackFrame.toString() Message-ID: I thought it would be handy if StackFrame had a toString method that did something sensible. Patch appended. BTW it would be nice if the boundary cases for StackFrame accessor methods were documented -- this toString is written assuming: * getMethodName could return null or the empty string if it can't get the function's name (and btw the name "getMethodName" is kind of a misnomer IMO) * getSourceFile will return null if the source file name can't be found * getLineNumber will return 0 if the line number is not known I'm happy to document these accessors if someone would confirm that this is the intended interpretation. Tom Index: frysk-core/frysk/rt/ChangeLog from Tom Tromey * StackFrame.java (toString): New method. Index: frysk-core/frysk/rt/StackFrame.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/rt/StackFrame.java,v retrieving revision 1.4 diff -u -r1.4 StackFrame.java --- frysk-core/frysk/rt/StackFrame.java 26 Jul 2006 16:24:00 -0000 1.4 +++ frysk-core/frysk/rt/StackFrame.java 5 Sep 2006 22:12:13 -0000 @@ -136,4 +136,37 @@ { return outer; } + + /** + * Return a string representation of this stack frame. + * The returned string is suitable for display to the user. + */ + public String toString () + { + StringBuffer builder = new StringBuffer("at 0x"); + builder.append(Long.toHexString(getAddress())); + String mn = getMethodName(); + if (mn != null && ! "".equals(mn)) + { + builder.append(" in function: "); + builder.append(getMethodName()); + } + String sf = getSourceFile(); + int line = getLineNumber(); + if (sf != null || line != 0) + { + builder.append(" ("); + if (sf != null) + builder.append(sf); + else + builder.append("Unknown source"); + if (line != 0) + { + builder.append(":"); + builder.append(line); + } + builder.append(")"); + } + return builder.toString(); + } } From tromey@redhat.com Wed Sep 6 00:21:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Wed, 06 Sep 2006 00:21:00 -0000 Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures In-Reply-To: <1157377857.3629.16.camel@dijkstra.wildebeest.org> References: <20060904114640.GC13314@GreenHouse.cn.ibm.com> <1157377857.3629.16.camel@dijkstra.wildebeest.org> Message-ID: Mark> It is a little unfortunate that there is no canonical list of Mark> syscalls and numbers per architecture. Reflection for the kernel APIs would be useful here. ;-) Mark> For some of these "sub-syscalls" I think it would be better to treat Mark> them as if they were really syscalls for those that are real syscalls on Mark> some other architecture (that is what strace and systemtap do). And I Mark> would propose minimize the usage of numbers. So only have a factory Mark> getSyscall(String) and not one based on numbers (since those differ Mark> between architectures and make it impossible to get any 'sub-syscalls'). Mark> If so then we should also drop the number() from SyscallEventInfo and Mark> replace it with a syscall() method that just returns the Syscall object. This sounds fairly reasonable to me. One use case I came up with is supporting strace's -o option in ftrace. Consider 'ftrace -o '... in this case we'd need to be able to look at a SyscallEventInfo and test "is it ?". Probably this would mean putting some "model" object representing the syscall into a hashset. In the current setup one plausible approach would be to have multiple Syscall objects with the same number but different names. Then, SyscallEventInfo would have an accessor to return the corresponding Syscall -- which would be the "decoded" one. Finally, Syscall would have an equals() method that would compare both the name and the number. The only oddity then would be what to do in the case where an unknown number is passed to syscallByNum. But ... I wonder if this should simply throw an exception. Tom From cmoller@redhat.com Wed Sep 6 03:40:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Wed, 06 Sep 2006 03:40:00 -0000 Subject: Preliminary Documentation checked in In-Reply-To: <44FDEA73.20400@redhat.com> References: <44FDC602.8000705@redhat.com> <44FDC742.7010308@redhat.com> <44FDC92A.8030502@redhat.com> <44FDEA73.20400@redhat.com> Message-ID: <44FE4334.1070907@redhat.com> I converted Rick's doc. The utility I used (sourceforge pdftohtml version 0.39) has a kind of "simple" format, the result of which is at: http://www.mollerware.com/frysk/simple/frysk_doc_1.0.html There's also what the utility calls "complex" format which is a whole lot prettier: http://www.mollerware.com/frysk/complex/frysk_doc_1.0.html The straight-from-sourceforge version (0.39) I built last Friday works fine; the version in fc6t2 (v 0.36) produces really crummy output. If we want to make the html version publicly available, I expect we should probably prebuild it rather than just shipping the PDF and having the html generated in the frysk build process. Both of these formats result in a bunch of files--16 for simple, 42 for complex. If anyone wants me to commit this stuff to the frysk tree, I expect it ought to be in it's own dir under htdocs/documentation, but I'll do it any way y'all want me too. cm Chris Moller mumbled something on 09/05/06 17:21: > Rick Moseley mumbled something on 09/05/2006 02:59 PM: > >> Chris Moller wrote: >> >>> I'll take a crack at that if you like--I grabbed a pdf2html converter >>> Fridaythat seems to work well. >>> >>> Chris >>> >>> >> Sure, if you have the time. Thanks. >> >> Do you need the screenshots/graphics separately for the or can the >> converter take care of that? >> > > The converter seems to extract the graphics directly from the PDF, but > I'll check that tonight. Either way, between the PDF and the odt, I'll > be able to extract them if I need to. > > Chris > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From woodzltc@cn.ibm.com Wed Sep 6 04:03:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 06 Sep 2006 04:03:00 -0000 Subject: Frysk minutes 20060905 In-Reply-To: <17661.51678.659095.25687@localhost.redhat.com> References: <17661.51678.659095.25687@localhost.redhat.com> Message-ID: <44FE4885.9030303@cn.ibm.com> Elena Zannoni wrote: > Is anybody running on fc6? Phil is still yum updating. Please run make > check. Mark runs make check on fc6. Some improvements with the latest > patches from Roland. This is from last week. Are there anymore "the > whole machine hangs" kind of failures? Roland thinks no. > Are there more "make check errors" probably yes. We are also running frysk and its testsuite on fc6. The shipped frysk in the .ppc64.rpm will trigger segmentation fault on fc6. We are now checking out and building the cvs source to see how they work. > libunwind: please test Alex patches. Andrew: to review. We can start > plug it into the sourcewindow, in the space reserved for it already. > The patches from Alex are not checked in yet. Please review and check > in asap. We had a test. TestStackBacktrace works ok with this patch applied. But we have a concern that frysk-sys are using some synchronization mechanism to handle ptrace requests. This patch use ptrace directly. Is it possible some synchroinization problem might be introduced in? For ppc64, we are having one engineer in US working on the porting. Anyway, it will lag behind x86 and x86_64. To make the later ppc64 merge-in more easily, could I request that we can isolate these architecture dependent code as early as possible? In fact, libunwind are already supporting x86 and x86_64. So at the design time, we need to give consideration to both. If some architecture dependent issues are identified, would you please also leave some space for ppc64 as well. > Did the syscall tracing get finished? ftrace you cannot track an > already running process. It can ftrace a newly created program, > started under ftrace. ftrace only works on x86, it doesn't really know > about the syscalls on other arches. Didn't IBM have patches for ppc? > It's just the syscall table missing. > > 32/64: Table for 32 bit syscalls on 64 bit machines, is different from > pure 32 bit case(?). Mapping of 32-bit registers in 64-bit mode is > also different. How do we test this? transition of a 64 bit to a 32 > bit back and forth (forking a 32 bit from a 64 bit process and vice > versa). Lots of corner cases. Could IBM look at this for ppc? But Tim > should finish this as he started it. We are thinking about the above two issues all the time. And we found they are not only specific on ppc64, they are problems of more general background instead. We are missing syscall table right now, but the current method to generate syscalls having its internal issues. Yao ever introduced a thread to talk about that. We would like to see more comments about his proposal. The bi-arch support is also relevant. A good solution to handle 32-bit and 64-bit syscall at the same time can lead to a better bi-arch support. More tests are also needed. > Disassembly: should it go in the source window as well? Yes. As a > separate pane. This can be started now. Adam? Yao had a patch about that (http://sources.redhat.com/ml/frysk/2006-q3/msg00371.html). Anyone can take a look and review. Thanks. Regards - Wu Zhou From qiyaoltc@cn.ibm.com Wed Sep 6 04:03:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 06 Sep 2006 04:03:00 -0000 Subject: Sign extend 32-bit register values and Bug #3055 Message-ID: <20060906040250.GE13314@GreenHouse.cn.ibm.com> long in java is 64-bit, and 32-bit register value should be sign extended. We override Register.get() in Isa to do sign extension for Ia32 and PPC(32-bit platforms). 2006-09-06 Yao Qi * IsaPPC.java (get): Sign extend 32-bit value to 64-bit. * IsaIA32.java (get): Likewise. * TestRegs.java: Test sign extension on I386. * Syscall.java (printReturn): Do not cast returnCode to int. 2006-09-05 Yao Qi * funit-ia32-regs.S (main): Set %edx to -4 for sign extension test. Please review this patch, and comments are welcome. Thanks! -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S,v retrieving revision 1.2 diff -u -r1.2 funit-ia32-regs.S --- frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S 27 Jun 2006 15:28:53 -0000 1.2 +++ frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S 5 Sep 2006 09:42:42 -0000 @@ -44,7 +44,7 @@ mov $1, %eax // exit syscall number mov $2, %ebx // first syscall arg mov $3, %ecx - mov $4, %edx + mov $-4, %edx mov $5, %ebp mov $6, %esi mov $7, %edi Index: frysk-core/frysk/proc/IsaIA32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v retrieving revision 1.4 diff -u -r1.4 IsaIA32.java --- frysk-core/frysk/proc/IsaIA32.java 29 Aug 2006 05:35:43 -0000 1.4 +++ frysk-core/frysk/proc/IsaIA32.java 5 Sep 2006 09:42:43 -0000 @@ -57,6 +57,13 @@ { super(0, wordOffset * 4, 4, name); } + // sign extend all 32-bit register values to 64-bit long. + public long get(frysk.proc.Task task) + { + int val; + val = (int) super.get(task); + return val; + } } static class IA32SegmentRegister Index: frysk-core/frysk/proc/IsaPPC.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC.java,v retrieving revision 1.2 diff -u -r1.2 IsaPPC.java --- frysk-core/frysk/proc/IsaPPC.java 23 Aug 2006 04:04:19 -0000 1.2 +++ frysk-core/frysk/proc/IsaPPC.java 5 Sep 2006 09:42:43 -0000 @@ -17,6 +17,13 @@ { super (0, wordOffset * 4, 4, name); } + // sign extend all 32-bit register values to 64-bit long. + public long get(frysk.proc.Task task) + { + int val; + val = (int) super.get(task); + return val; + } } private static PPCRegister[] gprs () Index: frysk-core/frysk/proc/Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Syscall.java,v retrieving revision 1.11 diff -u -r1.11 Syscall.java --- frysk-core/frysk/proc/Syscall.java 24 Aug 2006 03:13:05 -0000 1.11 +++ frysk-core/frysk/proc/Syscall.java 5 Sep 2006 09:42:44 -0000 @@ -197,7 +197,7 @@ writer.println (""); break; case 'i': - arg = (int)syscallEventInfo.returnCode (task); + arg = syscallEventInfo.returnCode (task); if (arg < 0) { writer.print ("-1"); writer.println (" ERRNO=" + (-arg)); Index: frysk-core/frysk/proc/TestRegs.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/TestRegs.java,v retrieving revision 1.2 diff -u -r1.2 TestRegs.java --- frysk-core/frysk/proc/TestRegs.java 31 Aug 2006 05:57:47 -0000 1.2 +++ frysk-core/frysk/proc/TestRegs.java 5 Sep 2006 09:42:44 -0000 @@ -415,7 +415,7 @@ assertEquals ("orig_eax register", 1, t.orig_eax); assertEquals ("ebx register", 2, t.ebx); assertEquals ("ecx register", 3, t.ecx); - assertEquals ("edx register", 4, t.edx); + assertEquals ("edx register", -4, t.edx); assertEquals ("ebp register", 5, t.ebp); assertEquals ("esi register", 6, t.esi); assertEquals ("edi register", 7, t.edi); From cagney@redhat.com Wed Sep 6 04:31:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 06 Sep 2006 04:31:00 -0000 Subject: Frysk minutes 20060905 In-Reply-To: <44FE4885.9030303@cn.ibm.com> References: <17661.51678.659095.25687@localhost.redhat.com> <44FE4885.9030303@cn.ibm.com> Message-ID: <44FE4F18.5050506@redhat.com> Wu Zhou wrote: > >> libunwind: please test Alex patches. Andrew: to review. We can start >> plug it into the sourcewindow, in the space reserved for it already. >> The patches from Alex are not checked in yet. Please review and check >> in asap. > > We had a test. TestStackBacktrace works ok with this patch applied. > But we have a concern that frysk-sys are using some synchronization > mechanism to handle ptrace requests. This patch use ptrace directly. > Is it possible some synchroinization problem might be introduced in? > Wu, good catch. Yes, the backtrace code cannot call ptrace directory; it will not work. All ptrace calls must be routed through the ptrace thread that Mike added. Andrew From cagney@redhat.com Wed Sep 6 05:06:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 06 Sep 2006 05:06:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> Message-ID: <44FE5749.90509@redhat.com> > > >> Is there any code available right now? If yes, we would be very happy to have a look at that first. >> > > Here's the patch I've just completed, that works on x86, and fixes a > potential libunwind memory leak while at that. > > As it turns out, libunwind already has all that we need, we were just > missing the proper way to use it. dwarf_find_proc_info() was not it, > since it's specifically designed to operate on the local process. > Part of the libunwind-ptrace interface offers access to everything we > need as far as locating unwind tables et al is concerned, while still > using our own callbacks to interact with the process using ptrace or > whatever. I'm not sure why we don't just bite the bullet and use all > of the libunwind interface (it looks like it would be much simpler and > would get us what we want), but I figured I wouldn't remove any such > code for now. > Unfortunatly having frysk use the ptrace calls found in libunwind-ptrace.a would be wrong. All ptrace calls to an attached process must be routed through a single thread and libunwind code won't be executed within that thread; and would immediatly limit frysk to native only. If you think the ptrace limitation is lame then argue it out with the kernel developers. Do any of the _UPT_* calls you added interact with either /proc or ptrace? Why is the cpu specific library required? + ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a Andrew From aoliva@redhat.com Wed Sep 6 06:42:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 06 Sep 2006 06:42:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <44FE5749.90509@redhat.com> (Andrew Cagney's message of "Wed, 06 Sep 2006 01:06:17 -0400") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FE5749.90509@redhat.com> Message-ID: On Sep 6, 2006, Andrew Cagney wrote: > Do any of the _UPT_* calls you added interact with either /proc or ptrace? Nope, that was the point of the split. I suppose we could still use libunwind-ptrace's get_proc_name, and only use our Java interfaces for stuff that actually interacts with the target process. I wonder if this would fix Tom's reported bug. > Why is the cpu specific library required? > + ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a -ENOCLUE, it was already there: -GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a +GEN_GCJ_LDADD += ../frysk-imports/libunwind/src/libunwind-ptrace.a \ + ../frysk-imports/libunwind/src/libunwind-$(libunwind_cpu).a -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Wed Sep 6 06:46:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 06 Sep 2006 06:46:00 -0000 Subject: [htdocs patch] Build 64-bit frysk on PPC64 In-Reply-To: <1157456806.3112.13.camel@dijkstra.wildebeest.org> (Mark Wielaard's message of "Tue, 05 Sep 2006 13:46:40 +0200") References: <20060905024257.GD13314@GreenHouse.cn.ibm.com> <1157456806.3112.13.camel@dijkstra.wildebeest.org> Message-ID: On Sep 5, 2006, Mark Wielaard wrote: > On Tue, 2006-09-05 at 10:42 +0800, Yao Qi wrote: >> It is a little different on PPC64 to build a 64-bit frysk. This patch >> adds some instructions for building 64-bit frysk on >> htdocs/build/index.html. >> [...] >> +$ ( export PKG_CONFIG_PATH=/usr/lib64/pkgconfig ) >> +$ ( mkdir build && cd build ) >> +$ ( CC='gcc -m64' GCJ='gcj -m64' GCJLINK='gcj -m64' CXX='g++ -m64' ../frysk/autogen.sh ) > The idea seems to be that we always want a 64 bit version of frysk when > we are on ppc64 (and 32bit ppc isn't supported atm it seems). So doesn't > it make more sense to adapt autogen to recognizes this and put in the > right flags by default? Then the user doesn't need to remember any > special flags while building. This is generally not something for autogen or the package's own build machinery, but rather for the RPM build machinery. The reason is that the package itself should do build as closely as possible to what the user asks, without making surprising changes behind the user's back. There are presumably ppc systems that don't include 64-bit support, libraries, etc, so it would just break the build to try to default to that, especially if the system itself claims to be ppc not ppc64. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Wed Sep 6 08:01:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 06 Sep 2006 08:01:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Tom Tromey's message of "05 Sep 2006 14:45:45 -0600") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 5, 2006, Tom Tromey wrote: > opsy. ./frysk-core/frysk/bindir/fdtrace ../Closer > bad close() call at: > val = frysk.rt.StackFrame@157de0; in function: (Unknown file at line 0) > val = frysk.rt.StackFrame@157db0; in function: (Unknown file at line 0) > val = frysk.rt.StackFrame@157d80; in function: (Unknown file at line 0) > This is an improvement since stack tracing used to just crash. And it > is clearly doing something correctly, because that looks like a > reasonable number of stack frames. Yeah, but it's not quite correct. The innermost frame is for the vdso syscall, the second is for the glibc entry point, and the last is not for main as one might expect, but rather for _start, which has no debug info. So get_proc_name() is working as expected (assuming you don't have glibc-debuginfo, that is). I don't see anything in libdw that will try to get vdso debug info over ptrace or somesuch, and I see that there's no debug info for _start. What I don't know is why it's skipping the main() frame. I'll get back to it after getting some sleep. FWIW, I experimented with libunwind-ptrace's get_proc_name before, and that didn't quite work because it needs the pid passed to _UPT_create() to be correct, and we don't have the target process's pid readily availabel at that point. The reason for this is that it opens /proc//maps to figure out the nwhat binaries are mapped in or some such. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mark@klomp.org Wed Sep 6 09:10:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 06 Sep 2006 09:10:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <44FE5749.90509@redhat.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FE5749.90509@redhat.com> Message-ID: <1157533819.2996.13.camel@dijkstra.wildebeest.org> Hi, On Wed, 2006-09-06 at 01:06 -0400, Andrew Cagney wrote: > > As it turns out, libunwind already has all that we need, we were just > > missing the proper way to use it. dwarf_find_proc_info() was not it, > > since it's specifically designed to operate on the local process. > > Part of the libunwind-ptrace interface offers access to everything we > > need as far as locating unwind tables et al is concerned, while still > > using our own callbacks to interact with the process using ptrace or > > whatever. I'm not sure why we don't just bite the bullet and use all > > of the libunwind interface (it looks like it would be much simpler and > > would get us what we want), but I figured I wouldn't remove any such > > code for now. > > > Unfortunatly having frysk use the ptrace calls found in > libunwind-ptrace.a would be wrong. All ptrace calls to an attached > process must be routed through a single thread and libunwind code won't > be executed within that thread; and would immediatly limit frysk to > native only. If you think the ptrace limitation is lame then argue it > out with the kernel developers. We could make the PtraceThread more general so you can schedule any code for execution on it, not just direct ptrace calls. Then you could wrap any code that depends on ptrace calls into a Runnable and just put it on the PtraceThread run queue. Cheers, Mark From mark@klomp.org Wed Sep 6 09:36:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 06 Sep 2006 09:36:00 -0000 Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures In-Reply-To: References: <20060904114640.GC13314@GreenHouse.cn.ibm.com> <1157377857.3629.16.camel@dijkstra.wildebeest.org> Message-ID: <1157535373.2996.21.camel@dijkstra.wildebeest.org> Hi Tom, On Tue, 2006-09-05 at 18:15 -0600, Tom Tromey wrote: > One use case I came up with is supporting strace's -o option in > ftrace. Consider 'ftrace -o '... in this case we'd need to be able > to look at a SyscallEventInfo and test "is it ?". Probably this > would mean putting some "model" object representing the syscall > into a hashset. Do you mean the -e option? ( My version of ftrace has -o being redirect output to . > In the current setup one plausible approach would be to have multiple > Syscall objects with the same number but different names. Then, > SyscallEventInfo would have an accessor to return the corresponding > Syscall -- which would be the "decoded" one. Finally, Syscall would > have an equals() method that would compare both the name and the > number. Yes, that seems the right approach. > The only oddity then would be what to do in the case where an unknown > number is passed to syscallByNum. But ... I wonder if this should > simply throw an exception. Not an exception. Sometimes new system calls are introduced. It should just return a Syscall object for number xyz with as name "unknown-xyz" so as to be unique. Cheers, Mark From qiyaoltc@cn.ibm.com Wed Sep 6 11:43:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 06 Sep 2006 11:43:00 -0000 Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures In-Reply-To: <1157535373.2996.21.camel@dijkstra.wildebeest.org> References: <20060904114640.GC13314@GreenHouse.cn.ibm.com> <1157377857.3629.16.camel@dijkstra.wildebeest.org> <1157535373.2996.21.camel@dijkstra.wildebeest.org> Message-ID: <20060906114401.GF13314@GreenHouse.cn.ibm.com> On Wed, Sep 06, 2006 at 11:36:12AM +0200, Mark Wielaard wrote: > > Do you mean the -e option? ( > My version of ftrace has -o being redirect output to . Do you mean strace here? :) There is no option for frace now. > > In the current setup one plausible approach would be to have multiple > > Syscall objects with the same number but different names. Then, > > SyscallEventInfo would have an accessor to return the corresponding > > Syscall -- which would be the "decoded" one. Finally, Syscall would > > have an equals() method that would compare both the name and the > > number. > > Yes, that seems the right approach. syscalls with different names but the same number could only be found on x86, and I could not find the similar case on other platforms. Actually, I start to rewrite Syscall.java, SyscallEventInfo.java and Linux.java. I am not sure I am on a right way, so any advice is appreciated. 1) Write a new method getSyscall() in SyscallEventInfo to return a Syscall object from a *certain* syscallList. 2) Build syscallList in every Linux.java. syscallList varies from ISA, so I place syscallList from Syscall.java to Linux.java On i386, there are 2 syscall numbers for a group of "subcalls", so I set up 3 syscallLists, a) syscallList for common syscalls(1 syscall num, 1 syscall name), b) socketSubCallList for socket subcalls group.(indexed by first argument) c) ipcSubCallList for ipc subcalls group.(indexed by first argument) 3) In SyscallEventInfo.getSyscall(), get syscall number and first argument, and return the Syscall object in one of the three syscallLists. Any comments on this? Thanks! If I am on a right track, I will continue to do it. > > > The only oddity then would be what to do in the case where an unknown > > number is passed to syscallByNum. But ... I wonder if this should > > simply throw an exception. > > Not an exception. Sometimes new system calls are introduced. It should > just return a Syscall object for number xyz with as name "unknown-xyz" > so as to be unique. Emm, I think you are right, Mark. A RuntimeException is thrown out in my code, :) -- Yao Qi From mark@klomp.org Wed Sep 6 12:37:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 06 Sep 2006 12:37:00 -0000 Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures In-Reply-To: <20060906114401.GF13314@GreenHouse.cn.ibm.com> References: <20060904114640.GC13314@GreenHouse.cn.ibm.com> <1157377857.3629.16.camel@dijkstra.wildebeest.org> <1157535373.2996.21.camel@dijkstra.wildebeest.org> <20060906114401.GF13314@GreenHouse.cn.ibm.com> Message-ID: <1157546233.2996.35.camel@dijkstra.wildebeest.org> On Wed, 2006-09-06 at 19:44 +0800, Yao Qi wrote: > On Wed, Sep 06, 2006 at 11:36:12AM +0200, Mark Wielaard wrote: > > > > Do you mean the -e option? ( > > My version of ftrace has -o being redirect output to . > Do you mean strace here? :) > There is no option for frace now. Right, duh. sorry, confusion everywhere. > > > In the current setup one plausible approach would be to have multiple > > > Syscall objects with the same number but different names. Then, > > > SyscallEventInfo would have an accessor to return the corresponding > > > Syscall -- which would be the "decoded" one. Finally, Syscall would > > > have an equals() method that would compare both the name and the > > > number. > > > > Yes, that seems the right approach. > > syscalls with different names but the same number could only be found > on x86, and I could not find the similar case on other platforms. Yes. Seems this is just socketcall on x86. Strange. But I think we should handle these as if they are raw syscalls as on other architectures. > Actually, I start to rewrite Syscall.java, SyscallEventInfo.java and > Linux.java. I am not sure I am on a right way, so any advice is > appreciated. > > 1) Write a new method getSyscall() in SyscallEventInfo to return a > Syscall object from a *certain* syscallList. > > 2) Build syscallList in every Linux.java. > syscallList varies from ISA, so I place syscallList from Syscall.java > to Linux.java > On i386, there are 2 syscall numbers for a group of "subcalls", so I > set up 3 syscallLists, > > a) syscallList for common syscalls(1 syscall num, 1 syscall name), > b) socketSubCallList for socket subcalls group.(indexed by first > argument) > c) ipcSubCallList for ipc subcalls group.(indexed by first argument) > > 3) In SyscallEventInfo.getSyscall(), get syscall number and first > argument, and return the Syscall object in one of the three > syscallLists. Looks fine to me. The current Syscall list also contains an argument spec. Will you include something similar? It could be nice for the user of the Syscall to determine the number of arguments and the type of the return value. Cheers, Mark From mark@klomp.org Wed Sep 6 13:02:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 06 Sep 2006 13:02:00 -0000 Subject: Merging SyscallRunning and Running TaskStates Message-ID: <1157547743.2996.46.camel@dijkstra.wildebeest.org> Hi, This merges the Running and SyscallRunning task states. 2006-09-06 Mark Wielaard * TaskState.java (SyscallRunning): Removed, merged with Running. Tested on x86 and x86_64. Full testsuite passes. Next up is also merging runningInSyscall, transitionToSyscallRunning and transitionOutOfSyscallRunning. This will make the Running state bigger, but overall we are using less code. And having less states also means less chances to forget to handle any event (as we saw with the runningInSyscall previously). When this is done we should have the core handle breakpoint, signal and syscall tracing simultaneously. In general I hope to reduce the task state machine to just those states that a task has in the kernel plus some blocking and attaching administration states. But not have special/separate states depending on what is being traced at the moment. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: running-syscall-merge.patch Type: text/x-patch Size: 10570 bytes Desc: not available URL: From mcvet@redhat.com Wed Sep 6 14:18:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Wed, 06 Sep 2006 14:18:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <1157533819.2996.13.camel@dijkstra.wildebeest.org> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FE5749.90509@redhat.com> <1157533819.2996.13.camel@dijkstra.wildebeest.org> Message-ID: <1157552322.2031.8.camel@towel.toronto.redhat.com> On Wed, 2006-09-06 at 11:10 +0200, Mark Wielaard wrote: > On Wed, 2006-09-06 at 01:06 -0400, Andrew Cagney wrote: > > Unfortunatly having frysk use the ptrace calls found in > > libunwind-ptrace.a would be wrong. All ptrace calls to an attached > > process must be routed through a single thread and libunwind code won't > > be executed within that thread; and would immediatly limit frysk to > > native only. If you think the ptrace limitation is lame then argue it > > out with the kernel developers. > > We could make the PtraceThread more general so you can schedule any code > for execution on it, not just direct ptrace calls. Then you could wrap > any code that depends on ptrace calls into a Runnable and just put it on > the PtraceThread run queue. > > Cheers, > > Mark > Since the ptrace thread was essentially just a workaround for #2595 to address problems with ptrace, I'm not sure if it would be a good idea to have more dependencies on this thread if we can avoid it. Hopefully this thread will disappear altogether in the future via utrace. That being said, I'll take a working solution right now if it means work can get done immediately on stacktraces, as long as it'll get fixed up properly later. - Mike From mark@klomp.org Wed Sep 6 14:27:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 06 Sep 2006 14:27:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <1157552322.2031.8.camel@towel.toronto.redhat.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FE5749.90509@redhat.com> <1157533819.2996.13.camel@dijkstra.wildebeest.org> <1157552322.2031.8.camel@towel.toronto.redhat.com> Message-ID: <1157552805.2996.50.camel@dijkstra.wildebeest.org> Hi, On Wed, 2006-09-06 at 10:18 -0400, Mike Cvet wrote: > Since the ptrace thread was essentially just a workaround for #2595 to > address problems with ptrace, I'm not sure if it would be a good idea to > have more dependencies on this thread if we can avoid it. Hopefully this > thread will disappear altogether in the future via utrace. > > That being said, I'll take a working solution right now if it means work > can get done immediately on stacktraces, as long as it'll get fixed up > properly later. When do we expect to start depending on and using utrace? Is there any other solution except using the ptrace calls of libunwind to get remote stacktraces working for now? Cheers, Mark From ezannoni@redhat.com Wed Sep 6 14:29:00 2006 From: ezannoni@redhat.com (Elena Zannoni) Date: Wed, 06 Sep 2006 14:29:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <1157552805.2996.50.camel@dijkstra.wildebeest.org> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FE5749.90509@redhat.com> <1157533819.2996.13.camel@dijkstra.wildebeest.org> <1157552322.2031.8.camel@towel.toronto.redhat.com> <1157552805.2996.50.camel@dijkstra.wildebeest.org> Message-ID: <17662.55814.184895.938951@localhost.redhat.com> Mark Wielaard writes: > Hi, > > On Wed, 2006-09-06 at 10:18 -0400, Mike Cvet wrote: > > Since the ptrace thread was essentially just a workaround for #2595 to > > address problems with ptrace, I'm not sure if it would be a good idea to > > have more dependencies on this thread if we can avoid it. Hopefully this > > thread will disappear altogether in the future via utrace. > > > > That being said, I'll take a working solution right now if it means work > > can get done immediately on stacktraces, as long as it'll get fixed up > > properly later. > > When do we expect to start depending on and using utrace? Is there any > other solution except using the ptrace calls of libunwind to get remote > stacktraces working for now? Remember that we will have to keep frysk working on older kernels that have the old ptrace (RHEL4, fc5), and so we will not delete that hack any time soon. From mark@klomp.org Wed Sep 6 15:03:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 06 Sep 2006 15:03:00 -0000 Subject: getLogger parameter In-Reply-To: <44E36E7D.60000@redhat.com> References: <44E36E7D.60000@redhat.com> Message-ID: <1157554992.2996.54.camel@dijkstra.wildebeest.org> Hi Andrew, On Wed, 2006-08-16 at 15:14 -0400, Andrew Cagney wrote: > I've changed all the calls to getLogger() so that they specify the > current package (e.g., frysk.event, frysk.proc, frysk.gui.monitor), and > not frysk .Config .FRYSK_LOG_ID. My understanding of the logging code > is that's the general intent as it makes possible fine-grained logging > such as just frysk.event, et.al. Can you explain this a little more? I am trying to get log output for the loggers in Task and TaskState with TestRunner. These used to show up with ./TestRunner -c FINE or ./TestRunner -c FINEST, but now these only give output for Wait and EventLoop, but not for anything else it seems. Is there some new magic incantation to get the log output for other classes? Thanks, Mark From tromey@redhat.com Wed Sep 6 16:10:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Wed, 06 Sep 2006 16:10:00 -0000 Subject: [rfc] Remove SyscallNum.shjava and maintain syscallList manually for different architectures In-Reply-To: <1157535373.2996.21.camel@dijkstra.wildebeest.org> References: <20060904114640.GC13314@GreenHouse.cn.ibm.com> <1157377857.3629.16.camel@dijkstra.wildebeest.org> <1157535373.2996.21.camel@dijkstra.wildebeest.org> Message-ID: >>>>> "Mark" == Mark Wielaard writes: Mark> Do you mean the -e option? ( Yeah. Sorry. Mark> Not an exception. Sometimes new system calls are introduced. It should Mark> just return a Syscall object for number xyz with as name "unknown-xyz" Mark> so as to be unique. I suppose if the syscall is unknown, there would be no way to decode sub-calls. So... yeah. Tom From tromey@redhat.com Thu Sep 7 01:29:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Thu, 07 Sep 2006 01:29:00 -0000 Subject: Patch: various Syscall changes Message-ID: This patch makes a few changes to Syscall: * Updates javadoc of syscallByNum * Fixed typo in syscallByNum * Changes syscallByNum to cache requested unknown syscalls, so that each Syscall object is unique * Adds equals() method. We don't really need this but it is a convenient place to add a comment * Adds syscallByName. This is needed for 'ftrace -e' (or "--trace" as I spell it in my impl...) Tom Index: ChangeLog from Tom Tromey * Syscall.java (syscallByNum): Updated javadoc. Fixed typo. Cache unknown syscalls. (unknownSyscalls): New field. (equals): New method. (syscallByName): Likewise. Index: Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Syscall.java,v retrieving revision 1.11 diff -u -r1.11 Syscall.java --- Syscall.java 24 Aug 2006 03:13:05 -0000 1.11 +++ Syscall.java 7 Sep 2006 01:29:16 -0000 @@ -38,6 +38,7 @@ // exception. package frysk.proc; +import java.util.HashMap; import inua.util.PrintWriter; /** @@ -53,6 +54,10 @@ String argList; boolean noreturn; + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + Syscall (String name, int number, int numArgs, String argList, boolean noreturn) { @@ -62,6 +67,7 @@ this.argList = argList; this.noreturn = noreturn; } + Syscall (String name, int number, int numArgs, String argList) { this.name = name; @@ -97,6 +103,13 @@ return number; } + /** Return true if this object equals the argument. */ + public boolean equals(Object other) + { + // Syscall objects are unique. + return this == other; + } + private void printStringArg (PrintWriter writer, frysk.proc.Task task, long addr) @@ -215,17 +228,48 @@ /** * Given a system call's number, this will return the corresponding * Syscall object. Note that system call numbers are platform - * dependent. + * dependent. This will return a Syscall object in all cases; if + * there is no predefined system call with the given number, a unique + * "unknown" system call with the indicated number will be + * returned. * XXX: Eventually this will be moved down to Linux, or even * further. * @param num the number of the system call + * @return the Syscall object */ public static Syscall syscallByNum (int num) { - if(num >= syscallList.length || num < 0){ - return new Syscall("UKNOWN SYSCALL", num); - } - return syscallList[num]; + if (num >= 0 && num < syscallList.length) + return syscallList[num]; + synchronized (Syscall.class) + { + Integer key = new Integer(num); + if (unknownSyscalls == null) + unknownSyscalls = new HashMap(); + else if (unknownSyscalls.containsKey(key)) + return (Syscall) unknownSyscalls.get(key); + Syscall result = new Syscall("UNKNOWN SYSCALL", num); + unknownSyscalls.put(key, result); + return result; + } + } + + /** + * Given a system call's name, this will return the corresponding + * Syscall object. If no predefined system call with that name + * is available, this will return null. + * XXX: Eventually this will be moved down to Linux, or even + * further. + * @param name the name of the system call + * @return the Syscall object, or null + * @throws NullPointerException if name is null + */ + public static Syscall syscallByName (String name) + { + for (int i = 0; i < syscallList.length; ++i) + if (name.equals(syscallList[i].name)) + return syscallList[i]; + return null; } private static Syscall[] syscallList = { From qiyaoltc@cn.ibm.com Thu Sep 7 06:40:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 07 Sep 2006 06:40:00 -0000 Subject: Patch: various Syscall changes In-Reply-To: References: Message-ID: <20060907063929.GG13314@GreenHouse.cn.ibm.com> On Wed, Sep 06, 2006 at 07:23:39PM -0600, Tom Tromey wrote: > This patch makes a few changes to Syscall: > Hi, Tom, This patch is fine to me except syscallByName(), :) and I have some comments, and questions. > * Updates javadoc of syscallByNum > * Fixed typo in syscallByNum Thanks for updating these docs. > * Changes syscallByNum to cache requested unknown syscalls, so that > each Syscall object is unique Hmmm, the first thing in my mind is like this, :) I think you are right. if (num >= 0 && num < syscallList.length) return syscallList[num]; else if (num < 0) throw new RuntimeException ("Negative Syscall Number:" + Integer.toString(num)); else return new Syscall ("Unknown_SYS_" + Integer.toString(num), num); > * Adds equals() method. We don't really need this but it is a > convenient place to add a comment Yes, we do not really need this. IMO, the name of syscall is the ID of it. We could say they are the same syscalls only if their names are the same. All of them above are fine to me, and I would like to commit them with my changes in other part of Syscall. > * Adds syscallByName. This is needed for 'ftrace -e' (or "--trace" as > I spell it in my impl...) What do you want "--trace" to do in ftrace? Only trace a certain syscall? If I am right, when we use ftrace like "ftrace --trace read ls", we just want to see SYS_read called in "ls". I do not think syscallByName is necessary here. We could do something like this in ftrace.java, public Action updateSyscallEnter (Task task) { ...... frysk.proc.Syscall syscall = syscallEventInfo.getSyscall(task) // trace_opt is a String that get value from commandline. // trace_opt is "read" in this case. if (syscall.getName().equals(trace_opt)) { ... } } The only thing we could get, when enter/exit syscall, is syscall number, and then we could map this number to different syscalls(the same syscall number could map to different syscalls on different architecture), and then extract all the information of a syscall, such as arguments and return value. Most of the time, we just want to know, "what is the name of this syscall?" *only* when the program meets an syscall. That is to say, debugger is only interested in syscall information when program meets syscall. We will seldom want to know which syscall is named "read" when the program does not meet an syscall. Comments? If you do not use it in this way in ftrace, please tell me. I am refactoring Syscall and SyscallEventInfo for multi-arch syscallList, so how Syscall and SyscallEventInfo are used is important for me to design. Thanks! -- Yao Qi From mark@klomp.org Thu Sep 7 11:00:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 07 Sep 2006 11:00:00 -0000 Subject: New syscall/signal test Message-ID: <1157626790.5773.12.camel@dijkstra.wildebeest.org> Hi, I wrote this because I wanted to make sure I didn't introduce any regressions while rewriting some parts of TaskState. And now it actually caught a bug I was about to introduce that none of the existing tests would have caught. So I am adding it to CVS to make sure it is always run. 2006-09-07 Mark Wielaard * TestSyscallSignal.java: New file. 2006-09-07 Mark Wielaard * funit-syscall-signal.c: New test prog. It is just a simple mixing of syscall and signal tracing. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: TestSyscallSignal.java Type: text/x-java Size: 10138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: funit-syscall-signal.c Type: text/x-csrc Size: 2965 bytes Desc: not available URL: From tromey@redhat.com Thu Sep 7 14:56:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Thu, 07 Sep 2006 14:56:00 -0000 Subject: question about Proc.java Message-ID: I was digging through Proc.java last night and I found this: public String[] getCmdLine () { argv = sendrecCmdLine (); return argv; } protected abstract String[] sendrecCmdLine (); private String[] argv; I think something is weird here ... arg is not used anywhere else in Proc. It could just be deleted. There are a number of instances of this in this file. Were these intended to be caches? If not, why not simply dispense with the wrappers and have getCmdLine (et al) be abstract? Tom From tromey@redhat.com Thu Sep 7 15:25:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Thu, 07 Sep 2006 15:25:00 -0000 Subject: Patch: various Syscall changes In-Reply-To: <20060907063929.GG13314@GreenHouse.cn.ibm.com> References: <20060907063929.GG13314@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: Yao> if (num >= 0 && num < syscallList.length) Yao> return syscallList[num]; Yao> else if (num < 0) Yao> throw new RuntimeException ("Negative Syscall Number:" + Yao> Integer.toString(num)); Yeah, I considered this. I kept it the way it was because I did not know whether the code was intentionally written to allow negative syscall numbers. Yao> IMO, the name of syscall is the ID of it. We could say they are the Yao> same syscalls only if their names are the same. What I was going for here is having Syscall work more or less like an 'enum'. Of course we can't use enum. And Syscall has an unusual need: unrecognized syscalls can be created. Still, the idea is that each system call is represented by a single Syscall object. That's why I added the cache for unrecognized syscalls, and why equals was written the way it was. >> * Adds syscallByName. This is needed for 'ftrace -e' (or "--trace" as >> I spell it in my impl...) Yao> What do you want "--trace" to do in ftrace? Only trace a certain Yao> syscall? Yes. I'll send my updated ftrace shortly so you can see. Yao> I do not think syscallByName is necessary here. We could do something Yao> like this in ftrace.java, Yeah, it isn't strictly necessary. It just seemed like a reasonably clean way to implement this functionality, and it was the first thing that came to mind. Yao> We will seldom want to know which syscall is named "read" when Yao> the program does not meet an syscall. Comments? I've thought about this a bit more. syscallByName has the nice property that we can tell the user if he misspelled a syscalll name during option processing. I think that is enough reason to keep it. Tom From tromey@redhat.com Thu Sep 7 15:44:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Thu, 07 Sep 2006 15:44:00 -0000 Subject: ftrace Message-ID: I added command line parsing to ftrace recently. I'm attaching a new .java file. This uses GNU Classpath's option parsing code, since I like it better than jargs. It isn't in gcc 4.1, so perhaps it could be put into frysk-imports. If you want to try this, download: http://people.redhat.com/~tromey/gcjh/gcjh.jar This jar includes the getopt code. I moved Ftrace.java into a package. Putting classes in the default package just rubs me the wrong way ... too much java hacking I suppose. It isn't in the right package, I just made one up; anyway this is simple to change. Currently '-o' (output file), '-p' (trace PID), and '-t' (specify syscalls to trace) are supported. This code requires all my Syscall patches. I've been running it interpreted using fryski. I found a few oddities with deployment. Right now frysk statically links in the various frysk libraries. This seems weird. fryski is not installed. Installing it might be nice... but I think my ideal would be to have frysk more directly loadable by gij. This would enable things like loading frysk into jython (or really any java program). I'm not sure of the best way to do this now that we've changed the default of gnu.gcj.runtime.VMClassLoader.library_control. Perhaps having user programs do an explicit System.loadLibrary of some kind would be sufficient. One nice result of doing this is that it becomes very easy to hack on frysk-library-using programs in Eclipse: just import the jars, and launch gij with a -D to set library_control, and it all magically works. On a related note I think the .java files from each 'bindir' should be moved into real packages and simply put into the appropriate frysk .so. The distributed executables can be "source-less", ie linked like: gcj --main=full.class.Name -o frysk -lall-the-libraries I can file PRs for these things if people agree that this is the way to go. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: Ftrace.java Type: application/octet-stream Size: 9047 bytes Desc: Ftrace.java URL: From tromey@redhat.com Thu Sep 7 15:53:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Thu, 07 Sep 2006 15:53:00 -0000 Subject: 2 typo fixes Message-ID: This patch fixes a few typos I ran across. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: P Type: application/octet-stream Size: 1811 bytes Desc: typo patch URL: From kasal@ucw.cz Thu Sep 7 16:35:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Thu, 07 Sep 2006 16:35:00 -0000 Subject: Why does frysk have so many configure scripts? Message-ID: <20060907163456.GA26008@camelia.ucw.cz> Hello, frysk-core, frysg-gui, etc, are treated as autonomous sub-packages, each having its own configure.ac. Why is that? I can imagine several reasons: 1) There is (or will be) a need to build the individual parts separately. 2) The configure.ac might be too different. 3) historic reasons I will be grateful for any info. Thanks, Stepan Kasal From mark@klomp.org Thu Sep 7 20:10:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 07 Sep 2006 20:10:00 -0000 Subject: Merging all BlockedSignal substates Message-ID: <1157659825.5773.59.camel@dijkstra.wildebeest.org> Hi, This merges all BlockedSignal substates by pulling insyscall into the BlockedSignal constructor, this means that SyscallBlockedInSyscall and blockedInExecSyscall (which might need to be renamed, since it can now just be used when blocking in any syscall) are now just simple variants of BlockedSignal with different defaults. They don't have to override any event handlers. 2006-09-07 Mark Wielaard * TaskState.java: Merge BlockedSignal, SyscallBlockedInSyscall and blockedInExecSyscall. This will simplify the merging of the running and runninginsyscall states. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: merge-blockedsignal.patch Type: text/x-patch Size: 5033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cagney@redhat.com Thu Sep 7 20:18:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 07 Sep 2006 20:18:00 -0000 Subject: Why does frysk have so many configure scripts? In-Reply-To: <20060907163456.GA26008@camelia.ucw.cz> References: <20060907163456.GA26008@camelia.ucw.cz> Message-ID: <45007EB3.1080805@redhat.com> Stepan Kasal wrote: > Hello, > frysk-core, frysg-gui, etc, are treated as autonomous sub-packages, > each having its own configure.ac. Why is that? > To better compartmentalize the build: - frysk-gtk, and frysk-gui only have GTK dependencyes, hence frysk's core (frysk-core) can be built without gtk dependencies - frysk-core and frysk-gui have no native code (that's separated into sys, imports, and gtk) (ok in theory, I see there's been some bitrot :-)). Andrew > I can imagine several reasons: > 1) There is (or will be) a need to build the individual parts > separately. > 2) The configure.ac might be too different. > 3) historic reasons > > I will be grateful for any info. > > Thanks, > Stepan Kasal > From cagney@redhat.com Thu Sep 7 20:26:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 07 Sep 2006 20:26:00 -0000 Subject: ftrace In-Reply-To: References: Message-ID: <4500807A.8070706@redhat.com> Tom Tromey wrote: > I added command line parsing to ftrace recently. I'm attaching a new > .java file. > > This uses GNU Classpath's option parsing code, since I like it better > than jargs. It isn't in gcc 4.1, so perhaps it could be put into > frysk-imports. If you want to try this, download: > > http://people.redhat.com/~tromey/gcjh/gcjh.jar > > If you like it better than jargs, then I'm guessing it isn't the GNU getopt-long JNI wrapper based implementation. We picked up jargs because the JNI getopt-long interface was so horrendous. Is there javadoc online for this alternative? The main issues with adopting another getopt alternative are: that it be sane; that we only have one (we're not in the business of babysitting multiple redundant packages - which would mean eliminating jargs); and its license be workable. Andrew From cagney@redhat.com Thu Sep 7 20:33:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 07 Sep 2006 20:33:00 -0000 Subject: question about Proc.java In-Reply-To: References: Message-ID: <45008220.5010002@redhat.com> Tom Tromey wrote: > I was digging through Proc.java last night and I found this: > > public String[] getCmdLine () > { > argv = sendrecCmdLine (); > return argv; > } > protected abstract String[] sendrecCmdLine (); > private String[] argv; > > I think something is weird here ... arg is not used anywhere else in > Proc. It could just be deleted. > > cvs annotate is your friend :-) Looking at that, you're describing what the code was once like. I'm guessing that the caching was removed because it simplified the case of exec (and ensured that the test passed). Stan? > There are a number of instances of this in this file. Were these > intended to be caches? > > If not, why not simply dispense with the wrappers and have getCmdLine > (et al) be abstract? > All the methods messaging the target are named (well hopefully) send, and sendrec, I prefer this consistency. Eventually the getCmdLine will start caching again. Andrew From cagney@redhat.com Thu Sep 7 20:47:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 07 Sep 2006 20:47:00 -0000 Subject: getLogger parameter In-Reply-To: <1157554992.2996.54.camel@dijkstra.wildebeest.org> References: <44E36E7D.60000@redhat.com> <1157554992.2996.54.camel@dijkstra.wildebeest.org> Message-ID: <45008556.7080103@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Wed, 2006-08-16 at 15:14 -0400, Andrew Cagney wrote: > >> I've changed all the calls to getLogger() so that they specify the >> current package (e.g., frysk.event, frysk.proc, frysk.gui.monitor), and >> not frysk .Config .FRYSK_LOG_ID. My understanding of the logging code >> is that's the general intent as it makes possible fine-grained logging >> such as just frysk.event, et.al. >> > > Can you explain this a little more? I am trying to get log output for > the loggers in Task and TaskState with TestRunner. These used to show up > with ./TestRunner -c FINE or ./TestRunner -c FINEST, but now these only > give output for Wait and EventLoop, but not for anything else it seems. > Is there some new magic incantation to get the log output for other > classes? > > There shouldn't be a new magic incarnation. -c manipulates the top level "frysk" logger and that in turn should manipulate all "frysk.*" sub-loggers (unless I've misunderstood this). Andrew From tromey@redhat.com Thu Sep 7 22:05:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Thu, 07 Sep 2006 22:05:00 -0000 Subject: ftrace In-Reply-To: <4500807A.8070706@redhat.com> References: <4500807A.8070706@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Cagney writes: Andrew> If you like it better than jargs, then I'm guessing it isn't the GNU Andrew> getopt-long JNI wrapper based implementation. We picked up jargs Andrew> because the JNI getopt-long interface was so horrendous. Is there Andrew> javadoc online for this alternative? This is a new implementation I wrote for Classpath. I didn't see javadoc online... the source code is fully documented though. It is in the GNU Classpath cvs repository. Here's a URL for convenient browsing: http://cvs.savannah.gnu.org/viewcvs/classpath/tools/gnu/classpath/tools/getopt/?root=classpath This getopt isn't perfect (there's a couple smaller features I still want to add) but IMNSHO it is pretty good. It handles most argument parsing approaches (joined single-char options, like -Ipath, are on the to-do list), automatically handles --help and --version, and allows some user control over grouping of options in --help output. Andrew> The main issues with adopting another getopt alternative are: that it Andrew> be sane; that we only have one (we're not in the business of Andrew> babysitting multiple redundant packages - which would mean eliminating Andrew> jargs); and its license be workable. * Sane... well, I think so :-) * Eliminating jargs... at your discretion of course * License... GPL+E like the rest of Classpath Tom From mcvet@redhat.com Thu Sep 7 22:10:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Thu, 07 Sep 2006 22:10:00 -0000 Subject: Stacktraces in the SourceWindow Message-ID: <1157667020.2031.24.camel@towel.toronto.redhat.com> For your viewing enjoyment, here is a preliminary screenshot of the libunwind work thus far presented in the SourceWindow, using Alex's libunwind patches. Still a lot of bugs to iron out both in the unwinding and the Java stack manipulation (this isn't yet committed) but still a nice milestone! - Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: stack.jpg Type: image/jpeg Size: 32264 bytes Desc: not available URL: From pmuldoon@redhat.com Thu Sep 7 22:26:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Thu, 07 Sep 2006 22:26:00 -0000 Subject: Stacktraces in the SourceWindow In-Reply-To: <1157667020.2031.24.camel@towel.toronto.redhat.com> References: <1157667020.2031.24.camel@towel.toronto.redhat.com> Message-ID: <45009C81.5040404@redhat.com> Awesome! It looks good. Nice to see the bits coming together after a lot of hard work! This has me thinking of another use of the source-window -> monitor interactions If we could store the stack-trace saying during a syscall, we could print to the log window what function the thread was in when the syscall entered, as well as all the usual information. We could code up a GTK method to make the function click-able in the monitor log, and then it would open a source window showing the code context of where the syscall happened. If we stored the whole stacktrace for each log event in the ui, we could even show the user how it got to that point in the code. We 'd have to have a circular buffer though, and eventually stack traces would be discarded as memory demands dictate. Mike Cvet wrote: > For your viewing enjoyment, here is a preliminary screenshot of the > libunwind work thus far presented in the SourceWindow, using Alex's > libunwind patches. > > Still a lot of bugs to iron out both in the unwinding and the Java stack > manipulation (this isn't yet committed) but still a nice milestone! > > - Mike > > > ------------------------------------------------------------------------ > From tromey@redhat.com Fri Sep 8 00:28:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Fri, 08 Sep 2006 00:28:00 -0000 Subject: Patch: minor efficiency improvement in Host Message-ID: Andrew got me cvs write access but I'm not comfortable simply committing stuff yet. I'd prefer to get "ok"s for things more complicated than typo fixes. This patch makes a couple anonymous classes from 'Host' slight more efficient. The compiler will already generate fields in an anonymous class to capture 'final' variables from the method which are used in the anonymous class body. Having an explicit field is only needed if it will be modified in the anonymous class. Otherwise we're just duplicating things for no benefit. Tom Index: ChangeLog from Tom Tromey * Host.java (requestRefreshXXX): Remove extra field from anonymous class. (requestCreateAttachedProc): Likewise. Index: Host.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Host.java,v retrieving revision 1.40 diff -u -r1.40 Host.java --- Host.java 7 Sep 2006 23:59:05 -0000 1.40 +++ Host.java 8 Sep 2006 00:15:18 -0000 @@ -176,12 +176,11 @@ * refreshing the internal structure to match. Optionally refresh * each processes task list. */ - public void requestRefreshXXX (final boolean refreshAllArg) + public void requestRefreshXXX (final boolean refreshAll) { logger.log (Level.FINEST, "{0} requestRefreshXXX boolean\n", this); Manager.eventLoop.add (new HostEvent ("RequestRefresh") { - boolean refreshAll = refreshAllArg; public void execute () { newState= oldState ().handleRefresh (Host.this, refreshAll); @@ -191,24 +190,19 @@ /** * Request that a new attached and running process be created. */ - public final void requestCreateAttachedProc (final String stdinArg, - final String stdoutArg, - final String stderrArg, - final String[] argsArg, + public final void requestCreateAttachedProc (final String stdin, + final String stdout, + final String stderr, + final String[] args, final TaskObserver.Attached attachedObserver) { logger.log (Level.FINE, "{0} requestCreateAttachedProc\n", this); Manager.eventLoop.add (new HostEvent ("requestCreateAttachedProc") { - String stdin = stdinArg; - String stdout = stdoutArg; - String stderr = stderrArg; - String[] args = argsArg; - TaskObserver.Attached attached = attachedObserver; public void execute () { newState= oldState ().handleCreateAttachedProc - (Host.this, stdin, stdout, stderr, args, attached); + (Host.this, stdin, stdout, stderr, args, attachedObserver); } }); } From mark@klomp.org Fri Sep 8 10:46:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 08 Sep 2006 10:46:00 -0000 Subject: Merging Running and runningInSyscall TaskStates Message-ID: <1157712384.5773.95.camel@dijkstra.wildebeest.org> Hi, Another episode in the continuous merging of states story. This patch merges the Running and runningInSyscall TaskStates. It removes another 100+ lines of duplicate code which is good. 2006-09-08 Mark Wielaard * TaskState.java: Merge Running and runningInSyscall states. We are really almost done with this (hopefully end of the day at the latest). Then we can finally mix and match signal, syscall and breakpoint observers whenever we want. The reason I am posting this is small installments is because this is pretty central code and I want to make sure I don't break anything. I test on x86 and x86_64 each time (fc5 for now). And it should make it easier for people to spot silly mistakes or yell and scream if they think I am moving in the wrong direction. Next up are the transitionToSyscallRunning and transitionOutOfSyscallRunning states. Then we need to move the pending code observers into the Task so they can be easily shared by the TaskStates. And then we should be finally done. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: merge-running-insyscall.diff Type: text/x-patch Size: 9962 bytes Desc: not available URL: From mark@klomp.org Fri Sep 8 12:02:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 08 Sep 2006 12:02:00 -0000 Subject: getLogger parameter In-Reply-To: <45008556.7080103@redhat.com> References: <44E36E7D.60000@redhat.com> <1157554992.2996.54.camel@dijkstra.wildebeest.org> <45008556.7080103@redhat.com> Message-ID: <1157716937.5773.99.camel@dijkstra.wildebeest.org> Hi Andrew, On Thu, 2006-09-07 at 16:47 -0400, Andrew Cagney wrote: > > On Wed, 2006-08-16 at 15:14 -0400, Andrew Cagney wrote: > >> I've changed all the calls to getLogger() so that they specify the > >> current package (e.g., frysk.event, frysk.proc, frysk.gui.monitor), and > >> not frysk .Config .FRYSK_LOG_ID. My understanding of the logging code > >> is that's the general intent as it makes possible fine-grained logging > >> such as just frysk.event, et.al. > > > > Can you explain this a little more? I am trying to get log output for > > the loggers in Task and TaskState with TestRunner. These used to show up > > with ./TestRunner -c FINE or ./TestRunner -c FINEST, but now these only > > give output for Wait and EventLoop, but not for anything else it seems. > > Is there some new magic incantation to get the log output for other > > classes? > > > There shouldn't be a new magic incarnation. -c manipulates the top > level "frysk" logger and that in turn should manipulate all "frysk.*" > sub-loggers (unless I've misunderstood this). But how does it work? How do you get log output for say Task and TaskState when using TestRunner now? I reverted to using System.err.println() for now, but at times it would be nice to get the log output as before this change. Cheers, Mark From mark@klomp.org Fri Sep 8 12:21:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 08 Sep 2006 12:21:00 -0000 Subject: Stacktraces in the SourceWindow In-Reply-To: <45009C81.5040404@redhat.com> References: <1157667020.2031.24.camel@towel.toronto.redhat.com> <45009C81.5040404@redhat.com> Message-ID: <1157718042.5773.108.camel@dijkstra.wildebeest.org> On Thu, 2006-09-07 at 17:26 -0500, Phil Muldoon wrote: > Awesome! It looks good. Nice to see the bits coming together after a lot > of hard work! Yes, this is nice to see. > > > If we could store the stack-trace saying during a syscall, we could > print to the log window what function the thread was in when the syscall > entered, as well as all the usual information. We could code up a GTK > method to make the function click-able in the monitor log, and then it > would open a source window showing the code context of where the syscall > happened. If we stored the whole stacktrace for each log event in the > ui, we could even show the user how it got to that point in the code. We > 'd have to have a circular buffer though, and eventually stack traces > would be discarded as memory demands dictate. > > Nice. That does probably slow down programs we are tracing even more though. So it should probably not be on by default. You also need to think about libraries that might be loaded/unloaded dynamically. How would that interact with the stacktraces? It means that at a later time the original stacktrace might not be valid, or that it might not be possible to find the actual code back. Another bluesky idea. Seeing the stack trace addresses I thought it would be nice if anywhere in the gui where you have a code address you could simple add a CodeObserver by right-clicking, or some other mechanism to the current Task or the whole Process. That way you can quickly start with breakpointing in the gui and don't have to do any code/line/address conversions (yet). Cheers, Mark From mark@klomp.org Fri Sep 8 12:26:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 08 Sep 2006 12:26:00 -0000 Subject: Patch: minor efficiency improvement in Host In-Reply-To: References: Message-ID: <1157718379.5773.114.camel@dijkstra.wildebeest.org> Hi Tom, On Thu, 2006-09-07 at 18:22 -0600, Tom Tromey wrote: > Andrew got me cvs write access but I'm not comfortable simply > committing stuff yet. I'd prefer to get "ok"s for things more > complicated than typo fixes. Welcome to the club! :) > This patch makes a couple anonymous classes from 'Host' slight more > efficient. The compiler will already generate fields in an anonymous > class to capture 'final' variables from the method which are used in > the anonymous class body. > > Having an explicit field is only needed if it will be modified in the > anonymous class. Otherwise we're just duplicating things for no benefit. This looks fine to me. Please do run a quick make check before checking anything in though. Even if you think a change is completely harmless. It is a nice feeling to see all tests PASS. And if they don't all PASS please do let us know (there are unfortunately some issues still on FC6). Cheers, Mark From ezannoni@gmail.com Fri Sep 8 12:31:00 2006 From: ezannoni@gmail.com (Elena Zannoni) Date: Fri, 08 Sep 2006 12:31:00 -0000 Subject: Stacktraces in the SourceWindow In-Reply-To: <1157667020.2031.24.camel@towel.toronto.redhat.com> References: <1157667020.2031.24.camel@towel.toronto.redhat.com> Message-ID: <45016152.4000806@gmail.com> Mike Cvet wrote: > For your viewing enjoyment, here is a preliminary screenshot of the > libunwind work thus far presented in the SourceWindow, using Alex's > libunwind patches. > > Still a lot of bugs to iron out both in the unwinding and the Java stack > manipulation (this isn't yet committed) but still a nice milestone! > > - Mike > Very nice. What is the line #0? I assume this is one of the bugs you mentioned :-) elena From qiyaoltc@cn.ibm.com Fri Sep 8 12:55:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 08 Sep 2006 12:55:00 -0000 Subject: [patch review] Syscall for multi-arch support Message-ID: <20060908125442.GA1364@GreenHouse.cn.ibm.com> Some items are listed here to present what I did, 1. Move syscallList from Syscall.java to Linux.java. syscallList is relative to OS+ISA, so I put this array in Linux.java . However, I do not change the spec in syscallList. It would take me a whole day to look up system call numbers for different architectures. :) 2. New methods to Syscall. Tom submitted a patch about part of this, and I integrate his patch in my changes. Add equals() in Syscall. 3. New methods in SyscallEventInfo. a) getSyscall (Task task) return a Syscall object when a syscall happens. b) getSyscallList() and getUnknownSyscalls() return the architecture-dependent syscallList and unknown syscall hash map from Linux.java c) syscallByNum() and syscallByName() are also from Tom's patch. 4. Setup three syscallList for Ia32 to index syscall object by syscall number and first argument directly. I discussed this with Mark here, http://sources.redhat.com/ml/frysk/2006-q3/msg00409.html One syscallList is for common syscalls.(indexed by syscall number) One syscalLList is for socket "subcall".(indexed by first argument) One syscallList is for ipc "subcall".(indexed by first argument) This patch could setup a framework for multi-arch syscall list, and now ftrace could recognize syscall "bind" or "send" as a standard system call, but there are something we could go on if this patch is on a right track. 1) Code syscallList spec for every architecture except Ia32. I did not code syscall spec for ipc "subcalls". 2) fill in argument for these "subcalls" on ia32. On ia32, these "subcalls" share the same system call number, but with different name, and these "subcalls" could be distinguished by %ebx, and their arguments are in memory addressed by %ecx. In my patch, I just let it return 0 now, so the output from ftrace is 0 or NULL. Any comments are welcome! Here is an output from ftrace on x86, (I input Ctrl-C to kill accept) [qiyao@GreenHouse frysk-core]$ ./frysk/bindir/ftrace frysk/pkglibexecdir/funit-syscall-running ftrace.main() Proc.getPid() 1601 ftrace.main() Proc.getPid() /home/qiyao/source/cvs/build-frysk/frysk-core/frysk/pkglibexecdir/funit-syscall-running 1601.1601 brk (NULL) = 142249984 1601.1601 mmap (NULL,4096,3,34,-1,-38) = 0xb7fa1000 1601.1601 access ("/etc/ld.so.preload",4) = -1 ERRNO=2 1601.1601 open ("/etc/ld.so.cache",0,0) = 3 1601.1601 fstat64 (3,0xbfe1648c) = 0 1601.1601 mmap (NULL,67623,1,2,3,-38) = 0xb7f90000 1601.1601 close (3) = 0 1601.1601 open ("/lib/libc.so.6",0,699) = 3 1601.1601 read (3,0xbfe165dc,512) = 512 1601.1601 fstat64 (3,0xbfe164ec) = 0 1601.1601 mmap (0x743000,1295780,5,2050,3,-38) = 0x743000 1601.1601 mmap (0x87a000,12288,3,2066,3,-38) = 0x87a000 1601.1601 mmap (0x87d000,9636,3,50,-1,-38) = 0x87d000 1601.1601 close (3) = 0 1601.1601 mmap (NULL,4096,3,34,-1,-38) = 0xb7f8f000 1601.1601 set_thread_area (0xbfe169d0) = 0 1601.1601 mprotect (0x87a000,8192,1) = 0 1601.1601 mprotect (0x73f000,4096,1) = 0 1601.1601 munmap (0xb7f90000,67623) = 0 1601.1601 socket (0,0,0) = 3 1601.1601 bind (0,NULL,0) = 0 1601.1601 getsockname (0,NULL,NULL) = 0 1601.1601 listen (0,0) = 0 1601.1601 fstat64 (1,0xbfe16644) = 0 1601.1601 mmap (NULL,4096,3,34,-1,-38) = 0xb7fa0000 1601.1601 write (1,0xb7fa0000,6)48815 = 6 1601.1601 accept (0,NULL,NULL) -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/bindir/ftrace.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/bindir/ftrace.java,v retrieving revision 1.18 diff -u -r1.18 ftrace.java --- frysk-core/frysk/bindir/ftrace.java 7 Aug 2006 20:22:15 -0000 1.18 +++ frysk-core/frysk/bindir/ftrace.java 8 Sep 2006 10:55:49 -0000 @@ -144,7 +144,9 @@ System.out.println("Got task exception " + e); return Action.CONTINUE; } - frysk.proc.Syscall syscall = frysk.proc.Syscall.syscallByNum(syscallEventInfo.number(task)); + + frysk.proc.Syscall syscall = syscallEventInfo.getSyscall(task); + PrintWriter printWriter = new PrintWriter(System.out); printWriter.print(task.getProc().getPid() + "." + task.getTid() + " "); syscall.printCall(printWriter, task, syscallEventInfo); @@ -165,7 +167,8 @@ System.out.println("Got task exception " + e); return Action.CONTINUE; } - frysk.proc.Syscall syscall = frysk.proc.Syscall.syscallByNum(syscallEventInfo.number(task)); + frysk.proc.Syscall syscall = syscallEventInfo.getSyscall(task); + PrintWriter printWriter = new PrintWriter(System.out); syscall.printReturn(printWriter, task, syscallEventInfo); printWriter.flush(); Index: frysk-core/frysk/proc/Isa.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Isa.java,v retrieving revision 1.11 diff -u -r1.11 Isa.java --- frysk-core/frysk/proc/Isa.java 23 Aug 2006 04:04:19 -0000 1.11 +++ frysk-core/frysk/proc/Isa.java 8 Sep 2006 10:55:50 -0000 @@ -49,6 +49,9 @@ public interface Isa { + + String toString(); + Iterator RegisterIterator(); Register getRegisterByName(String name); Index: frysk-core/frysk/proc/IsaEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaEMT64.java,v retrieving revision 1.4 diff -u -r1.4 IsaEMT64.java --- frysk-core/frysk/proc/IsaEMT64.java 29 Aug 2006 05:35:43 -0000 1.4 +++ frysk-core/frysk/proc/IsaEMT64.java 8 Sep 2006 10:55:50 -0000 @@ -117,6 +117,10 @@ return (Register)registerMap.get(name); } + public String toString () + { + return "x86-64"; + } public long pc(Task task) { return getRegisterByName("rip").get(task); Index: frysk-core/frysk/proc/IsaIA32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v retrieving revision 1.4 diff -u -r1.4 IsaIA32.java --- frysk-core/frysk/proc/IsaIA32.java 29 Aug 2006 05:35:43 -0000 1.4 +++ frysk-core/frysk/proc/IsaIA32.java 8 Sep 2006 10:55:50 -0000 @@ -124,6 +124,10 @@ return (Register)registerMap.get(name); } + public String toString() + { + return "ia32"; + } public long pc(Task task) { return getRegisterByName("eip").get(task); Index: frysk-core/frysk/proc/IsaPPC.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC.java,v retrieving revision 1.2 diff -u -r1.2 IsaPPC.java --- frysk-core/frysk/proc/IsaPPC.java 23 Aug 2006 04:04:19 -0000 1.2 +++ frysk-core/frysk/proc/IsaPPC.java 8 Sep 2006 10:55:50 -0000 @@ -82,6 +82,11 @@ return getRegisterByName("nip").get(task); } + public String toString() + { + return "ppc"; + } + public int getWordSize () { return 4; Index: frysk-core/frysk/proc/IsaPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC64.java,v retrieving revision 1.5 diff -u -r1.5 IsaPPC64.java --- frysk-core/frysk/proc/IsaPPC64.java 29 Aug 2006 05:35:43 -0000 1.5 +++ frysk-core/frysk/proc/IsaPPC64.java 8 Sep 2006 10:55:50 -0000 @@ -99,6 +99,11 @@ return getRegisterByName("nip").get(task); } + public String toString () + { + return "ppc64"; + } + public int getWordSize () { return 8; Index: frysk-core/frysk/proc/LinuxEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxEMT64.java,v retrieving revision 1.2 diff -u -r1.2 LinuxEMT64.java --- frysk-core/frysk/proc/LinuxEMT64.java 11 Jul 2006 21:25:25 -0000 1.2 +++ frysk-core/frysk/proc/LinuxEMT64.java 8 Sep 2006 10:55:50 -0000 @@ -39,6 +39,8 @@ package frysk.proc; +import java.util.HashMap; + class LinuxEMT64 extends IsaEMT64 implements SyscallEventDecoder { @@ -50,6 +52,10 @@ return isa; } + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + private SyscallEventInfo info; public SyscallEventInfo getSyscallEventInfo () { @@ -85,7 +91,285 @@ throw new RuntimeException ("unknown syscall arg"); } } + }; return info; } + + /** FIXME: This syscallList is i386 specific. */ + static Syscall[] syscallList = { + new Syscall (0), + new Syscall ("exit", 1, 1), + new Syscall ("fork", 2, 0, "i: "), + new Syscall ("read", 3, 3, "i:ibn "), + new Syscall ("write", 4, 3, "i:ibn "), + new Syscall ("open", 5, 3, "i:siv "), + new Syscall ("close", 6, 1, "i:i "), + new Syscall ("waitpid", 7, 3, "i:ipi "), + new Syscall ("creat", 8, 2, "i:sv"), + new Syscall ("link", 9, 2, "i:ss "), + new Syscall ("unlink", 10, 1, "i:s "), + new Syscall ("execve", 11, 3, "i:ppp "), + new Syscall ("chdir", 12, 1, "i:s "), + new Syscall ("time", 13, 1, "i:P "), + new Syscall ("sys_mknod", 14, 3, "i:sii "), + new Syscall ("chmod", 15, 2, "i:si "), + new Syscall ("lchown", 16, 3, "i:sii "), + new Syscall ("break", 17), + new Syscall ("old_stat", 18, 3, "i:pp "), + new Syscall ("lseek", 19, 3, "i:iii "), + new Syscall ("getpid", 20, 0, "i: "), + new Syscall ("mount", 21, 5, "i:sssip "), + new Syscall ("umount", 22, 1, "i:s "), + new Syscall ("setuid", 23, 1, "i:i "), + new Syscall ("getuid", 24, 0, "i: "), + new Syscall ("stime", 25, 1, "i:p "), + new Syscall ("ptrace", 26, 4, "i:iiii "), + new Syscall ("alarm", 27, 1, "i:i "), + new Syscall ("old_fstat", 28, 2, "i:ip "), + new Syscall ("pause", 29, 0, "i: "), + new Syscall ("utime", 30, 2, "i:sP "), + new Syscall ("stty", 31), + new Syscall ("gtty", 32), + new Syscall ("access", 33, 2, "i:si "), + new Syscall ("nice", 34, 1, "i:i "), + new Syscall ("ftime", 35, 1, "i:p "), + new Syscall ("sync", 36, 0, "i: "), + new Syscall ("kill", 37, 2, "i:ii "), + new Syscall ("rename", 38, 2, "i:ss "), + new Syscall ("mkdir", 39, 2, "i:si "), + new Syscall ("rmdir", 40, 1, "i:s "), + new Syscall ("dup", 41, 1, "i:i "), + new Syscall ("pipe", 42, 1, "i:f "), + new Syscall ("times", 43, 1, "i:p "), + new Syscall ("prof", 44), + new Syscall ("brk", 45, 1, "i:p "), + new Syscall ("setgid", 46, 1, "i:i "), + new Syscall ("getgid", 47, 0, "i: "), + new Syscall ("signal", 48, 2, "i:ii "), + new Syscall ("geteuid", 49, 0, "i: "), + new Syscall ("getegid", 50, 0, "i: "), + new Syscall ("acct", 51, 1, "i:S "), + new Syscall ("umount2", 52, 2, "i:si "), + new Syscall ("lock", 53), + new Syscall ("ioctl", 54, 3, "i:iiI "), + new Syscall ("fcntl", 55, 3, "i:iiF "), + new Syscall ("mpx", 56), + new Syscall ("setpgid", 57, 2, "i:ii "), + new Syscall ("ulimit", 58, 2, "i:ii "), + new Syscall ("oldolduname", 59), + new Syscall ("umask", 60, 1, "i:i "), + new Syscall ("chroot", 61, 1, "i:s "), + new Syscall ("ustat", 62, 2, "i:ip "), + new Syscall ("dup2", 63, 2, "i:ii "), + new Syscall ("getppid", 64, 0, "i: "), + new Syscall ("getpgrp", 65, 0, "i: "), + new Syscall ("setsid", 66, 0, "i: "), + new Syscall ("sigaction", 67, 3, "i:ipp "), + new Syscall ("sgetmask", 68), + new Syscall ("ssetmask", 69), + new Syscall ("setreuid", 70, 2, "i:ii "), + new Syscall ("setregid", 71, 2, "i:ii "), + new Syscall ("sigsuspend", 72, 1, "i:p "), + new Syscall ("sigpending", 73, 1, "i:p "), + new Syscall ("sethostname", 74, 2, "i:pi "), + new Syscall ("setrlimit", 75, 2, "i:ip "), + new Syscall ("getrlimit", 76, 2, "i:ip "), + new Syscall ("getrusage", 77, 2, "i:ip "), + new Syscall ("gettimeofday", 78, 2, "i:PP "), + new Syscall ("settimeofday", 79, 2, "i:PP "), + new Syscall ("getgroups", 80, 2, "i:ip "), + new Syscall ("setgroups", 81, 2, "i:ip "), + new Syscall ("select", 82, 5, "i:iPPPP "), + new Syscall ("symlink", 83, 2, "i:ss "), + new Syscall ("oldlstat", 84, 2, "i:pp "), + new Syscall ("readlink", 85, 3, "i:spi "), + new Syscall ("uselib", 86, 1, "i:s "), + new Syscall ("swapon", 87, 2, "i:si "), + new Syscall ("reboot", 88, 1, "i:i "), + new Syscall (89), + new Syscall ("mmap", 90, 6, "b:aniiii "), + new Syscall ("munmap", 91, 2, "i:ai "), + new Syscall ("truncate", 92, 2, "i:si "), + new Syscall ("ftruncate", 93, 2, "i:ii "), + new Syscall ("fchmod", 94, 2, "i:ii "), + new Syscall ("fchown", 95, 3, "i:iii "), + new Syscall ("getpriority", 96, 2, "i:ii "), + new Syscall ("setpriority", 97, 3, "i:iii "), + new Syscall ("profil", 98, 4, "i:piii "), + new Syscall ("statfs", 99, 2, "i:sp "), + new Syscall ("fstatfs", 100, 2, "i:ip "), + new Syscall ("ioperm", 101, 3, "i:iii "), + new Syscall ("socketcall", 102, 2, "i:ip "), + new Syscall ("klogctl", 103, 3, "i:isi "), + new Syscall ("setitimer", 104, 3, "i:ipp "), + new Syscall ("getitimer", 105, 2, "i:ip "), + new Syscall ("sys_stat", 106, 2, "i:sp "), + new Syscall ("sys_lstat", 107, 2, "i:sp "), + new Syscall ("sys_fstat", 108, 2, "i:ip "), + new Syscall ("old_uname", 109, 1, "i:p "), + new Syscall ("iopl", 110, 1, "i:i "), + new Syscall ("vhangup", 111, 1, "i:i "), + new Syscall ("idle", 112, 0, "i: "), + new Syscall (113), + new Syscall ("wait4", 114, 4, "i:iWiP "), + new Syscall ("swapoff", 115, 1, "i:s "), + new Syscall ("sysinfo", 116, 1, "i:p "), + new Syscall ("ipc", 117, 6, "i:iiiipi "), + new Syscall ("fsync", 118, 1, "i:i "), + new Syscall ("sigreturn", 119), + new Syscall ("clone", 120, 2, "i:ip "), + new Syscall ("setdomain", 121, 2, "i:si "), + new Syscall ("uname", 122, 1, "i:p "), + new Syscall ("modify_ldt", 123, 3, "i:ipi "), + new Syscall ("adjtimex", 124, 1, "i:p "), + new Syscall ("mprotect", 125, 3, "i:aii "), + new Syscall ("sigprocmask", 126, 3, "i:ipp "), + new Syscall ("create_module", 127, 3), + new Syscall ("init_module", 128, 5), + new Syscall ("delete_module", 129, 3), + new Syscall ("get_kernel_syms", 130, 1, "i:p "), + new Syscall ("quotactl", 131, 4, "i:isip "), + new Syscall ("getpgid", 132, 1, "i:i "), + new Syscall ("fchdir", 133, 1, "i:i "), + new Syscall ("bdflush", 134, 2, "i:ii "), + new Syscall ("sysfs", 135, 1, "i:i "), + new Syscall ("personality", 136, 1, "i:i "), + new Syscall ("afs_syscall", 137), + new Syscall ("setfsuid", 138, 1, "i:i "), + new Syscall ("setfsgid", 139, 1, "i:i "), + new Syscall ("llseek", 140, 5, "i:iuupi "), + new Syscall ("s_getdents", 141, 3, "i:ipi "), + new Syscall ("select", 142, 5, "i:iPPPP "), + new Syscall ("flock", 143, 2, "i:ii "), + new Syscall ("msync", 144, 3, "i:aii "), + new Syscall ("readv", 145, 3, "i:ipi "), + new Syscall ("writev", 146, 3, "i:ipi "), + new Syscall ("getsid", 147, 1, "i:i "), + new Syscall ("fdatasync", 148, 1, "i:i "), + new Syscall ("sysctl", 149, 1, "i:p "), + new Syscall ("mlock", 150, 2, "i:bn "), + new Syscall ("munlock", 151, 2, "i:ai "), + new Syscall ("mlockall", 152, 1, "i:i "), + new Syscall ("munlockall", 153, 0, "i: "), + new Syscall ("sched_setp", 154, 2, "i:ip "), + new Syscall ("sched_getp", 155, 2, "i:ip "), + new Syscall ("sched_sets", 156, 3, "i:iip "), + new Syscall ("sched_gets", 157, 1, "i:i "), + new Syscall ("sched_yield", 158, 0, "i: "), + new Syscall ("sched_primax", 159, 1, "i:i "), + new Syscall ("sched_primin", 160, 1, "i:i "), + new Syscall ("sched_rr_gi", 161, 2, "i:ip "), + new Syscall ("nanosleep", 162, 2, "i:pp "), + new Syscall ("mremap", 163, 4, "b:aini "), + new Syscall ("setresuid", 164, 3, "i:iii "), + new Syscall ("getresuid", 165, 3, "i:ppp "), + new Syscall ("vm86", 166, 1, "i:p "), + new Syscall ("query_module", 167, 5, "i:sipip "), + new Syscall ("poll", 168, 3, "i:pii "), + new Syscall ("nfsservctl", 169, 3, "i:ipp "), + new Syscall ("setresgid", 170, 3, "i:iii "), + new Syscall ("getresgid", 171, 3, "i:ppp "), + new Syscall ("prctl", 172, 5, "i:iiiii "), + new Syscall ("rt_sigreturn", 173), + new Syscall ("rt_sigaction", 174), + new Syscall ("rt_sigprocmask", 175), + new Syscall ("rt_sigpending", 176), + new Syscall ("rt_sigtimedwait", 177), + new Syscall ("rt_sigqueueinfo", 178), + new Syscall ("rt_sigsuspend", 179), + new Syscall ("pread64", 180), + new Syscall ("pwrite64", 181), + new Syscall ("chown", 182, 3, "i:sii "), + new Syscall ("getcwd", 183, 2, "i:bi "), + new Syscall ("capget", 184, 2, "i:pp "), + new Syscall ("capset", 185, 2, "i:pp "), + new Syscall ("sigaltstack", 186, 2, "i:PP "), + new Syscall ("sendfile", 187, 4, "i:iipi "), + new Syscall ("getpmsg", 188), + new Syscall ("putpmsg", 189), + new Syscall ("vfork", 190, 0, "i: "), + new Syscall ("ugetrlimit", 191), + new Syscall ("mmap", 192, 6, "b:aniiii "), + new Syscall ("truncate64", 193, 3, "i:shl "), + new Syscall ("ftruncate64", 194, 3, "i:ihl "), + new Syscall ("stat64", 195, 2, "i:sp "), + new Syscall ("lstat64", 196, 2, "i:sp "), + new Syscall ("fstat64", 197, 2, "i:ip "), + new Syscall ("lchown32", 198, 3, "i:sii "), + new Syscall ("getuid32", 199), + new Syscall ("getgid32", 200), + new Syscall ("geteuid32", 201), + new Syscall ("getegid32", 202), + new Syscall ("setreuid32", 203, 2, "i:ii "), + new Syscall ("setregid32", 204, 2, "i:ii "), + new Syscall ("getgroups32", 205, 2, "i:ip "), + new Syscall ("setgroups32", 206, 2, "i:ip "), + new Syscall ("fchown32", 207, 3, "i:iii "), + new Syscall ("setresuid32", 208, 3, "i:iii "), + new Syscall ("getresuid32", 209, 3, "i:ppp "), + new Syscall ("setresgid32", 210, 3, "i:iii "), + new Syscall ("getresgid32", 211, 3, "i:ppp "), + new Syscall ("chown32", 212, 3, "i:sii "), + new Syscall ("setuid32", 213, 1, "i:i "), + new Syscall ("setgid32", 214, 1, "i:i "), + new Syscall ("setfsuid32", 215, 1, "i:i "), + new Syscall ("setfsgid32", 216, 1, "i:i "), + new Syscall ("pivot_root", 217, 2, "i:ss "), + new Syscall ("mincore", 218, 3, "i:anV "), + new Syscall ("madvise", 219, 3, "i:pii "), + new Syscall ("getdents64", 220, 3, "i:ipi "), + new Syscall ("fcntl64", 221, 3, "i:iip "), + new Syscall (222), + new Syscall (223), + new Syscall ("gettid", 224, 0), + new Syscall ("readahead", 225, 4, "i:ihli "), + new Syscall ("setxattr", 226), + new Syscall ("lsetxattr", 227), + new Syscall ("fsetxattr", 228), + new Syscall ("getxattr", 229), + new Syscall ("lgetxattr", 230), + new Syscall ("fgetxattr", 231), + new Syscall ("listxattr", 232), + new Syscall ("llistxattr", 233), + new Syscall ("flistxattr", 234), + new Syscall ("removexattr", 235), + new Syscall ("lremovexattr", 236), + new Syscall ("fremovexattr", 237), + new Syscall ("tkill", 238, 2, "i:ii "), + new Syscall ("sendfile64", 239, 4, "i:iipi "), + new Syscall ("futex", 240, 4, "i:piip "), + new Syscall ("sched_setaffinity", 241), + new Syscall ("sched_getaffinity", 242), + new Syscall ("set_thread_area", 243, 1, "i:p "), + new Syscall ("get_thread_area", 244, 1, "i:p "), + new Syscall ("io_setup", 245, 2, "i:ip "), + new Syscall ("io_destroy", 246, 1, "i:i "), + new Syscall ("io_getevents", 247, 5, "i:iiipp "), + new Syscall ("io_submit", 248, 3, "i:iip "), + new Syscall ("io_cancel", 249, 3, "i:ipp "), + new Syscall ("fadvise64", 250), + new Syscall (251), + new Syscall ("exit_group", 252, 1, " :i ", true), + new Syscall ("lookup_dcookie", 253), + new Syscall ("epoll_create", 254), + new Syscall ("epoll_ctl", 255), + new Syscall ("epoll_wait", 256), + new Syscall ("remap_file_pages", 257), + new Syscall ("set_tid_address", 258), + new Syscall ("timer_create", 259), + new Syscall ("timer_settime", 260), + new Syscall ("timer_gettime", 261), + new Syscall ("timer_getoverrun", 262), + new Syscall ("timer_delete", 263), + new Syscall ("clock_settime", 264), + new Syscall ("clock_gettime", 265), + new Syscall ("clock_getres", 266), + new Syscall ("clock_nanosleep", 267), + new Syscall ("statfs64", 268), + new Syscall ("fstatfs64", 269), + new Syscall ("tgkill", 270), + new Syscall ("utimes", 271), + new Syscall ("fadvise64_64", 272), + }; } Index: frysk-core/frysk/proc/LinuxIa32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxIa32.java,v retrieving revision 1.8 diff -u -r1.8 LinuxIa32.java --- frysk-core/frysk/proc/LinuxIa32.java 11 Jul 2006 21:25:25 -0000 1.8 +++ frysk-core/frysk/proc/LinuxIa32.java 8 Sep 2006 10:55:50 -0000 @@ -39,53 +39,435 @@ package frysk.proc; +import java.util.HashMap; + class LinuxIa32 - extends IsaIA32 implements SyscallEventDecoder + extends IsaIA32 implements SyscallEventDecoder { - private static LinuxIa32 isa; - static LinuxIa32 isaSingleton () + private static LinuxIa32 isa; + static LinuxIa32 isaSingleton () + { + if (isa == null) + isa = new LinuxIa32 (); + return isa; + } + + private static final int SOCKET_NUM = 102; + private static final int IPC_NUM = 117; + + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + + private SyscallEventInfo info; + public SyscallEventInfo getSyscallEventInfo () + { + if (info == null) + info = new SyscallEventInfo () + { + public int number (Task task) + { + return (int)getRegisterByName ("orig_eax").get (task); + } + public long returnCode (Task task) + { + return getRegisterByName ("eax").get (task); + } + public long arg (Task task, int n) + { + int num = number (task); + + if (n == 0) + return num; + + /** For socket_syscall and ipc_syscall*/ + if (num == SOCKET_NUM || num == IPC_NUM) + { + /** FIXME: Get arguments from memory via PTRACE_PEEKDATA. */ + return 0; + } + else + { + switch (n) + { + case 1: + return getRegisterByName("ebx").get (task); + case 2: + return getRegisterByName("ecx").get (task); + case 3: + return getRegisterByName("edx").get (task); + case 4: + return getRegisterByName("esi").get (task); + case 5: + return getRegisterByName("edi").get (task); + case 6: + return getRegisterByName("eax").get (task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + } + + public Syscall getSyscall(Task task) + { + int number = this.number(task); + + if (number != SOCKET_NUM && number != IPC_NUM) + return syscallByNum (number, task); + else + { + /** sub syscall number is in %ebx. */ + int subSyscallNumber = (int) getRegisterByName("ebx").get (task); + + if (number == SOCKET_NUM) + { + return socketSubcallList[subSyscallNumber]; + } + else + { + return ipcSubcallList[subSyscallNumber]; + } + } + } + + }; + return info; + } + + static Syscall[] syscallList = { + new Syscall (0), + new Syscall ("exit", 1, 1), + new Syscall ("fork", 2, 0, "i: "), + new Syscall ("read", 3, 3, "i:ibn "), + new Syscall ("write", 4, 3, "i:ibn "), + new Syscall ("open", 5, 3, "i:siv "), + new Syscall ("close", 6, 1, "i:i "), + new Syscall ("waitpid", 7, 3, "i:ipi "), + new Syscall ("creat", 8, 2, "i:sv"), + new Syscall ("link", 9, 2, "i:ss "), + new Syscall ("unlink", 10, 1, "i:s "), + new Syscall ("execve", 11, 3, "i:ppp "), + new Syscall ("chdir", 12, 1, "i:s "), + new Syscall ("time", 13, 1, "i:P "), + new Syscall ("sys_mknod", 14, 3, "i:sii "), + new Syscall ("chmod", 15, 2, "i:si "), + new Syscall ("lchown", 16, 3, "i:sii "), + new Syscall ("break", 17), + new Syscall ("old_stat", 18, 3, "i:pp "), + new Syscall ("lseek", 19, 3, "i:iii "), + new Syscall ("getpid", 20, 0, "i: "), + new Syscall ("mount", 21, 5, "i:sssip "), + new Syscall ("umount", 22, 1, "i:s "), + new Syscall ("setuid", 23, 1, "i:i "), + new Syscall ("getuid", 24, 0, "i: "), + new Syscall ("stime", 25, 1, "i:p "), + new Syscall ("ptrace", 26, 4, "i:iiii "), + new Syscall ("alarm", 27, 1, "i:i "), + new Syscall ("old_fstat", 28, 2, "i:ip "), + new Syscall ("pause", 29, 0, "i: "), + new Syscall ("utime", 30, 2, "i:sP "), + new Syscall ("stty", 31), + new Syscall ("gtty", 32), + new Syscall ("access", 33, 2, "i:si "), + new Syscall ("nice", 34, 1, "i:i "), + new Syscall ("ftime", 35, 1, "i:p "), + new Syscall ("sync", 36, 0, "i: "), + new Syscall ("kill", 37, 2, "i:ii "), + new Syscall ("rename", 38, 2, "i:ss "), + new Syscall ("mkdir", 39, 2, "i:si "), + new Syscall ("rmdir", 40, 1, "i:s "), + new Syscall ("dup", 41, 1, "i:i "), + new Syscall ("pipe", 42, 1, "i:f "), + new Syscall ("times", 43, 1, "i:p "), + new Syscall ("prof", 44), + new Syscall ("brk", 45, 1, "i:p "), + new Syscall ("setgid", 46, 1, "i:i "), + new Syscall ("getgid", 47, 0, "i: "), + new Syscall ("signal", 48, 2, "i:ii "), + new Syscall ("geteuid", 49, 0, "i: "), + new Syscall ("getegid", 50, 0, "i: "), + new Syscall ("acct", 51, 1, "i:S "), + new Syscall ("umount2", 52, 2, "i:si "), + new Syscall ("lock", 53), + new Syscall ("ioctl", 54, 3, "i:iiI "), + new Syscall ("fcntl", 55, 3, "i:iiF "), + new Syscall ("mpx", 56), + new Syscall ("setpgid", 57, 2, "i:ii "), + new Syscall ("ulimit", 58, 2, "i:ii "), + new Syscall ("oldolduname", 59), + new Syscall ("umask", 60, 1, "i:i "), + new Syscall ("chroot", 61, 1, "i:s "), + new Syscall ("ustat", 62, 2, "i:ip "), + new Syscall ("dup2", 63, 2, "i:ii "), + new Syscall ("getppid", 64, 0, "i: "), + new Syscall ("getpgrp", 65, 0, "i: "), + new Syscall ("setsid", 66, 0, "i: "), + new Syscall ("sigaction", 67, 3, "i:ipp "), + new Syscall ("sgetmask", 68), + new Syscall ("ssetmask", 69), + new Syscall ("setreuid", 70, 2, "i:ii "), + new Syscall ("setregid", 71, 2, "i:ii "), + new Syscall ("sigsuspend", 72, 1, "i:p "), + new Syscall ("sigpending", 73, 1, "i:p "), + new Syscall ("sethostname", 74, 2, "i:pi "), + new Syscall ("setrlimit", 75, 2, "i:ip "), + new Syscall ("getrlimit", 76, 2, "i:ip "), + new Syscall ("getrusage", 77, 2, "i:ip "), + new Syscall ("gettimeofday", 78, 2, "i:PP "), + new Syscall ("settimeofday", 79, 2, "i:PP "), + new Syscall ("getgroups", 80, 2, "i:ip "), + new Syscall ("setgroups", 81, 2, "i:ip "), + new Syscall ("select", 82, 5, "i:iPPPP "), + new Syscall ("symlink", 83, 2, "i:ss "), + new Syscall ("oldlstat", 84, 2, "i:pp "), + new Syscall ("readlink", 85, 3, "i:spi "), + new Syscall ("uselib", 86, 1, "i:s "), + new Syscall ("swapon", 87, 2, "i:si "), + new Syscall ("reboot", 88, 1, "i:i "), + new Syscall (89), + new Syscall ("mmap", 90, 6, "b:aniiii "), + new Syscall ("munmap", 91, 2, "i:ai "), + new Syscall ("truncate", 92, 2, "i:si "), + new Syscall ("ftruncate", 93, 2, "i:ii "), + new Syscall ("fchmod", 94, 2, "i:ii "), + new Syscall ("fchown", 95, 3, "i:iii "), + new Syscall ("getpriority", 96, 2, "i:ii "), + new Syscall ("setpriority", 97, 3, "i:iii "), + new Syscall ("profil", 98, 4, "i:piii "), + new Syscall ("statfs", 99, 2, "i:sp "), + new Syscall ("fstatfs", 100, 2, "i:ip "), + new Syscall ("ioperm", 101, 3, "i:iii "), + new Syscall ("socketcall", 102, 2, "i:ip "), + new Syscall ("klogctl", 103, 3, "i:isi "), + new Syscall ("setitimer", 104, 3, "i:ipp "), + new Syscall ("getitimer", 105, 2, "i:ip "), + new Syscall ("sys_stat", 106, 2, "i:sp "), + new Syscall ("sys_lstat", 107, 2, "i:sp "), + new Syscall ("sys_fstat", 108, 2, "i:ip "), + new Syscall ("old_uname", 109, 1, "i:p "), + new Syscall ("iopl", 110, 1, "i:i "), + new Syscall ("vhangup", 111, 1, "i:i "), + new Syscall ("idle", 112, 0, "i: "), + new Syscall (113), + new Syscall ("wait4", 114, 4, "i:iWiP "), + new Syscall ("swapoff", 115, 1, "i:s "), + new Syscall ("sysinfo", 116, 1, "i:p "), + new Syscall ("ipc", 117, 6, "i:iiiipi "), + new Syscall ("fsync", 118, 1, "i:i "), + new Syscall ("sigreturn", 119), + new Syscall ("clone", 120, 2, "i:ip "), + new Syscall ("setdomain", 121, 2, "i:si "), + new Syscall ("uname", 122, 1, "i:p "), + new Syscall ("modify_ldt", 123, 3, "i:ipi "), + new Syscall ("adjtimex", 124, 1, "i:p "), + new Syscall ("mprotect", 125, 3, "i:aii "), + new Syscall ("sigprocmask", 126, 3, "i:ipp "), + new Syscall ("create_module", 127, 3), + new Syscall ("init_module", 128, 5), + new Syscall ("delete_module", 129, 3), + new Syscall ("get_kernel_syms", 130, 1, "i:p "), + new Syscall ("quotactl", 131, 4, "i:isip "), + new Syscall ("getpgid", 132, 1, "i:i "), + new Syscall ("fchdir", 133, 1, "i:i "), + new Syscall ("bdflush", 134, 2, "i:ii "), + new Syscall ("sysfs", 135, 1, "i:i "), + new Syscall ("personality", 136, 1, "i:i "), + new Syscall ("afs_syscall", 137), + new Syscall ("setfsuid", 138, 1, "i:i "), + new Syscall ("setfsgid", 139, 1, "i:i "), + new Syscall ("llseek", 140, 5, "i:iuupi "), + new Syscall ("s_getdents", 141, 3, "i:ipi "), + new Syscall ("select", 142, 5, "i:iPPPP "), + new Syscall ("flock", 143, 2, "i:ii "), + new Syscall ("msync", 144, 3, "i:aii "), + new Syscall ("readv", 145, 3, "i:ipi "), + new Syscall ("writev", 146, 3, "i:ipi "), + new Syscall ("getsid", 147, 1, "i:i "), + new Syscall ("fdatasync", 148, 1, "i:i "), + new Syscall ("sysctl", 149, 1, "i:p "), + new Syscall ("mlock", 150, 2, "i:bn "), + new Syscall ("munlock", 151, 2, "i:ai "), + new Syscall ("mlockall", 152, 1, "i:i "), + new Syscall ("munlockall", 153, 0, "i: "), + new Syscall ("sched_setp", 154, 2, "i:ip "), + new Syscall ("sched_getp", 155, 2, "i:ip "), + new Syscall ("sched_sets", 156, 3, "i:iip "), + new Syscall ("sched_gets", 157, 1, "i:i "), + new Syscall ("sched_yield", 158, 0, "i: "), + new Syscall ("sched_primax", 159, 1, "i:i "), + new Syscall ("sched_primin", 160, 1, "i:i "), + new Syscall ("sched_rr_gi", 161, 2, "i:ip "), + new Syscall ("nanosleep", 162, 2, "i:pp "), + new Syscall ("mremap", 163, 4, "b:aini "), + new Syscall ("setresuid", 164, 3, "i:iii "), + new Syscall ("getresuid", 165, 3, "i:ppp "), + new Syscall ("vm86", 166, 1, "i:p "), + new Syscall ("query_module", 167, 5, "i:sipip "), + new Syscall ("poll", 168, 3, "i:pii "), + new Syscall ("nfsservctl", 169, 3, "i:ipp "), + new Syscall ("setresgid", 170, 3, "i:iii "), + new Syscall ("getresgid", 171, 3, "i:ppp "), + new Syscall ("prctl", 172, 5, "i:iiiii "), + new Syscall ("rt_sigreturn", 173), + new Syscall ("rt_sigaction", 174), + new Syscall ("rt_sigprocmask", 175), + new Syscall ("rt_sigpending", 176), + new Syscall ("rt_sigtimedwait", 177), + new Syscall ("rt_sigqueueinfo", 178), + new Syscall ("rt_sigsuspend", 179), + new Syscall ("pread64", 180), + new Syscall ("pwrite64", 181), + new Syscall ("chown", 182, 3, "i:sii "), + new Syscall ("getcwd", 183, 2, "i:bi "), + new Syscall ("capget", 184, 2, "i:pp "), + new Syscall ("capset", 185, 2, "i:pp "), + new Syscall ("sigaltstack", 186, 2, "i:PP "), + new Syscall ("sendfile", 187, 4, "i:iipi "), + new Syscall ("getpmsg", 188), + new Syscall ("putpmsg", 189), + new Syscall ("vfork", 190, 0, "i: "), + new Syscall ("ugetrlimit", 191), + new Syscall ("mmap", 192, 6, "b:aniiii "), + new Syscall ("truncate64", 193, 3, "i:shl "), + new Syscall ("ftruncate64", 194, 3, "i:ihl "), + new Syscall ("stat64", 195, 2, "i:sp "), + new Syscall ("lstat64", 196, 2, "i:sp "), + new Syscall ("fstat64", 197, 2, "i:ip "), + new Syscall ("lchown32", 198, 3, "i:sii "), + new Syscall ("getuid32", 199), + new Syscall ("getgid32", 200), + new Syscall ("geteuid32", 201), + new Syscall ("getegid32", 202), + new Syscall ("setreuid32", 203, 2, "i:ii "), + new Syscall ("setregid32", 204, 2, "i:ii "), + new Syscall ("getgroups32", 205, 2, "i:ip "), + new Syscall ("setgroups32", 206, 2, "i:ip "), + new Syscall ("fchown32", 207, 3, "i:iii "), + new Syscall ("setresuid32", 208, 3, "i:iii "), + new Syscall ("getresuid32", 209, 3, "i:ppp "), + new Syscall ("setresgid32", 210, 3, "i:iii "), + new Syscall ("getresgid32", 211, 3, "i:ppp "), + new Syscall ("chown32", 212, 3, "i:sii "), + new Syscall ("setuid32", 213, 1, "i:i "), + new Syscall ("setgid32", 214, 1, "i:i "), + new Syscall ("setfsuid32", 215, 1, "i:i "), + new Syscall ("setfsgid32", 216, 1, "i:i "), + new Syscall ("pivot_root", 217, 2, "i:ss "), + new Syscall ("mincore", 218, 3, "i:anV "), + new Syscall ("madvise", 219, 3, "i:pii "), + new Syscall ("getdents64", 220, 3, "i:ipi "), + new Syscall ("fcntl64", 221, 3, "i:iip "), + new Syscall (222), + new Syscall (223), + new Syscall ("gettid", 224, 0), + new Syscall ("readahead", 225, 4, "i:ihli "), + new Syscall ("setxattr", 226), + new Syscall ("lsetxattr", 227), + new Syscall ("fsetxattr", 228), + new Syscall ("getxattr", 229), + new Syscall ("lgetxattr", 230), + new Syscall ("fgetxattr", 231), + new Syscall ("listxattr", 232), + new Syscall ("llistxattr", 233), + new Syscall ("flistxattr", 234), + new Syscall ("removexattr", 235), + new Syscall ("lremovexattr", 236), + new Syscall ("fremovexattr", 237), + new Syscall ("tkill", 238, 2, "i:ii "), + new Syscall ("sendfile64", 239, 4, "i:iipi "), + new Syscall ("futex", 240, 4, "i:piip "), + new Syscall ("sched_setaffinity", 241), + new Syscall ("sched_getaffinity", 242), + new Syscall ("set_thread_area", 243, 1, "i:p "), + new Syscall ("get_thread_area", 244, 1, "i:p "), + new Syscall ("io_setup", 245, 2, "i:ip "), + new Syscall ("io_destroy", 246, 1, "i:i "), + new Syscall ("io_getevents", 247, 5, "i:iiipp "), + new Syscall ("io_submit", 248, 3, "i:iip "), + new Syscall ("io_cancel", 249, 3, "i:ipp "), + new Syscall ("fadvise64", 250), + new Syscall (251), + new Syscall ("exit_group", 252, 1, " :i ", true), + new Syscall ("lookup_dcookie", 253), + new Syscall ("epoll_create", 254), + new Syscall ("epoll_ctl", 255), + new Syscall ("epoll_wait", 256), + new Syscall ("remap_file_pages", 257), + new Syscall ("set_tid_address", 258), + new Syscall ("timer_create", 259), + new Syscall ("timer_settime", 260), + new Syscall ("timer_gettime", 261), + new Syscall ("timer_getoverrun", 262), + new Syscall ("timer_delete", 263), + new Syscall ("clock_settime", 264), + new Syscall ("clock_gettime", 265), + new Syscall ("clock_getres", 266), + new Syscall ("clock_nanosleep", 267), + new Syscall ("statfs64", 268), + new Syscall ("fstatfs64", 269), + new Syscall ("tgkill", 270), + new Syscall ("utimes", 271), + new Syscall ("fadvise64_64", 272) + }; + + + static class SubSyscall + extends Syscall + { + SubSyscall (String name, int number) { - if (isa == null) - isa = new LinuxIa32 (); - return isa; + super (name, number); } - - private SyscallEventInfo info; - public SyscallEventInfo getSyscallEventInfo () + SubSyscall (String name, int number, int numArgs, String argList) { - if (info == null) - info = new SyscallEventInfo () - { - public int number (Task task) - { - return (int)getRegisterByName ("orig_eax").get (task); - } - public long returnCode (Task task) - { - return getRegisterByName ("eax").get (task); - } - public long arg (Task task, int n) - { - switch (n) { - case 0: - return (long)number (task); - case 1: - return getRegisterByName("ebx").get (task); - case 2: - return getRegisterByName("ecx").get (task); - case 3: - return getRegisterByName("edx").get (task); - case 4: - return getRegisterByName("esi").get (task); - case 5: - return getRegisterByName("edi").get (task); - case 6: - return getRegisterByName("eax").get (task); - default: - throw new RuntimeException ("unknown syscall arg"); - } - } - }; - return info; + super (name, number, numArgs, argList); } + } + + static Syscall[] socketSubcallList = { + new SubSyscall ("", SOCKET_NUM), + new SubSyscall ("socket", SOCKET_NUM, 3, "i:iii"), + new SubSyscall ("bind", SOCKET_NUM, 3, "i:ipi "), + new SubSyscall ("connect", SOCKET_NUM, 3, "i:ipi "), + new SubSyscall ("listen", SOCKET_NUM, 2, "i:ii "), + new SubSyscall ("accept", SOCKET_NUM, 3, "i:ipp "), + new SubSyscall ("getsockname",SOCKET_NUM, 3, "i:ipp "), + new SubSyscall ("getpeername",SOCKET_NUM, 4, "i:iiip "), + new SubSyscall ("socketpair", SOCKET_NUM, 4, "i:iiip "), + new SubSyscall ("send", SOCKET_NUM, 4, "i:ipii "), + new SubSyscall ("recv", SOCKET_NUM, 4, "i:ipii "), + new SubSyscall ("sendto", SOCKET_NUM, 6, "i:ipiipi"), + new SubSyscall ("recvfrom", SOCKET_NUM, 6, "i:ipiipp "), + new SubSyscall ("shutdown", SOCKET_NUM, 2, "i:ii "), + new SubSyscall ("setsockopt", SOCKET_NUM, 5, "i:iiipp ") + }; + + static Syscall[] ipcSubcallList = { + new SubSyscall ("semop", IPC_NUM), + new SubSyscall ("semget", IPC_NUM), + new SubSyscall ("semctl", IPC_NUM), + new SubSyscall ("semtimedop", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("msgsnd", IPC_NUM), + new SubSyscall ("msgrcv", IPC_NUM), + new SubSyscall ("msgget", IPC_NUM), + new SubSyscall ("msgctl", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("", IPC_NUM), + new SubSyscall ("shmat", IPC_NUM), + new SubSyscall ("shmdt", IPC_NUM), + new SubSyscall ("shmget", IPC_NUM), + new SubSyscall ("shmctl", IPC_NUM) + }; + + } Index: frysk-core/frysk/proc/LinuxPPC.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC.java,v retrieving revision 1.3 diff -u -r1.3 LinuxPPC.java --- frysk-core/frysk/proc/LinuxPPC.java 4 Sep 2006 07:40:06 -0000 1.3 +++ frysk-core/frysk/proc/LinuxPPC.java 8 Sep 2006 10:55:50 -0000 @@ -2,6 +2,8 @@ package frysk.proc; +import java.util.HashMap; + import java.util.logging.Level; import java.util.logging.Logger; @@ -18,6 +20,10 @@ return isa; } + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + private SyscallEventInfo info; public SyscallEventInfo getSyscallEventInfo () @@ -61,7 +67,284 @@ throw new RuntimeException ("unknown syscall arg"); } } + }; return info; } -} \ No newline at end of file + /** FIXME: This syscallList is i386 specific. */ + static Syscall[] syscallList = { + new Syscall (0), + new Syscall ("exit", 1, 1), + new Syscall ("fork", 2, 0, "i: "), + new Syscall ("read", 3, 3, "i:ibn "), + new Syscall ("write", 4, 3, "i:ibn "), + new Syscall ("open", 5, 3, "i:siv "), + new Syscall ("close", 6, 1, "i:i "), + new Syscall ("waitpid", 7, 3, "i:ipi "), + new Syscall ("creat", 8, 2, "i:sv"), + new Syscall ("link", 9, 2, "i:ss "), + new Syscall ("unlink", 10, 1, "i:s "), + new Syscall ("execve", 11, 3, "i:ppp "), + new Syscall ("chdir", 12, 1, "i:s "), + new Syscall ("time", 13, 1, "i:P "), + new Syscall ("sys_mknod", 14, 3, "i:sii "), + new Syscall ("chmod", 15, 2, "i:si "), + new Syscall ("lchown", 16, 3, "i:sii "), + new Syscall ("break", 17), + new Syscall ("old_stat", 18, 3, "i:pp "), + new Syscall ("lseek", 19, 3, "i:iii "), + new Syscall ("getpid", 20, 0, "i: "), + new Syscall ("mount", 21, 5, "i:sssip "), + new Syscall ("umount", 22, 1, "i:s "), + new Syscall ("setuid", 23, 1, "i:i "), + new Syscall ("getuid", 24, 0, "i: "), + new Syscall ("stime", 25, 1, "i:p "), + new Syscall ("ptrace", 26, 4, "i:iiii "), + new Syscall ("alarm", 27, 1, "i:i "), + new Syscall ("old_fstat", 28, 2, "i:ip "), + new Syscall ("pause", 29, 0, "i: "), + new Syscall ("utime", 30, 2, "i:sP "), + new Syscall ("stty", 31), + new Syscall ("gtty", 32), + new Syscall ("access", 33, 2, "i:si "), + new Syscall ("nice", 34, 1, "i:i "), + new Syscall ("ftime", 35, 1, "i:p "), + new Syscall ("sync", 36, 0, "i: "), + new Syscall ("kill", 37, 2, "i:ii "), + new Syscall ("rename", 38, 2, "i:ss "), + new Syscall ("mkdir", 39, 2, "i:si "), + new Syscall ("rmdir", 40, 1, "i:s "), + new Syscall ("dup", 41, 1, "i:i "), + new Syscall ("pipe", 42, 1, "i:f "), + new Syscall ("times", 43, 1, "i:p "), + new Syscall ("prof", 44), + new Syscall ("brk", 45, 1, "i:p "), + new Syscall ("setgid", 46, 1, "i:i "), + new Syscall ("getgid", 47, 0, "i: "), + new Syscall ("signal", 48, 2, "i:ii "), + new Syscall ("geteuid", 49, 0, "i: "), + new Syscall ("getegid", 50, 0, "i: "), + new Syscall ("acct", 51, 1, "i:S "), + new Syscall ("umount2", 52, 2, "i:si "), + new Syscall ("lock", 53), + new Syscall ("ioctl", 54, 3, "i:iiI "), + new Syscall ("fcntl", 55, 3, "i:iiF "), + new Syscall ("mpx", 56), + new Syscall ("setpgid", 57, 2, "i:ii "), + new Syscall ("ulimit", 58, 2, "i:ii "), + new Syscall ("oldolduname", 59), + new Syscall ("umask", 60, 1, "i:i "), + new Syscall ("chroot", 61, 1, "i:s "), + new Syscall ("ustat", 62, 2, "i:ip "), + new Syscall ("dup2", 63, 2, "i:ii "), + new Syscall ("getppid", 64, 0, "i: "), + new Syscall ("getpgrp", 65, 0, "i: "), + new Syscall ("setsid", 66, 0, "i: "), + new Syscall ("sigaction", 67, 3, "i:ipp "), + new Syscall ("sgetmask", 68), + new Syscall ("ssetmask", 69), + new Syscall ("setreuid", 70, 2, "i:ii "), + new Syscall ("setregid", 71, 2, "i:ii "), + new Syscall ("sigsuspend", 72, 1, "i:p "), + new Syscall ("sigpending", 73, 1, "i:p "), + new Syscall ("sethostname", 74, 2, "i:pi "), + new Syscall ("setrlimit", 75, 2, "i:ip "), + new Syscall ("getrlimit", 76, 2, "i:ip "), + new Syscall ("getrusage", 77, 2, "i:ip "), + new Syscall ("gettimeofday", 78, 2, "i:PP "), + new Syscall ("settimeofday", 79, 2, "i:PP "), + new Syscall ("getgroups", 80, 2, "i:ip "), + new Syscall ("setgroups", 81, 2, "i:ip "), + new Syscall ("select", 82, 5, "i:iPPPP "), + new Syscall ("symlink", 83, 2, "i:ss "), + new Syscall ("oldlstat", 84, 2, "i:pp "), + new Syscall ("readlink", 85, 3, "i:spi "), + new Syscall ("uselib", 86, 1, "i:s "), + new Syscall ("swapon", 87, 2, "i:si "), + new Syscall ("reboot", 88, 1, "i:i "), + new Syscall (89), + new Syscall ("mmap", 90, 6, "b:aniiii "), + new Syscall ("munmap", 91, 2, "i:ai "), + new Syscall ("truncate", 92, 2, "i:si "), + new Syscall ("ftruncate", 93, 2, "i:ii "), + new Syscall ("fchmod", 94, 2, "i:ii "), + new Syscall ("fchown", 95, 3, "i:iii "), + new Syscall ("getpriority", 96, 2, "i:ii "), + new Syscall ("setpriority", 97, 3, "i:iii "), + new Syscall ("profil", 98, 4, "i:piii "), + new Syscall ("statfs", 99, 2, "i:sp "), + new Syscall ("fstatfs", 100, 2, "i:ip "), + new Syscall ("ioperm", 101, 3, "i:iii "), + new Syscall ("socketcall", 102, 2, "i:ip "), + new Syscall ("klogctl", 103, 3, "i:isi "), + new Syscall ("setitimer", 104, 3, "i:ipp "), + new Syscall ("getitimer", 105, 2, "i:ip "), + new Syscall ("sys_stat", 106, 2, "i:sp "), + new Syscall ("sys_lstat", 107, 2, "i:sp "), + new Syscall ("sys_fstat", 108, 2, "i:ip "), + new Syscall ("old_uname", 109, 1, "i:p "), + new Syscall ("iopl", 110, 1, "i:i "), + new Syscall ("vhangup", 111, 1, "i:i "), + new Syscall ("idle", 112, 0, "i: "), + new Syscall (113), + new Syscall ("wait4", 114, 4, "i:iWiP "), + new Syscall ("swapoff", 115, 1, "i:s "), + new Syscall ("sysinfo", 116, 1, "i:p "), + new Syscall ("ipc", 117, 6, "i:iiiipi "), + new Syscall ("fsync", 118, 1, "i:i "), + new Syscall ("sigreturn", 119), + new Syscall ("clone", 120, 2, "i:ip "), + new Syscall ("setdomain", 121, 2, "i:si "), + new Syscall ("uname", 122, 1, "i:p "), + new Syscall ("modify_ldt", 123, 3, "i:ipi "), + new Syscall ("adjtimex", 124, 1, "i:p "), + new Syscall ("mprotect", 125, 3, "i:aii "), + new Syscall ("sigprocmask", 126, 3, "i:ipp "), + new Syscall ("create_module", 127, 3), + new Syscall ("init_module", 128, 5), + new Syscall ("delete_module", 129, 3), + new Syscall ("get_kernel_syms", 130, 1, "i:p "), + new Syscall ("quotactl", 131, 4, "i:isip "), + new Syscall ("getpgid", 132, 1, "i:i "), + new Syscall ("fchdir", 133, 1, "i:i "), + new Syscall ("bdflush", 134, 2, "i:ii "), + new Syscall ("sysfs", 135, 1, "i:i "), + new Syscall ("personality", 136, 1, "i:i "), + new Syscall ("afs_syscall", 137), + new Syscall ("setfsuid", 138, 1, "i:i "), + new Syscall ("setfsgid", 139, 1, "i:i "), + new Syscall ("llseek", 140, 5, "i:iuupi "), + new Syscall ("s_getdents", 141, 3, "i:ipi "), + new Syscall ("select", 142, 5, "i:iPPPP "), + new Syscall ("flock", 143, 2, "i:ii "), + new Syscall ("msync", 144, 3, "i:aii "), + new Syscall ("readv", 145, 3, "i:ipi "), + new Syscall ("writev", 146, 3, "i:ipi "), + new Syscall ("getsid", 147, 1, "i:i "), + new Syscall ("fdatasync", 148, 1, "i:i "), + new Syscall ("sysctl", 149, 1, "i:p "), + new Syscall ("mlock", 150, 2, "i:bn "), + new Syscall ("munlock", 151, 2, "i:ai "), + new Syscall ("mlockall", 152, 1, "i:i "), + new Syscall ("munlockall", 153, 0, "i: "), + new Syscall ("sched_setp", 154, 2, "i:ip "), + new Syscall ("sched_getp", 155, 2, "i:ip "), + new Syscall ("sched_sets", 156, 3, "i:iip "), + new Syscall ("sched_gets", 157, 1, "i:i "), + new Syscall ("sched_yield", 158, 0, "i: "), + new Syscall ("sched_primax", 159, 1, "i:i "), + new Syscall ("sched_primin", 160, 1, "i:i "), + new Syscall ("sched_rr_gi", 161, 2, "i:ip "), + new Syscall ("nanosleep", 162, 2, "i:pp "), + new Syscall ("mremap", 163, 4, "b:aini "), + new Syscall ("setresuid", 164, 3, "i:iii "), + new Syscall ("getresuid", 165, 3, "i:ppp "), + new Syscall ("vm86", 166, 1, "i:p "), + new Syscall ("query_module", 167, 5, "i:sipip "), + new Syscall ("poll", 168, 3, "i:pii "), + new Syscall ("nfsservctl", 169, 3, "i:ipp "), + new Syscall ("setresgid", 170, 3, "i:iii "), + new Syscall ("getresgid", 171, 3, "i:ppp "), + new Syscall ("prctl", 172, 5, "i:iiiii "), + new Syscall ("rt_sigreturn", 173), + new Syscall ("rt_sigaction", 174), + new Syscall ("rt_sigprocmask", 175), + new Syscall ("rt_sigpending", 176), + new Syscall ("rt_sigtimedwait", 177), + new Syscall ("rt_sigqueueinfo", 178), + new Syscall ("rt_sigsuspend", 179), + new Syscall ("pread64", 180), + new Syscall ("pwrite64", 181), + new Syscall ("chown", 182, 3, "i:sii "), + new Syscall ("getcwd", 183, 2, "i:bi "), + new Syscall ("capget", 184, 2, "i:pp "), + new Syscall ("capset", 185, 2, "i:pp "), + new Syscall ("sigaltstack", 186, 2, "i:PP "), + new Syscall ("sendfile", 187, 4, "i:iipi "), + new Syscall ("getpmsg", 188), + new Syscall ("putpmsg", 189), + new Syscall ("vfork", 190, 0, "i: "), + new Syscall ("ugetrlimit", 191), + new Syscall ("mmap", 192, 6, "b:aniiii "), + new Syscall ("truncate64", 193, 3, "i:shl "), + new Syscall ("ftruncate64", 194, 3, "i:ihl "), + new Syscall ("stat64", 195, 2, "i:sp "), + new Syscall ("lstat64", 196, 2, "i:sp "), + new Syscall ("fstat64", 197, 2, "i:ip "), + new Syscall ("lchown32", 198, 3, "i:sii "), + new Syscall ("getuid32", 199), + new Syscall ("getgid32", 200), + new Syscall ("geteuid32", 201), + new Syscall ("getegid32", 202), + new Syscall ("setreuid32", 203, 2, "i:ii "), + new Syscall ("setregid32", 204, 2, "i:ii "), + new Syscall ("getgroups32", 205, 2, "i:ip "), + new Syscall ("setgroups32", 206, 2, "i:ip "), + new Syscall ("fchown32", 207, 3, "i:iii "), + new Syscall ("setresuid32", 208, 3, "i:iii "), + new Syscall ("getresuid32", 209, 3, "i:ppp "), + new Syscall ("setresgid32", 210, 3, "i:iii "), + new Syscall ("getresgid32", 211, 3, "i:ppp "), + new Syscall ("chown32", 212, 3, "i:sii "), + new Syscall ("setuid32", 213, 1, "i:i "), + new Syscall ("setgid32", 214, 1, "i:i "), + new Syscall ("setfsuid32", 215, 1, "i:i "), + new Syscall ("setfsgid32", 216, 1, "i:i "), + new Syscall ("pivot_root", 217, 2, "i:ss "), + new Syscall ("mincore", 218, 3, "i:anV "), + new Syscall ("madvise", 219, 3, "i:pii "), + new Syscall ("getdents64", 220, 3, "i:ipi "), + new Syscall ("fcntl64", 221, 3, "i:iip "), + new Syscall (222), + new Syscall (223), + new Syscall ("gettid", 224, 0), + new Syscall ("readahead", 225, 4, "i:ihli "), + new Syscall ("setxattr", 226), + new Syscall ("lsetxattr", 227), + new Syscall ("fsetxattr", 228), + new Syscall ("getxattr", 229), + new Syscall ("lgetxattr", 230), + new Syscall ("fgetxattr", 231), + new Syscall ("listxattr", 232), + new Syscall ("llistxattr", 233), + new Syscall ("flistxattr", 234), + new Syscall ("removexattr", 235), + new Syscall ("lremovexattr", 236), + new Syscall ("fremovexattr", 237), + new Syscall ("tkill", 238, 2, "i:ii "), + new Syscall ("sendfile64", 239, 4, "i:iipi "), + new Syscall ("futex", 240, 4, "i:piip "), + new Syscall ("sched_setaffinity", 241), + new Syscall ("sched_getaffinity", 242), + new Syscall ("set_thread_area", 243, 1, "i:p "), + new Syscall ("get_thread_area", 244, 1, "i:p "), + new Syscall ("io_setup", 245, 2, "i:ip "), + new Syscall ("io_destroy", 246, 1, "i:i "), + new Syscall ("io_getevents", 247, 5, "i:iiipp "), + new Syscall ("io_submit", 248, 3, "i:iip "), + new Syscall ("io_cancel", 249, 3, "i:ipp "), + new Syscall ("fadvise64", 250), + new Syscall (251), + new Syscall ("exit_group", 252, 1, " :i ", true), + new Syscall ("lookup_dcookie", 253), + new Syscall ("epoll_create", 254), + new Syscall ("epoll_ctl", 255), + new Syscall ("epoll_wait", 256), + new Syscall ("remap_file_pages", 257), + new Syscall ("set_tid_address", 258), + new Syscall ("timer_create", 259), + new Syscall ("timer_settime", 260), + new Syscall ("timer_gettime", 261), + new Syscall ("timer_getoverrun", 262), + new Syscall ("timer_delete", 263), + new Syscall ("clock_settime", 264), + new Syscall ("clock_gettime", 265), + new Syscall ("clock_getres", 266), + new Syscall ("clock_nanosleep", 267), + new Syscall ("statfs64", 268), + new Syscall ("fstatfs64", 269), + new Syscall ("tgkill", 270), + new Syscall ("utimes", 271), + new Syscall ("fadvise64_64", 272), + }; +} Index: frysk-core/frysk/proc/LinuxPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC64.java,v retrieving revision 1.3 diff -u -r1.3 LinuxPPC64.java --- frysk-core/frysk/proc/LinuxPPC64.java 16 Aug 2006 19:09:51 -0000 1.3 +++ frysk-core/frysk/proc/LinuxPPC64.java 8 Sep 2006 10:55:50 -0000 @@ -2,6 +2,8 @@ package frysk.proc; +import java.util.HashMap; + import java.util.logging.Level; import java.util.logging.Logger; @@ -18,6 +20,10 @@ return isa; } + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + private SyscallEventInfo info; public SyscallEventInfo getSyscallEventInfo () { @@ -59,7 +65,285 @@ throw new RuntimeException ("unknown syscall arg"); } } + }; return info; } + + + static Syscall[] syscallList = { + new Syscall (0), + new Syscall ("exit", 1, 1), + new Syscall ("fork", 2, 0, "i: "), + new Syscall ("read", 3, 3, "i:ibn "), + new Syscall ("write", 4, 3, "i:ibn "), + new Syscall ("open", 5, 3, "i:siv "), + new Syscall ("close", 6, 1, "i:i "), + new Syscall ("waitpid", 7, 3, "i:ipi "), + new Syscall ("creat", 8, 2, "i:sv"), + new Syscall ("link", 9, 2, "i:ss "), + new Syscall ("unlink", 10, 1, "i:s "), + new Syscall ("execve", 11, 3, "i:ppp "), + new Syscall ("chdir", 12, 1, "i:s "), + new Syscall ("time", 13, 1, "i:P "), + new Syscall ("sys_mknod", 14, 3, "i:sii "), + new Syscall ("chmod", 15, 2, "i:si "), + new Syscall ("lchown", 16, 3, "i:sii "), + new Syscall ("break", 17), + new Syscall ("old_stat", 18, 3, "i:pp "), + new Syscall ("lseek", 19, 3, "i:iii "), + new Syscall ("getpid", 20, 0, "i: "), + new Syscall ("mount", 21, 5, "i:sssip "), + new Syscall ("umount", 22, 1, "i:s "), + new Syscall ("setuid", 23, 1, "i:i "), + new Syscall ("getuid", 24, 0, "i: "), + new Syscall ("stime", 25, 1, "i:p "), + new Syscall ("ptrace", 26, 4, "i:iiii "), + new Syscall ("alarm", 27, 1, "i:i "), + new Syscall ("old_fstat", 28, 2, "i:ip "), + new Syscall ("pause", 29, 0, "i: "), + new Syscall ("utime", 30, 2, "i:sP "), + new Syscall ("stty", 31), + new Syscall ("gtty", 32), + new Syscall ("access", 33, 2, "i:si "), + new Syscall ("nice", 34, 1, "i:i "), + new Syscall ("ftime", 35, 1, "i:p "), + new Syscall ("sync", 36, 0, "i: "), + new Syscall ("kill", 37, 2, "i:ii "), + new Syscall ("rename", 38, 2, "i:ss "), + new Syscall ("mkdir", 39, 2, "i:si "), + new Syscall ("rmdir", 40, 1, "i:s "), + new Syscall ("dup", 41, 1, "i:i "), + new Syscall ("pipe", 42, 1, "i:f "), + new Syscall ("times", 43, 1, "i:p "), + new Syscall ("prof", 44), + new Syscall ("brk", 45, 1, "i:p "), + new Syscall ("setgid", 46, 1, "i:i "), + new Syscall ("getgid", 47, 0, "i: "), + new Syscall ("signal", 48, 2, "i:ii "), + new Syscall ("geteuid", 49, 0, "i: "), + new Syscall ("getegid", 50, 0, "i: "), + new Syscall ("acct", 51, 1, "i:S "), + new Syscall ("umount2", 52, 2, "i:si "), + new Syscall ("lock", 53), + new Syscall ("ioctl", 54, 3, "i:iiI "), + new Syscall ("fcntl", 55, 3, "i:iiF "), + new Syscall ("mpx", 56), + new Syscall ("setpgid", 57, 2, "i:ii "), + new Syscall ("ulimit", 58, 2, "i:ii "), + new Syscall ("oldolduname", 59), + new Syscall ("umask", 60, 1, "i:i "), + new Syscall ("chroot", 61, 1, "i:s "), + new Syscall ("ustat", 62, 2, "i:ip "), + new Syscall ("dup2", 63, 2, "i:ii "), + new Syscall ("getppid", 64, 0, "i: "), + new Syscall ("getpgrp", 65, 0, "i: "), + new Syscall ("setsid", 66, 0, "i: "), + new Syscall ("sigaction", 67, 3, "i:ipp "), + new Syscall ("sgetmask", 68), + new Syscall ("ssetmask", 69), + new Syscall ("setreuid", 70, 2, "i:ii "), + new Syscall ("setregid", 71, 2, "i:ii "), + new Syscall ("sigsuspend", 72, 1, "i:p "), + new Syscall ("sigpending", 73, 1, "i:p "), + new Syscall ("sethostname", 74, 2, "i:pi "), + new Syscall ("setrlimit", 75, 2, "i:ip "), + new Syscall ("getrlimit", 76, 2, "i:ip "), + new Syscall ("getrusage", 77, 2, "i:ip "), + new Syscall ("gettimeofday", 78, 2, "i:PP "), + new Syscall ("settimeofday", 79, 2, "i:PP "), + new Syscall ("getgroups", 80, 2, "i:ip "), + new Syscall ("setgroups", 81, 2, "i:ip "), + new Syscall ("select", 82, 5, "i:iPPPP "), + new Syscall ("symlink", 83, 2, "i:ss "), + new Syscall ("oldlstat", 84, 2, "i:pp "), + new Syscall ("readlink", 85, 3, "i:spi "), + new Syscall ("uselib", 86, 1, "i:s "), + new Syscall ("swapon", 87, 2, "i:si "), + new Syscall ("reboot", 88, 1, "i:i "), + new Syscall (89), + new Syscall ("mmap", 90, 6, "b:aniiii "), + new Syscall ("munmap", 91, 2, "i:ai "), + new Syscall ("truncate", 92, 2, "i:si "), + new Syscall ("ftruncate", 93, 2, "i:ii "), + new Syscall ("fchmod", 94, 2, "i:ii "), + new Syscall ("fchown", 95, 3, "i:iii "), + new Syscall ("getpriority", 96, 2, "i:ii "), + new Syscall ("setpriority", 97, 3, "i:iii "), + new Syscall ("profil", 98, 4, "i:piii "), + new Syscall ("statfs", 99, 2, "i:sp "), + new Syscall ("fstatfs", 100, 2, "i:ip "), + new Syscall ("ioperm", 101, 3, "i:iii "), + new Syscall ("socketcall", 102, 2, "i:ip "), + new Syscall ("klogctl", 103, 3, "i:isi "), + new Syscall ("setitimer", 104, 3, "i:ipp "), + new Syscall ("getitimer", 105, 2, "i:ip "), + new Syscall ("sys_stat", 106, 2, "i:sp "), + new Syscall ("sys_lstat", 107, 2, "i:sp "), + new Syscall ("sys_fstat", 108, 2, "i:ip "), + new Syscall ("old_uname", 109, 1, "i:p "), + new Syscall ("iopl", 110, 1, "i:i "), + new Syscall ("vhangup", 111, 1, "i:i "), + new Syscall ("idle", 112, 0, "i: "), + new Syscall (113), + new Syscall ("wait4", 114, 4, "i:iWiP "), + new Syscall ("swapoff", 115, 1, "i:s "), + new Syscall ("sysinfo", 116, 1, "i:p "), + new Syscall ("ipc", 117, 6, "i:iiiipi "), + new Syscall ("fsync", 118, 1, "i:i "), + new Syscall ("sigreturn", 119), + new Syscall ("clone", 120, 2, "i:ip "), + new Syscall ("setdomain", 121, 2, "i:si "), + new Syscall ("uname", 122, 1, "i:p "), + new Syscall ("modify_ldt", 123, 3, "i:ipi "), + new Syscall ("adjtimex", 124, 1, "i:p "), + new Syscall ("mprotect", 125, 3, "i:aii "), + new Syscall ("sigprocmask", 126, 3, "i:ipp "), + new Syscall ("create_module", 127, 3), + new Syscall ("init_module", 128, 5), + new Syscall ("delete_module", 129, 3), + new Syscall ("get_kernel_syms", 130, 1, "i:p "), + new Syscall ("quotactl", 131, 4, "i:isip "), + new Syscall ("getpgid", 132, 1, "i:i "), + new Syscall ("fchdir", 133, 1, "i:i "), + new Syscall ("bdflush", 134, 2, "i:ii "), + new Syscall ("sysfs", 135, 1, "i:i "), + new Syscall ("personality", 136, 1, "i:i "), + new Syscall ("afs_syscall", 137), + new Syscall ("setfsuid", 138, 1, "i:i "), + new Syscall ("setfsgid", 139, 1, "i:i "), + new Syscall ("llseek", 140, 5, "i:iuupi "), + new Syscall ("s_getdents", 141, 3, "i:ipi "), + new Syscall ("select", 142, 5, "i:iPPPP "), + new Syscall ("flock", 143, 2, "i:ii "), + new Syscall ("msync", 144, 3, "i:aii "), + new Syscall ("readv", 145, 3, "i:ipi "), + new Syscall ("writev", 146, 3, "i:ipi "), + new Syscall ("getsid", 147, 1, "i:i "), + new Syscall ("fdatasync", 148, 1, "i:i "), + new Syscall ("sysctl", 149, 1, "i:p "), + new Syscall ("mlock", 150, 2, "i:bn "), + new Syscall ("munlock", 151, 2, "i:ai "), + new Syscall ("mlockall", 152, 1, "i:i "), + new Syscall ("munlockall", 153, 0, "i: "), + new Syscall ("sched_setp", 154, 2, "i:ip "), + new Syscall ("sched_getp", 155, 2, "i:ip "), + new Syscall ("sched_sets", 156, 3, "i:iip "), + new Syscall ("sched_gets", 157, 1, "i:i "), + new Syscall ("sched_yield", 158, 0, "i: "), + new Syscall ("sched_primax", 159, 1, "i:i "), + new Syscall ("sched_primin", 160, 1, "i:i "), + new Syscall ("sched_rr_gi", 161, 2, "i:ip "), + new Syscall ("nanosleep", 162, 2, "i:pp "), + new Syscall ("mremap", 163, 4, "b:aini "), + new Syscall ("setresuid", 164, 3, "i:iii "), + new Syscall ("getresuid", 165, 3, "i:ppp "), + new Syscall ("vm86", 166, 1, "i:p "), + new Syscall ("query_module", 167, 5, "i:sipip "), + new Syscall ("poll", 168, 3, "i:pii "), + new Syscall ("nfsservctl", 169, 3, "i:ipp "), + new Syscall ("setresgid", 170, 3, "i:iii "), + new Syscall ("getresgid", 171, 3, "i:ppp "), + new Syscall ("prctl", 172, 5, "i:iiiii "), + new Syscall ("rt_sigreturn", 173), + new Syscall ("rt_sigaction", 174), + new Syscall ("rt_sigprocmask", 175), + new Syscall ("rt_sigpending", 176), + new Syscall ("rt_sigtimedwait", 177), + new Syscall ("rt_sigqueueinfo", 178), + new Syscall ("rt_sigsuspend", 179), + new Syscall ("pread64", 180), + new Syscall ("pwrite64", 181), + new Syscall ("chown", 182, 3, "i:sii "), + new Syscall ("getcwd", 183, 2, "i:bi "), + new Syscall ("capget", 184, 2, "i:pp "), + new Syscall ("capset", 185, 2, "i:pp "), + new Syscall ("sigaltstack", 186, 2, "i:PP "), + new Syscall ("sendfile", 187, 4, "i:iipi "), + new Syscall ("getpmsg", 188), + new Syscall ("putpmsg", 189), + new Syscall ("vfork", 190, 0, "i: "), + new Syscall ("ugetrlimit", 191), + new Syscall ("mmap", 192, 6, "b:aniiii "), + new Syscall ("truncate64", 193, 3, "i:shl "), + new Syscall ("ftruncate64", 194, 3, "i:ihl "), + new Syscall ("stat64", 195, 2, "i:sp "), + new Syscall ("lstat64", 196, 2, "i:sp "), + new Syscall ("fstat64", 197, 2, "i:ip "), + new Syscall ("lchown32", 198, 3, "i:sii "), + new Syscall ("getuid32", 199), + new Syscall ("getgid32", 200), + new Syscall ("geteuid32", 201), + new Syscall ("getegid32", 202), + new Syscall ("setreuid32", 203, 2, "i:ii "), + new Syscall ("setregid32", 204, 2, "i:ii "), + new Syscall ("getgroups32", 205, 2, "i:ip "), + new Syscall ("setgroups32", 206, 2, "i:ip "), + new Syscall ("fchown32", 207, 3, "i:iii "), + new Syscall ("setresuid32", 208, 3, "i:iii "), + new Syscall ("getresuid32", 209, 3, "i:ppp "), + new Syscall ("setresgid32", 210, 3, "i:iii "), + new Syscall ("getresgid32", 211, 3, "i:ppp "), + new Syscall ("chown32", 212, 3, "i:sii "), + new Syscall ("setuid32", 213, 1, "i:i "), + new Syscall ("setgid32", 214, 1, "i:i "), + new Syscall ("setfsuid32", 215, 1, "i:i "), + new Syscall ("setfsgid32", 216, 1, "i:i "), + new Syscall ("pivot_root", 217, 2, "i:ss "), + new Syscall ("mincore", 218, 3, "i:anV "), + new Syscall ("madvise", 219, 3, "i:pii "), + new Syscall ("getdents64", 220, 3, "i:ipi "), + new Syscall ("fcntl64", 221, 3, "i:iip "), + new Syscall (222), + new Syscall (223), + new Syscall ("gettid", 224, 0), + new Syscall ("readahead", 225, 4, "i:ihli "), + new Syscall ("setxattr", 226), + new Syscall ("lsetxattr", 227), + new Syscall ("fsetxattr", 228), + new Syscall ("getxattr", 229), + new Syscall ("lgetxattr", 230), + new Syscall ("fgetxattr", 231), + new Syscall ("listxattr", 232), + new Syscall ("llistxattr", 233), + new Syscall ("flistxattr", 234), + new Syscall ("removexattr", 235), + new Syscall ("lremovexattr", 236), + new Syscall ("fremovexattr", 237), + new Syscall ("tkill", 238, 2, "i:ii "), + new Syscall ("sendfile64", 239, 4, "i:iipi "), + new Syscall ("futex", 240, 4, "i:piip "), + new Syscall ("sched_setaffinity", 241), + new Syscall ("sched_getaffinity", 242), + new Syscall ("set_thread_area", 243, 1, "i:p "), + new Syscall ("get_thread_area", 244, 1, "i:p "), + new Syscall ("io_setup", 245, 2, "i:ip "), + new Syscall ("io_destroy", 246, 1, "i:i "), + new Syscall ("io_getevents", 247, 5, "i:iiipp "), + new Syscall ("io_submit", 248, 3, "i:iip "), + new Syscall ("io_cancel", 249, 3, "i:ipp "), + new Syscall ("fadvise64", 250), + new Syscall (251), + new Syscall ("exit_group", 252, 1, " :i ", true), + new Syscall ("lookup_dcookie", 253), + new Syscall ("epoll_create", 254), + new Syscall ("epoll_ctl", 255), + new Syscall ("epoll_wait", 256), + new Syscall ("remap_file_pages", 257), + new Syscall ("set_tid_address", 258), + new Syscall ("timer_create", 259), + new Syscall ("timer_settime", 260), + new Syscall ("timer_gettime", 261), + new Syscall ("timer_getoverrun", 262), + new Syscall ("timer_delete", 263), + new Syscall ("clock_settime", 264), + new Syscall ("clock_gettime", 265), + new Syscall ("clock_getres", 266), + new Syscall ("clock_nanosleep", 267), + new Syscall ("statfs64", 268), + new Syscall ("fstatfs64", 269), + new Syscall ("tgkill", 270), + new Syscall ("utimes", 271), + new Syscall ("fadvise64_64", 272), + }; } Index: frysk-core/frysk/proc/Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Syscall.java,v retrieving revision 1.12 diff -u -r1.12 Syscall.java --- frysk-core/frysk/proc/Syscall.java 6 Sep 2006 15:28:32 -0000 1.12 +++ frysk-core/frysk/proc/Syscall.java 8 Sep 2006 10:55:50 -0000 @@ -96,24 +96,30 @@ { return number; } - - private void printStringArg (PrintWriter writer, - frysk.proc.Task task, - long addr) + /** Return true if this object equals the argument. */ + public boolean equals(Object other) { - if (addr == 0) - writer.print ("0x0"); - else { - writer.print ("\""); - StringBuffer x = new StringBuffer (); - task.memory.get (addr, 20, x); - if (x.length () == 20) - x.append ("..."); - x.append ("\""); - writer.print (x); - } + // Syscall objects are unique. + return this == other; } + private void printStringArg (PrintWriter writer, + frysk.proc.Task task, + long addr) + { + if (addr == 0) + writer.print ("0x0"); + else { + writer.print ("\""); + StringBuffer x = new StringBuffer (); + task.memory.get (addr, 20, x); + if (x.length () == 20) + x.append ("..."); + x.append ("\""); + writer.print (x); + } + } + /** * Print a textual representation of a system call. * @param writer where to print the representation @@ -212,295 +218,20 @@ return writer; } - /** - * Given a system call's number, this will return the corresponding - * Syscall object. Note that system call numbers are platform - * dependent. - * XXX: Eventually this will be moved down to Linux, or even - * further. - * @param num the number of the system call - */ - public static Syscall syscallByNum (int num) - { - if(num >= syscallList.length || num < 0){ - return new Syscall("UKNOWN SYSCALL", num); - } - return syscallList[num]; - } - - private static Syscall[] syscallList = { - new Syscall (0), - new Syscall ("exit", 1, 1), - new Syscall ("fork", 2, 0, "i: "), - new Syscall ("read", 3, 3, "i:ibn "), - new Syscall ("write", 4, 3, "i:ibn "), - new Syscall ("open", 5, 3, "i:siv "), - new Syscall ("close", 6, 1, "i:i "), - new Syscall ("waitpid", 7, 3, "i:ipi "), - new Syscall ("creat", 8, 2, "i:sv"), - new Syscall ("link", 9, 2, "i:ss "), - new Syscall ("unlink", 10, 1, "i:s "), - new Syscall ("execve", 11, 3, "i:ppp "), - new Syscall ("chdir", 12, 1, "i:s "), - new Syscall ("time", 13, 1, "i:P "), - new Syscall ("sys_mknod", 14, 3, "i:sii "), - new Syscall ("chmod", 15, 2, "i:si "), - new Syscall ("lchown", 16, 3, "i:sii "), - new Syscall ("break", 17), - new Syscall ("old_stat", 18, 3, "i:pp "), - new Syscall ("lseek", 19, 3, "i:iii "), - new Syscall ("getpid", 20, 0, "i: "), - new Syscall ("mount", 21, 5, "i:sssip "), - new Syscall ("umount", 22, 1, "i:s "), - new Syscall ("setuid", 23, 1, "i:i "), - new Syscall ("getuid", 24, 0, "i: "), - new Syscall ("stime", 25, 1, "i:p "), - new Syscall ("ptrace", 26, 4, "i:iiii "), - new Syscall ("alarm", 27, 1, "i:i "), - new Syscall ("old_fstat", 28, 2, "i:ip "), - new Syscall ("pause", 29, 0, "i: "), - new Syscall ("utime", 30, 2, "i:sP "), - new Syscall ("stty", 31), - new Syscall ("gtty", 32), - new Syscall ("access", 33, 2, "i:si "), - new Syscall ("nice", 34, 1, "i:i "), - new Syscall ("ftime", 35, 1, "i:p "), - new Syscall ("sync", 36, 0, "i: "), - new Syscall ("kill", 37, 2, "i:ii "), - new Syscall ("rename", 38, 2, "i:ss "), - new Syscall ("mkdir", 39, 2, "i:si "), - new Syscall ("rmdir", 40, 1, "i:s "), - new Syscall ("dup", 41, 1, "i:i "), - new Syscall ("pipe", 42, 1, "i:f "), - new Syscall ("times", 43, 1, "i:p "), - new Syscall ("prof", 44), - new Syscall ("brk", 45, 1, "i:p "), - new Syscall ("setgid", 46, 1, "i:i "), - new Syscall ("getgid", 47, 0, "i: "), - new Syscall ("signal", 48, 2, "i:ii "), - new Syscall ("geteuid", 49, 0, "i: "), - new Syscall ("getegid", 50, 0, "i: "), - new Syscall ("acct", 51, 1, "i:S "), - new Syscall ("umount2", 52, 2, "i:si "), - new Syscall ("lock", 53), - new Syscall ("ioctl", 54, 3, "i:iiI "), - new Syscall ("fcntl", 55, 3, "i:iiF "), - new Syscall ("mpx", 56), - new Syscall ("setpgid", 57, 2, "i:ii "), - new Syscall ("ulimit", 58, 2, "i:ii "), - new Syscall ("oldolduname", 59), - new Syscall ("umask", 60, 1, "i:i "), - new Syscall ("chroot", 61, 1, "i:s "), - new Syscall ("ustat", 62, 2, "i:ip "), - new Syscall ("dup2", 63, 2, "i:ii "), - new Syscall ("getppid", 64, 0, "i: "), - new Syscall ("getpgrp", 65, 0, "i: "), - new Syscall ("setsid", 66, 0, "i: "), - new Syscall ("sigaction", 67, 3, "i:ipp "), - new Syscall ("sgetmask", 68), - new Syscall ("ssetmask", 69), - new Syscall ("setreuid", 70, 2, "i:ii "), - new Syscall ("setregid", 71, 2, "i:ii "), - new Syscall ("sigsuspend", 72, 1, "i:p "), - new Syscall ("sigpending", 73, 1, "i:p "), - new Syscall ("sethostname", 74, 2, "i:pi "), - new Syscall ("setrlimit", 75, 2, "i:ip "), - new Syscall ("getrlimit", 76, 2, "i:ip "), - new Syscall ("getrusage", 77, 2, "i:ip "), - new Syscall ("gettimeofday", 78, 2, "i:PP "), - new Syscall ("settimeofday", 79, 2, "i:PP "), - new Syscall ("getgroups", 80, 2, "i:ip "), - new Syscall ("setgroups", 81, 2, "i:ip "), - new Syscall ("select", 82, 5, "i:iPPPP "), - new Syscall ("symlink", 83, 2, "i:ss "), - new Syscall ("oldlstat", 84, 2, "i:pp "), - new Syscall ("readlink", 85, 3, "i:spi "), - new Syscall ("uselib", 86, 1, "i:s "), - new Syscall ("swapon", 87, 2, "i:si "), - new Syscall ("reboot", 88, 1, "i:i "), - new Syscall (89), - new Syscall ("mmap", 90, 6, "b:aniiii "), - new Syscall ("munmap", 91, 2, "i:ai "), - new Syscall ("truncate", 92, 2, "i:si "), - new Syscall ("ftruncate", 93, 2, "i:ii "), - new Syscall ("fchmod", 94, 2, "i:ii "), - new Syscall ("fchown", 95, 3, "i:iii "), - new Syscall ("getpriority", 96, 2, "i:ii "), - new Syscall ("setpriority", 97, 3, "i:iii "), - new Syscall ("profil", 98, 4, "i:piii "), - new Syscall ("statfs", 99, 2, "i:sp "), - new Syscall ("fstatfs", 100, 2, "i:ip "), - new Syscall ("ioperm", 101, 3, "i:iii "), - new Syscall ("socketcall", 102, 2, "i:ip "), - new Syscall ("klogctl", 103, 3, "i:isi "), - new Syscall ("setitimer", 104, 3, "i:ipp "), - new Syscall ("getitimer", 105, 2, "i:ip "), - new Syscall ("sys_stat", 106, 2, "i:sp "), - new Syscall ("sys_lstat", 107, 2, "i:sp "), - new Syscall ("sys_fstat", 108, 2, "i:ip "), - new Syscall ("old_uname", 109, 1, "i:p "), - new Syscall ("iopl", 110, 1, "i:i "), - new Syscall ("vhangup", 111, 1, "i:i "), - new Syscall ("idle", 112, 0, "i: "), - new Syscall (113), - new Syscall ("wait4", 114, 4, "i:iWiP "), - new Syscall ("swapoff", 115, 1, "i:s "), - new Syscall ("sysinfo", 116, 1, "i:p "), - new Syscall ("ipc", 117, 6, "i:iiiipi "), - new Syscall ("fsync", 118, 1, "i:i "), - new Syscall ("sigreturn", 119), - new Syscall ("clone", 120, 2, "i:ip "), - new Syscall ("setdomain", 121, 2, "i:si "), - new Syscall ("uname", 122, 1, "i:p "), - new Syscall ("modify_ldt", 123, 3, "i:ipi "), - new Syscall ("adjtimex", 124, 1, "i:p "), - new Syscall ("mprotect", 125, 3, "i:aii "), - new Syscall ("sigprocmask", 126, 3, "i:ipp "), - new Syscall ("create_module", 127, 3), - new Syscall ("init_module", 128, 5), - new Syscall ("delete_module", 129, 3), - new Syscall ("get_kernel_syms", 130, 1, "i:p "), - new Syscall ("quotactl", 131, 4, "i:isip "), - new Syscall ("getpgid", 132, 1, "i:i "), - new Syscall ("fchdir", 133, 1, "i:i "), - new Syscall ("bdflush", 134, 2, "i:ii "), - new Syscall ("sysfs", 135, 1, "i:i "), - new Syscall ("personality", 136, 1, "i:i "), - new Syscall ("afs_syscall", 137), - new Syscall ("setfsuid", 138, 1, "i:i "), - new Syscall ("setfsgid", 139, 1, "i:i "), - new Syscall ("llseek", 140, 5, "i:iuupi "), - new Syscall ("s_getdents", 141, 3, "i:ipi "), - new Syscall ("select", 142, 5, "i:iPPPP "), - new Syscall ("flock", 143, 2, "i:ii "), - new Syscall ("msync", 144, 3, "i:aii "), - new Syscall ("readv", 145, 3, "i:ipi "), - new Syscall ("writev", 146, 3, "i:ipi "), - new Syscall ("getsid", 147, 1, "i:i "), - new Syscall ("fdatasync", 148, 1, "i:i "), - new Syscall ("sysctl", 149, 1, "i:p "), - new Syscall ("mlock", 150, 2, "i:bn "), - new Syscall ("munlock", 151, 2, "i:ai "), - new Syscall ("mlockall", 152, 1, "i:i "), - new Syscall ("munlockall", 153, 0, "i: "), - new Syscall ("sched_setp", 154, 2, "i:ip "), - new Syscall ("sched_getp", 155, 2, "i:ip "), - new Syscall ("sched_sets", 156, 3, "i:iip "), - new Syscall ("sched_gets", 157, 1, "i:i "), - new Syscall ("sched_yield", 158, 0, "i: "), - new Syscall ("sched_primax", 159, 1, "i:i "), - new Syscall ("sched_primin", 160, 1, "i:i "), - new Syscall ("sched_rr_gi", 161, 2, "i:ip "), - new Syscall ("nanosleep", 162, 2, "i:pp "), - new Syscall ("mremap", 163, 4, "b:aini "), - new Syscall ("setresuid", 164, 3, "i:iii "), - new Syscall ("getresuid", 165, 3, "i:ppp "), - new Syscall ("vm86", 166, 1, "i:p "), - new Syscall ("query_module", 167, 5, "i:sipip "), - new Syscall ("poll", 168, 3, "i:pii "), - new Syscall ("nfsservctl", 169, 3, "i:ipp "), - new Syscall ("setresgid", 170, 3, "i:iii "), - new Syscall ("getresgid", 171, 3, "i:ppp "), - new Syscall ("prctl", 172, 5, "i:iiiii "), - new Syscall ("rt_sigreturn", 173), - new Syscall ("rt_sigaction", 174), - new Syscall ("rt_sigprocmask", 175), - new Syscall ("rt_sigpending", 176), - new Syscall ("rt_sigtimedwait", 177), - new Syscall ("rt_sigqueueinfo", 178), - new Syscall ("rt_sigsuspend", 179), - new Syscall ("pread64", 180), - new Syscall ("pwrite64", 181), - new Syscall ("chown", 182, 3, "i:sii "), - new Syscall ("getcwd", 183, 2, "i:bi "), - new Syscall ("capget", 184, 2, "i:pp "), - new Syscall ("capset", 185, 2, "i:pp "), - new Syscall ("sigaltstack", 186, 2, "i:PP "), - new Syscall ("sendfile", 187, 4, "i:iipi "), - new Syscall ("getpmsg", 188), - new Syscall ("putpmsg", 189), - new Syscall ("vfork", 190, 0, "i: "), - new Syscall ("ugetrlimit", 191), - new Syscall ("mmap", 192, 6, "b:aniiii "), - new Syscall ("truncate64", 193, 3, "i:shl "), - new Syscall ("ftruncate64", 194, 3, "i:ihl "), - new Syscall ("stat64", 195, 2, "i:sp "), - new Syscall ("lstat64", 196, 2, "i:sp "), - new Syscall ("fstat64", 197, 2, "i:ip "), - new Syscall ("lchown32", 198, 3, "i:sii "), - new Syscall ("getuid32", 199), - new Syscall ("getgid32", 200), - new Syscall ("geteuid32", 201), - new Syscall ("getegid32", 202), - new Syscall ("setreuid32", 203, 2, "i:ii "), - new Syscall ("setregid32", 204, 2, "i:ii "), - new Syscall ("getgroups32", 205, 2, "i:ip "), - new Syscall ("setgroups32", 206, 2, "i:ip "), - new Syscall ("fchown32", 207, 3, "i:iii "), - new Syscall ("setresuid32", 208, 3, "i:iii "), - new Syscall ("getresuid32", 209, 3, "i:ppp "), - new Syscall ("setresgid32", 210, 3, "i:iii "), - new Syscall ("getresgid32", 211, 3, "i:ppp "), - new Syscall ("chown32", 212, 3, "i:sii "), - new Syscall ("setuid32", 213, 1, "i:i "), - new Syscall ("setgid32", 214, 1, "i:i "), - new Syscall ("setfsuid32", 215, 1, "i:i "), - new Syscall ("setfsgid32", 216, 1, "i:i "), - new Syscall ("pivot_root", 217, 2, "i:ss "), - new Syscall ("mincore", 218, 3, "i:anV "), - new Syscall ("madvise", 219, 3, "i:pii "), - new Syscall ("getdents64", 220, 3, "i:ipi "), - new Syscall ("fcntl64", 221, 3, "i:iip "), - new Syscall (222), - new Syscall (223), - new Syscall ("gettid", 224, 0), - new Syscall ("readahead", 225, 4, "i:ihli "), - new Syscall ("setxattr", 226), - new Syscall ("lsetxattr", 227), - new Syscall ("fsetxattr", 228), - new Syscall ("getxattr", 229), - new Syscall ("lgetxattr", 230), - new Syscall ("fgetxattr", 231), - new Syscall ("listxattr", 232), - new Syscall ("llistxattr", 233), - new Syscall ("flistxattr", 234), - new Syscall ("removexattr", 235), - new Syscall ("lremovexattr", 236), - new Syscall ("fremovexattr", 237), - new Syscall ("tkill", 238, 2, "i:ii "), - new Syscall ("sendfile64", 239, 4, "i:iipi "), - new Syscall ("futex", 240, 4, "i:piip "), - new Syscall ("sched_setaffinity", 241), - new Syscall ("sched_getaffinity", 242), - new Syscall ("set_thread_area", 243, 1, "i:p "), - new Syscall ("get_thread_area", 244, 1, "i:p "), - new Syscall ("io_setup", 245, 2, "i:ip "), - new Syscall ("io_destroy", 246, 1, "i:i "), - new Syscall ("io_getevents", 247, 5, "i:iiipp "), - new Syscall ("io_submit", 248, 3, "i:iip "), - new Syscall ("io_cancel", 249, 3, "i:ipp "), - new Syscall ("fadvise64", 250), - new Syscall (251), - new Syscall ("exit_group", 252, 1, " :i ", true), - new Syscall ("lookup_dcookie", 253), - new Syscall ("epoll_create", 254), - new Syscall ("epoll_ctl", 255), - new Syscall ("epoll_wait", 256), - new Syscall ("remap_file_pages", 257), - new Syscall ("set_tid_address", 258), - new Syscall ("timer_create", 259), - new Syscall ("timer_settime", 260), - new Syscall ("timer_gettime", 261), - new Syscall ("timer_getoverrun", 262), - new Syscall ("timer_delete", 263), - new Syscall ("clock_settime", 264), - new Syscall ("clock_gettime", 265), - new Syscall ("clock_getres", 266), - new Syscall ("clock_nanosleep", 267), - new Syscall ("statfs64", 268), - new Syscall ("fstatfs64", 269), - new Syscall ("tgkill", 270), - new Syscall ("utimes", 271), - new Syscall ("fadvise64_64", 272), - }; + /** + * Given a system call's name, this will return the corresponding + * Syscall object. If no predefined system call with that name + * is available, this will return null. + * @param name the name of the system call + * @param syscallList system calls list + * @return the Syscall object, or null + * @throws NullPointerException if name is null + */ + public static Syscall syscallByName (String name, Syscall[] syscallList) + { + for (int i = 0; i < LinuxIa32.syscallList.length; ++i) + if (name.equals(syscallList[i].name)) + return syscallList[i]; + return null; + } } Index: frysk-core/frysk/proc/SyscallEventInfo.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/SyscallEventInfo.java,v retrieving revision 1.4 diff -u -r1.4 SyscallEventInfo.java --- frysk-core/frysk/proc/SyscallEventInfo.java 11 Jul 2006 21:25:25 -0000 1.4 +++ frysk-core/frysk/proc/SyscallEventInfo.java 8 Sep 2006 10:55:50 -0000 @@ -38,17 +38,181 @@ // exception. package frysk.proc; +import java.util.HashMap; /** * An object that retrieves syscall info from a task. Used in combination * with Syscall and a Task object to retrieve information. */ public abstract class SyscallEventInfo { - public final static int ENTER = 0; - public final static int EXIT = 1; - public final static int UNKNOWN = -1; - - public abstract int number (Task task); - public abstract long arg (Task task, int n); - public abstract long returnCode (Task task); + public final static int ENTER = 0; + public final static int EXIT = 1; + public final static int UNKNOWN = -1; + + public abstract int number (Task task); + public abstract long arg (Task task, int n); + public abstract long returnCode (Task task); + + + public Syscall getSyscall (Task task) + { + int number = this.number (task); + return syscallByNum (number, task); + } + + private static Syscall[] getSyscallList (Task task) + { + Syscall[] syscallList; + String isaName = new String(); + + try + { + isaName = task.getIsa().toString(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get the name of isa"); + } + + if (isaName.equals("ia32")) + { + syscallList = LinuxIa32.syscallList; + } + else if (isaName.equals("x86-64")) + { + syscallList = LinuxEMT64.syscallList; + } + else if (isaName.equals("ppc64")) + { + syscallList = LinuxPPC64.syscallList; + } + else + { + syscallList = LinuxPPC.syscallList; + } + + return syscallList; + } + + private static HashMap getUnknownSyscalls (Task task) + { + HashMap unknownSyscalls; + String isaName = new String(); + + try + { + isaName = task.getIsa().toString(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get the name of isa"); + } + + if (isaName.equals("ia32")) + { + unknownSyscalls = LinuxIa32.unknownSyscalls; + } + else if (isaName.equals("x86-64")) + { + unknownSyscalls = LinuxEMT64.unknownSyscalls; + } + else if (isaName.equals("ppc64")) + { + unknownSyscalls = LinuxPPC64.unknownSyscalls; + } + else + { + unknownSyscalls = LinuxPPC.unknownSyscalls; + } + return unknownSyscalls; + } + + /** + * Given a system call's number, this will return the corresponding + * Syscall object. Note that system call numbers are platform + * dependent. This will return a Syscall object in all cases; if + * there is no predefined system call with the given number, a unique + * "unknown" system call with the indicated number will be saved in + * unknownSyscalls. + * @param num the number of the system call + * @param task the current task + * @return the Syscall object + */ + public static Syscall syscallByNum (int num, Task task) + { + Syscall[] syscallList; + HashMap unknownSyscalls; + + syscallList = getSyscallList (task); + unknownSyscalls = getUnknownSyscalls (task); + + if (num < 0) + { + throw new RuntimeException ("Negative Syscall Number:" + + Integer.toString(num)); + } + else if (num >= syscallList.length) + { + synchronized (SyscallEventInfo.class) + { + Integer key = new Integer(num); + if (unknownSyscalls == null) + unknownSyscalls = new HashMap(); + else if (unknownSyscalls.containsKey(key)) + return (Syscall) unknownSyscalls.get(key); + + Syscall result = new Syscall("UNKNOWN SYSCALL " + Integer.toString(num), num); + unknownSyscalls.put(key, result); + + return result; + } + } + else + { + return syscallList[num]; + } + } + + /** + * Given a system call's name, this will return the corresponding + * Syscall object. If no predefined system call with that name + * is available, this will return null. + * @param name the name of the system call + * @param task the cuurent task + * @return the Syscall object, or null + * @throws NullPointerException if name is null + */ + public static Syscall syscallByName (String name, Task task) + { + Syscall syscall; + String isaName = new String(); + + try + { + isaName = task.getIsa().toString(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get the name of isa"); + } + + if (isaName.equals("ia32")) + { + syscall = Syscall.syscallByName (name, LinuxIa32.syscallList); + if (syscall != null) + return syscall; + + syscall = Syscall.syscallByName (name, LinuxIa32.socketSubcallList); + if (syscall != null) + return syscall; + + syscall = Syscall.syscallByName (name, LinuxIa32.ipcSubcallList); + if (syscall != null) + return syscall; + return null; + } + else + return Syscall.syscallByName (name, getSyscallList(task)); + + } } -------------- next part -------------- Index: frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java =================================================================== RCS file: /cvs/frysk/frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java,v retrieving revision 1.4 diff -u -r1.4 SysCallUtilyInfo.java --- frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java 6 Sep 2006 17:43:08 -0000 1.4 +++ frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java 8 Sep 2006 11:49:54 -0000 @@ -58,8 +58,7 @@ return ""; } - Syscall syscall = Syscall - .syscallByNum(syscallEventInfo.number(task)); + Syscall syscall = syscallEventInfo.getSyscall(task); enterCall = syscall.getName(); if (syscall.numArgs > 0) enterCall += " ("; @@ -119,7 +118,7 @@ return ""; } - Syscall syscall = Syscall.syscallByNum(syscallEventInfo.number(task)); + Syscall syscall = syscallEventInfo.getSyscall(task); returnCall += syscall.getName() + " returns with value "; From mcvet@redhat.com Fri Sep 8 14:08:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 08 Sep 2006 14:08:00 -0000 Subject: Stacktraces in the SourceWindow In-Reply-To: <1157718042.5773.108.camel@dijkstra.wildebeest.org> References: <1157667020.2031.24.camel@towel.toronto.redhat.com> <45009C81.5040404@redhat.com> <1157718042.5773.108.camel@dijkstra.wildebeest.org> Message-ID: <1157724514.2031.48.camel@towel.toronto.redhat.com> On Fri, 2006-09-08 at 14:20 +0200, Mark Wielaard wrote: > On Thu, 2006-09-07 at 17:26 -0500, Phil Muldoon wrote: > > > > > > If we could store the stack-trace saying during a syscall, we could > > print to the log window what function the thread was in when the syscall > > entered, as well as all the usual information. We could code up a GTK > > method to make the function click-able in the monitor log, and then it > > would open a source window showing the code context of where the syscall > > happened. If we stored the whole stacktrace for each log event in the > > ui, we could even show the user how it got to that point in the code. We > > 'd have to have a circular buffer though, and eventually stack traces > > would be discarded as memory demands dictate. > > > > Awesome! I expect this information to be useful all over the monitor; as you said this can be plugged into syscall observers, we could create new Filters and Actions, and as discussed last night, properly update entry function information in the thread view. But as Elena noticed (the line #0 thing) there are still plenty of bugs yet. And tons of work to do in the SourceWindow and the stack-related classes it uses. > > Nice. That does probably slow down programs we are tracing even more > though. So it should probably not be on by default. You also need to > think about libraries that might be loaded/unloaded dynamically. How > would that interact with the stacktraces? It means that at a later time > the original stacktrace might not be valid, or that it might not be > possible to find the actual code back. > You're absolutely right - currently the stack tracing is a fairly expensive operation and for the example trace I showed yesterday with the seven stack frames (the bottom two belong to glibc), there were 45 ptrace calls routed through our PtraceThread (*grumble*). So when this information is used in the monitor we'll just have to figure out a way to do it with minimal impact on tracing and monitor operation in general. We'll obviously want to do as few calls as possible to the unwinder, and store as much information as we can. You raise a another good point though - we'll have to figure out a way to keep the stack trace current. Ugh. > Another bluesky idea. Seeing the stack trace addresses I thought it > would be nice if anywhere in the gui where you have a code address you > could simple add a CodeObserver by right-clicking, or some other > mechanism to the current Task or the whole Process. That way you can > quickly start with breakpointing in the gui and don't have to do any > code/line/address conversions (yet). > Cool! Sounds like we'd better start working up some enhancement bugs =) - Mike From mcvet@redhat.com Fri Sep 8 17:08:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 08 Sep 2006 17:08:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <17662.55814.184895.938951@localhost.redhat.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FE5749.90509@redhat.com> <1157533819.2996.13.camel@dijkstra.wildebeest.org> <1157552322.2031.8.camel@towel.toronto.redhat.com> <1157552805.2996.50.camel@dijkstra.wildebeest.org> <17662.55814.184895.938951@localhost.redhat.com> Message-ID: <1157735333.2031.59.camel@towel.toronto.redhat.com> On Wed, 2006-09-06 at 10:24 -0400, Elena Zannoni wrote: > Mark Wielaard writes: > > Hi, > > > > On Wed, 2006-09-06 at 10:18 -0400, Mike Cvet wrote: > > > Since the ptrace thread was essentially just a workaround for #2595 to > > > address problems with ptrace, I'm not sure if it would be a good idea to > > > have more dependencies on this thread if we can avoid it. Hopefully this > > > thread will disappear altogether in the future via utrace. > > > > > > That being said, I'll take a working solution right now if it means work > > > can get done immediately on stacktraces, as long as it'll get fixed up > > > properly later. > > > > When do we expect to start depending on and using utrace? Is there any > > other solution except using the ptrace calls of libunwind to get remote > > stacktraces working for now? > > Remember that we will have to keep frysk working on older kernels that > have the old ptrace (RHEL4, fc5), and so we will not delete that hack > any time soon. Well it appears all the callbacks were set up properly to route through the PtraceThread anyway - so this is a good thing. I just spoke with Andrew and I'll be checking in Alex's changes this afternoon. The bugs that Tom has seen and others have observed are still present, but since the remote unwinding is actually /doing/ somewhat correct, it'll go in now and others can take a look at it if they like. - Mike From npremji@redhat.com Fri Sep 8 17:42:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Fri, 08 Sep 2006 17:42:00 -0000 Subject: Eventviewer Mouse Edge scrolling Message-ID: <1157737352.2007.3.camel@tow.toronto.redhat.com> It's committed, check it out. To use, drag your mouse to the edge (or rather near edge) of the main drawing area, if it is possible to scroll in that direction, it will be scrolled. Enjoy. From cagney@redhat.com Fri Sep 8 20:30:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 08 Sep 2006 20:30:00 -0000 Subject: ftrace In-Reply-To: References: <4500807A.8070706@redhat.com> Message-ID: <4501D2CA.7060206@redhat.com> Tom Tromey wrote: > Andrew> The main issues with adopting another getopt alternative are: > that it > Andrew> be sane; that we only have one (we're not in the business of > Andrew> babysitting multiple redundant packages - which would mean eliminating > Andrew> jargs); and its license be workable. > > * Sane... well, I think so :-) > * Eliminating jargs... at your discretion of course > * License... GPL+E like the rest of Classpath > > Tom > In that case "done" :-) Now for your other question on this thread. Andrew From cagney@redhat.com Fri Sep 8 20:32:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 08 Sep 2006 20:32:00 -0000 Subject: getLogger parameter In-Reply-To: <1157716937.5773.99.camel@dijkstra.wildebeest.org> References: <44E36E7D.60000@redhat.com> <1157554992.2996.54.camel@dijkstra.wildebeest.org> <45008556.7080103@redhat.com> <1157716937.5773.99.camel@dijkstra.wildebeest.org> Message-ID: <4501D36C.2090803@redhat.com> Mark Wielaard wrote: > > But how does it work? How do you get log output for say Task and > TaskState when using TestRunner now? > > I reverted to using System.err.println() for now, but at times it would > be nice to get the log output as before this change. > > Unfortunatly: ./TestRunner -c FINE since it isn't working then we've a bug; somewhere. Can someone that uses ~/.frysk/properties post what they are using, that might give us a clue as to the differences. Andrew From pmuldoon@redhat.com Fri Sep 8 20:55:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 08 Sep 2006 20:55:00 -0000 Subject: getLogger parameter In-Reply-To: <4501D36C.2090803@redhat.com> References: <44E36E7D.60000@redhat.com> <1157554992.2996.54.camel@dijkstra.wildebeest.org> <45008556.7080103@redhat.com> <1157716937.5773.99.camel@dijkstra.wildebeest.org> <4501D36C.2090803@redhat.com> Message-ID: <4501D8CE.9040800@redhat.com> > Unfortunatly: > ./TestRunner -c FINE > since it isn't working then we've a bug; somewhere. > > Can someone that uses ~/.frysk/properties post what they are using, > that might give us a clue as to the differences. > > Andrew > Contents of ~/.frysk/logging.properties for me is: java.util.logging.ConsoleHandler.level = OFF java.util.logging.FileHandler.level = FINE frysk.core.debug.WindowHandler.level = OFF A side point, this is read by: private static void setupCoreLogging() in frysk-gui.frysk.gui.Gui And it sets-up the the levels and log managers. Maybe look in there for a point to point comparison with how TestRunner sets things up? Regards Phil From tromey@redhat.com Fri Sep 8 23:57:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Fri, 08 Sep 2006 23:57:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <20060908125442.GA1364@GreenHouse.cn.ibm.com> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: I generally like this patch. I've got a few comments about it. Yao> 1. Move syscallList from Syscall.java to Linux.java. Sounds good. Yao> It would take me a whole day to look up system call numbers for Yao> different architectures. :) Automation would be good... too bad there's no way to do this dynamically. Yao> b) getSyscallList() and getUnknownSyscalls() return the Yao> architecture-dependent syscallList and unknown syscall hash map from Yao> Linux.java Ok, I think I didn't understand something important (and fundamental and obvious :-) about frysk. If it is possible to request Syscall objects from different ISAs in the same frysk process, then I think either syscallByNum and syscallByName should be methods on the ISA object, or they should take the ISA as an argument. This makes the strace '-e' argument look a little weird now too. If the user 'ftrace's all 'open' calls, should it be every open call from every ISA? I suppose we could try to enumerate every ISA supported by the host platform... Yao> public interface Isa Yao> { Yao> + Yao> + String toString(); Not really necessary (since Object has toString) but I suppose it could be nice if you plan to document it differently. Yao> + if (isaName.equals("ia32")) Yao> + { Yao> + syscallList = LinuxIa32.syscallList; Yao> + } Yao> + else if (isaName.equals("x86-64")) Yao> + { Yao> + syscallList = LinuxEMT64.syscallList; Yao> + } Yao> + else if (isaName.equals("ppc64")) Yao> + { Yao> + syscallList = LinuxPPC64.syscallList; Yao> + } Yao> + else Yao> + { Yao> + syscallList = LinuxPPC.syscallList; Yao> + } Code like this is "anti-OO" -- every time you add an ISA you will have to find every such switch and add a case. It is much better, IMO, to add a method to the ISA to return the desired attribute. Yao> + public static Syscall syscallByName (String name, Task task) [...] Yao> + if (isaName.equals("ia32")) Yao> + { Yao> + syscall = Syscall.syscallByName (name, LinuxIa32.syscallList); Yao> + if (syscall != null) Yao> + return syscall; Likewise, this could simply delegate to the ISA and the ISA-specific oddities could be hidden there, where they (again IMO) belong. Tom From tromey@redhat.com Sat Sep 9 00:16:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Sat, 09 Sep 2006 00:16:00 -0000 Subject: Sign extend 32-bit register values and Bug #3055 In-Reply-To: <20060906040250.GE13314@GreenHouse.cn.ibm.com> References: <20060906040250.GE13314@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: Yao> long in java is 64-bit, and 32-bit register value should be sign Yao> extended. We override Register.get() in Isa to do sign extension for Yao> Ia32 and PPC(32-bit platforms). The idea seems good to me. It would be good if SyscallEventInfo.returnCode were documented to mention that sign extension happens. I suppose it is odd to sign extend addresses. Tom From aoliva@redhat.com Sun Sep 10 08:10:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Sun, 10 Sep 2006 08:10:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Alexandre Oliva's message of "Wed, 06 Sep 2006 05:00:52 -0300") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 6, 2006, Alexandre Oliva wrote: > On Sep 5, 2006, Tom Tromey wrote: > What I don't know is why it's skipping the main() frame. Tricky. AFAICT libunwind won't fetch the unwind info from the vdso, which is only available from the running process, using ptrace. So it makes some conservative assumptions to unwind the stack and loses. Adding more stack frames gives it more stack space to sync up, and then it does display function names correctly, but it still fails to print file/line numbers. I'm yet to figure out why. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From tromey@redhat.com Sun Sep 10 17:35:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Sun, 10 Sep 2006 17:35:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: >>>>> "Alexandre" == Alexandre Oliva writes: Alexandre> Adding more stack frames gives it more stack space to sync Alexandre> up, and then it does display function names correctly, but Alexandre> it still fails to print file/line numbers. I'm yet to Alexandre> figure out why. Adding more frames makes more of it work for me: opsy. ./install/bin/fdtrace ./Closer bad close() call at: at 0x45bdc402 at 0x80483ba in function: doit2 (/home/tromey/gnu/frysk/CC.c:11) at 0x80483dd in function: main at 0x45c0f724 at 0x8048301 I've appended the program. The doit2 frame is nearly correct -- the line number is off by 2. The doit frame itself doesn't print any info, and the main frame only prints the function name. This is the output including my patch to add StackFrame.toString, which omits info that it can't find. Tom #include #include void doit() { close(73); close(74); } void doit2() { doit(); } int main() { doit2(); return 0; } From qiyaoltc@cn.ibm.com Mon Sep 11 02:27:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 11 Sep 2006 02:27:00 -0000 Subject: [patch ping] TestModify & Disassembler Message-ID: <20060911022704.GB19394@GreenHouse.cn.ibm.com> Could anyone here have a look these two patches? Thanks! http://sources.redhat.com/ml/frysk/2006-q3/msg00373.html Written by Yong to merge TestModify together. http://sources.redhat.com/ml/frysk/2006-q3/msg00371.html Written by Yao to rewrite Disassembler and enable TestOpcodes for PPC64. -- Yao Qi From woodzltc@cn.ibm.com Mon Sep 11 04:18:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Mon, 11 Sep 2006 04:18:00 -0000 Subject: is UNW_REMOTE_ONLY in-dispensable fro Frysk Message-ID: <4504E379.1010400@cn.ibm.com> UNW_REMOTE_ONLY is causing some trouble for us to work on ppc64 porting of libunwind. I am thinking over if it is in-dispensable for Frysk. If it is not, could we remove this option from configure.ac? Regards - Wu Zhou From qiyaoltc@cn.ibm.com Mon Sep 11 05:10:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 11 Sep 2006 05:10:00 -0000 Subject: Patch: StackFrame.toString() In-Reply-To: References: Message-ID: <20060911051051.GC19394@GreenHouse.cn.ibm.com> On Tue, Sep 05, 2006 at 04:34:26PM -0600, Tom Tromey wrote: > I thought it would be handy if StackFrame had a toString method that > did something sensible. Patch appended. > > BTW it would be nice if the boundary cases for StackFrame accessor > methods were documented -- this toString is written assuming: > > * getMethodName could return null or the empty string if it can't get > the function's name (and btw the name "getMethodName" is kind of a > misnomer IMO) getMethodName is only return methodName, which is set by unw_get_proc_name() in StackFrame::initialize(). In Gget_proc_name.c:get_proc_name(), we could know methodName is set to empty string if function's name could not be got. So your assumption to getMethodName is right. > > * getSourceFile will return null if the source file name can't be > found Your assumption is right too. :-) > > * getLineNumber will return 0 if the line number is not known getLineNumber is a java binding of dwfl_lineinfo, and LineNumber is valid if the return value of dwfl_lineinfo is not empty. Some codes could be modified to meet your document, jint lib::dw::DwflLine::dwfl_lineinfo_linenum(){ int lineNum; if (::dwfl_lineinfo(DWFL_LINE_POINTER, NULL, &lineNum, NULL,NULL,NULL)) return (jint) lineNum; else return 0; } > > I'm happy to document these accessors if someone would confirm that > this is the intended interpretation. This patch is fine to me. > > + public String toString () > + { > + StringBuffer builder = new StringBuffer("at 0x"); > + builder.append(Long.toHexString(getAddress())); > + String mn = getMethodName(); > + if (mn != null && ! "".equals(mn)) Just one question for my curiosity, Is there any difference between ""equals(mn) and mn.equals("")? -- Yao Qi From qiyaoltc@cn.ibm.com Mon Sep 11 07:37:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 11 Sep 2006 07:37:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> Message-ID: <20060911073724.GD19394@GreenHouse.cn.ibm.com> On Fri, Sep 08, 2006 at 05:51:25PM -0600, Tom Tromey wrote: > >>>>> "Yao" == Yao Qi writes: > > I generally like this patch. I've got a few comments about it. > > Yao> It would take me a whole day to look up system call numbers for > Yao> different architectures. :) > > Automation would be good... too bad there's no way to do this > dynamically. Syscall spec of the same name is the same on all the architectures, so most of the work is copy-paste. Luckily, this work is once-done-for-ever. :) > > Yao> b) getSyscallList() and getUnknownSyscalls() return the > Yao> architecture-dependent syscallList and unknown syscall hash map from > Yao> Linux.java > > Ok, I think I didn't understand something important (and fundamental > and obvious :-) about frysk. If it is possible to request Syscall > objects from different ISAs in the same frysk process, then I think > either syscallByNum and syscallByName should be methods on the ISA > object, or they should take the ISA as an argument. > syscallByNum and syscallByName in class SyscallEventInfo takes the task as an argument, and get ISA via task.getIsa(). syscallByNum and syscallByName in class SyscallEventInfo are interfaces to "users" outside system calls, and they could get information about syscall calls for a certain task. > This makes the strace '-e' argument look a little weird now too. If > the user 'ftrace's all 'open' calls, should it be every open call from > every ISA? I suppose we could try to enumerate every ISA supported by > the host platform... Actually, I have modified this patch for some times in order to support "ftrace -e", and "ftrace -e" makes some troubles to this design. :) If the user 'ftrace's all 'open' calls, frsk core (SyscallEventInfo.getSyscall(task))could detect the ISA type of task we currently ftraced, and *only* find syscall object in syscallList for this ISA type. This is to say, if we run "ftrace -e open ls" on our pc(x86), frysk core fork and execv "/bin/ls", and then get the ISA type(x86 here) of this task, and only find syscall object in LinuxIa32.syscallList. If a 32-bit program fork and exec a 64-bit program, the ISA type of this child task is 64-bit, and frysk core could find syscall object in LinuxEMT64(or LinuxPPC64).syscallList. > > Yao> public interface Isa > Yao> { > Yao> + > Yao> + String toString(); > > Not really necessary (since Object has toString) but I suppose it > could be nice if you plan to document it differently. I add this method in order to know what the current ISA is, and not it seems that it is not necessary since the following code is "anti-OO". > > Yao> + if (isaName.equals("ia32")) > Yao> + { > Yao> + syscallList = LinuxIa32.syscallList; > Yao> + } > Yao> + else if (isaName.equals("x86-64")) > Yao> + { > Yao> + syscallList = LinuxEMT64.syscallList; > Yao> + } > Yao> + else if (isaName.equals("ppc64")) > Yao> + { > Yao> + syscallList = LinuxPPC64.syscallList; > Yao> + } > Yao> + else > Yao> + { > Yao> + syscallList = LinuxPPC.syscallList; > Yao> + } > > Code like this is "anti-OO" -- every time you add an ISA you will have > to find every such switch and add a case. > > It is much better, IMO, to add a method to the ISA to return the > desired attribute. That is a good idea. System call is an OS+ISA specific thing, so I do not put them in ISA at first. Currently, frysk is only supported on Linux, and assume "OS" as Linux, and I could put getSyscallList() or syscallByNum() in ISA. > > Yao> + public static Syscall syscallByName (String name, Task task) > [...] > Yao> + if (isaName.equals("ia32")) > Yao> + { > Yao> + syscall = Syscall.syscallByName (name, LinuxIa32.syscallList); > Yao> + if (syscall != null) > Yao> + return syscall; > > Likewise, this could simply delegate to the ISA and the ISA-specific > oddities could be hidden there, where they (again IMO) belong. -- Yao Qi From mark@klomp.org Mon Sep 11 09:30:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 11 Sep 2006 09:30:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <1157735333.2031.59.camel@towel.toronto.redhat.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FE5749.90509@redhat.com> <1157533819.2996.13.camel@dijkstra.wildebeest.org> <1157552322.2031.8.camel@towel.toronto.redhat.com> <1157552805.2996.50.camel@dijkstra.wildebeest.org> <17662.55814.184895.938951@localhost.redhat.com> <1157735333.2031.59.camel@towel.toronto.redhat.com> Message-ID: <1157967009.3067.8.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-09-08 at 13:08 -0400, Mike Cvet wrote: > The bugs that Tom has seen and others have observed are still present, > but since the remote unwinding is actually /doing/ somewhat correct, > it'll go in now and others can take a look at it if they like. It seems to be hard coded for x86 so the test fails for any other architecture. For now I have disabled it as follows: 2006-09-11 Mark Wielaard * tests/TestStackBacktrace.java (testBacktrace): Disabled when MachineType is not IA32. Also updated the bug report at http://sourceware.org/bugzilla/show_bug.cgi?id=2936 Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: TestStackBacktrace-disable.diff Type: text/x-patch Size: 1008 bytes Desc: not available URL: From mark@klomp.org Mon Sep 11 12:51:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 11 Sep 2006 12:51:00 -0000 Subject: Merged all running states Message-ID: <1157979072.3067.35.camel@dijkstra.wildebeest.org> Hi, This is the last TaskState state merging patch. It merges all running states into one Running class with four instances (running, inSyscallRunning, syscallRunning and inSyscallRunningTraced). The transitionToSyscallRunning and transitionOutOfSyscallRunning have been removed. 2006-09-11 Mark Wielaard * Task.java (syscallObservers): Made package private. * TaskState (transitionToSyscallRunning): Removed merged with Running. (transitionOutOfSyscallRunning): Likewise. (inSyscallRunningTraced): New state. This should also theoretically fix a bug that Phil was seeing. In the old setup transitionToSyscallRunning and transitionOutOfSyscallRunning would not handle all events, or new observers added while doing the transition. I was unable to replicate this issue myself though, so I don't have a real testcase. Phil, could you try your setup with this patch installed and see if it resolves your issue? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: four-running.diff Type: text/x-patch Size: 7503 bytes Desc: not available URL: From cagney@redhat.com Mon Sep 11 13:35:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 11 Sep 2006 13:35:00 -0000 Subject: is UNW_REMOTE_ONLY in-dispensable fro Frysk In-Reply-To: <4504E379.1010400@cn.ibm.com> References: <4504E379.1010400@cn.ibm.com> Message-ID: <45056609.7090007@redhat.com> Wu Zhou wrote: > UNW_REMOTE_ONLY is causing some trouble for us to work on ppc64 > porting of libunwind. I am thinking over if it is in-dispensable for > Frysk. I don't think it is in-dispensable, however, it is correct on principle - this code has no need to do native unwinding - and it lets us avoid a number of ongoing issues where the native-unwind defined symbols that clashed with libgcj. Rick and Adam can fill in the details. Perhaps something to discuss on the libunwind list? Andrew > > If it is not, could we remove this option from configure.ac? > > Regards > - Wu Zhou From cagney@redhat.com Mon Sep 11 14:00:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 11 Sep 2006 14:00:00 -0000 Subject: Sign extend 32-bit register values and Bug #3055 In-Reply-To: <20060906040250.GE13314@GreenHouse.cn.ibm.com> References: <20060906040250.GE13314@GreenHouse.cn.ibm.com> Message-ID: <45056BDD.4080706@redhat.com> Yao Qi wrote: > long in java is 64-bit, and 32-bit register value should be sign > extended. We override Register.get() in Isa to do sign extension for > Ia32 and PPC(32-bit platforms). > The underlying issue here, though, is that a << Register has-a Type >> and the type is what determines the characteristics of the register's value. For instance, a program counter might have an unsigned type, while general purpose registers have signed types. (This would address TomT's question). I have my doubts that we really want to push the full type system down into this simpler model. Will it be easy to differentiate between the two intents when get() is called by making it explicit - getAsAddress() getAsValue()? At least that way we can clearly understand the intent. Oh and while almost all ISAs have unsigned addresses, one, the mips, is sign-extended. We can worry about that later :-) Andrew > 2006-09-06 Yao Qi > > * IsaPPC.java (get): Sign extend 32-bit value to 64-bit. > * IsaIA32.java (get): Likewise. > > * TestRegs.java: Test sign extension on I386. > > * Syscall.java (printReturn): Do not cast returnCode to int. > > 2006-09-05 Yao Qi > > * funit-ia32-regs.S (main): Set %edx to -4 for sign extension > test. > > Please review this patch, and comments are welcome. Thanks! > > > ------------------------------------------------------------------------ > > Index: frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S,v > retrieving revision 1.2 > diff -u -r1.2 funit-ia32-regs.S > --- frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S 27 Jun 2006 15:28:53 -0000 1.2 > +++ frysk-core/frysk/pkglibexecdir/funit-ia32-regs.S 5 Sep 2006 09:42:42 -0000 > @@ -44,7 +44,7 @@ > mov $1, %eax // exit syscall number > mov $2, %ebx // first syscall arg > mov $3, %ecx > - mov $4, %edx > + mov $-4, %edx > mov $5, %ebp > mov $6, %esi > mov $7, %edi > Index: frysk-core/frysk/proc/IsaIA32.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v > retrieving revision 1.4 > diff -u -r1.4 IsaIA32.java > --- frysk-core/frysk/proc/IsaIA32.java 29 Aug 2006 05:35:43 -0000 1.4 > +++ frysk-core/frysk/proc/IsaIA32.java 5 Sep 2006 09:42:43 -0000 > @@ -57,6 +57,13 @@ > { > super(0, wordOffset * 4, 4, name); > } > + // sign extend all 32-bit register values to 64-bit long. > + public long get(frysk.proc.Task task) > + { > + int val; > + val = (int) super.get(task); > + return val; > + } > } > > static class IA32SegmentRegister > Index: frysk-core/frysk/proc/IsaPPC.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC.java,v > retrieving revision 1.2 > diff -u -r1.2 IsaPPC.java > --- frysk-core/frysk/proc/IsaPPC.java 23 Aug 2006 04:04:19 -0000 1.2 > +++ frysk-core/frysk/proc/IsaPPC.java 5 Sep 2006 09:42:43 -0000 > @@ -17,6 +17,13 @@ > { > super (0, wordOffset * 4, 4, name); > } > + // sign extend all 32-bit register values to 64-bit long. > + public long get(frysk.proc.Task task) > + { > + int val; > + val = (int) super.get(task); > + return val; > + } > } > > private static PPCRegister[] gprs () > Index: frysk-core/frysk/proc/Syscall.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/Syscall.java,v > retrieving revision 1.11 > diff -u -r1.11 Syscall.java > --- frysk-core/frysk/proc/Syscall.java 24 Aug 2006 03:13:05 -0000 1.11 > +++ frysk-core/frysk/proc/Syscall.java 5 Sep 2006 09:42:44 -0000 > @@ -197,7 +197,7 @@ > writer.println (""); > break; > case 'i': > - arg = (int)syscallEventInfo.returnCode (task); > + arg = syscallEventInfo.returnCode (task); > if (arg < 0) { > writer.print ("-1"); > writer.println (" ERRNO=" + (-arg)); > Index: frysk-core/frysk/proc/TestRegs.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/TestRegs.java,v > retrieving revision 1.2 > diff -u -r1.2 TestRegs.java > --- frysk-core/frysk/proc/TestRegs.java 31 Aug 2006 05:57:47 -0000 1.2 > +++ frysk-core/frysk/proc/TestRegs.java 5 Sep 2006 09:42:44 -0000 > @@ -415,7 +415,7 @@ > assertEquals ("orig_eax register", 1, t.orig_eax); > assertEquals ("ebx register", 2, t.ebx); > assertEquals ("ecx register", 3, t.ecx); > - assertEquals ("edx register", 4, t.edx); > + assertEquals ("edx register", -4, t.edx); > assertEquals ("ebp register", 5, t.ebp); > assertEquals ("esi register", 6, t.esi); > assertEquals ("edi register", 7, t.edi); > From kasal@ucw.cz Mon Sep 11 14:07:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Mon, 11 Sep 2006 14:07:00 -0000 Subject: frysk-imports frysk/gui/srcwin/ChangeLog frysk ... In-Reply-To: <20060908181937.16857.qmail@sourceware.org> References: <20060908181937.16857.qmail@sourceware.org> Message-ID: <20060911140656.GA22398@camelia.ucw.cz> Hello, this change has broken `make dist'. On Fri, Sep 08, 2006 at 06:19:37PM -0000, mcvet@sourceware.org wrote: > frysk-core: > 2006-09-08 Alexandre Oliva > > * Makefile.am (GEN_GCJ_LDADD): Link in libunwind-ptrace.a. this adds: EXTRA_DIST += $(srcdir)/frysk/pkglibexecdir/funit-rt-looper.h Is this a file which you forgot to cvs add? Or is it a typo and did you mean the corresponding *.c file? And the $(srcdir)/ prefix does not belong here. > * Makefile.in: Rebuild. The generated Makefile.in's are no longer kept in the CVS, so these lines do not belong to the chlog file. Have a nice day, Stepan Kasal From cagney@redhat.com Mon Sep 11 14:39:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 11 Sep 2006 14:39:00 -0000 Subject: Patch: minor efficiency improvement in Host In-Reply-To: References: Message-ID: <450574DD.60204@redhat.com> Tom, this works around a bug in gcj; it has been found to corrupt final parameters used in nested classes. Andrew Tom Tromey wrote: > Andrew got me cvs write access but I'm not comfortable simply > committing stuff yet. I'd prefer to get "ok"s for things more > complicated than typo fixes. > > This patch makes a couple anonymous classes from 'Host' slight more > efficient. The compiler will already generate fields in an anonymous > class to capture 'final' variables from the method which are used in > the anonymous class body. > > Having an explicit field is only needed if it will be modified in the > anonymous class. Otherwise we're just duplicating things for no benefit. > > Tom > > Index: ChangeLog > from Tom Tromey > * Host.java (requestRefreshXXX): Remove extra field from anonymous > class. > (requestCreateAttachedProc): Likewise. > > Index: Host.java > =================================================================== > RCS file: /cvs/frysk/frysk-core/frysk/proc/Host.java,v > retrieving revision 1.40 > diff -u -r1.40 Host.java > --- Host.java 7 Sep 2006 23:59:05 -0000 1.40 > +++ Host.java 8 Sep 2006 00:15:18 -0000 > @@ -176,12 +176,11 @@ > * refreshing the internal structure to match. Optionally refresh > * each processes task list. > */ > - public void requestRefreshXXX (final boolean refreshAllArg) > + public void requestRefreshXXX (final boolean refreshAll) > From cagney@redhat.com Mon Sep 11 15:05:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 11 Sep 2006 15:05:00 -0000 Subject: Stacktraces in the SourceWindow In-Reply-To: <1157718042.5773.108.camel@dijkstra.wildebeest.org> References: <1157667020.2031.24.camel@towel.toronto.redhat.com> <45009C81.5040404@redhat.com> <1157718042.5773.108.camel@dijkstra.wildebeest.org> Message-ID: <45057B32.8050500@redhat.com> Mark Wielaard wrote: > On Thu, 2006-09-07 at 17:26 -0500, Phil Muldoon wrote: > >> Awesome! It looks good. Nice to see the bits coming together after a lot >> of hard work! >> > > Yes, this is nice to see. > > >> >> >> If we could store the stack-trace saying during a syscall, we could >> print to the log window what function the thread was in when the syscall >> entered, as well as all the usual information. We could code up a GTK >> method to make the function click-able in the monitor log, and then it >> would open a source window showing the code context of where the syscall >> happened. If we stored the whole stacktrace for each log event in the >> ui, we could even show the user how it got to that point in the code. We >> 'd have to have a circular buffer though, and eventually stack traces >> would be discarded as memory demands dictate. >> >> >> > > Nice. That does probably slow down programs we are tracing even more > though. So it should probably not be on by default. You also need to > think about libraries that might be loaded/unloaded dynamically. How > would that interact with the stacktraces? It means that at a later time > the original stacktrace might not be valid, or that it might not be > possible to find the actual code back. > > Fortunatly, if the file name / line number information is captured then things won't go away (unless of course someone types rm -rf src :-). If a user also wants local variable, or detailed inline information, then that can also be eventually added -> with again an increase in overhead. Anyway I think this is something everyone wants -> for instance, with it I can use frysk to figure out why frysk is making some dubious system calls during start up. BTW, a command line utility that also finally drops into place is fstack. Andrew > From tromey@redhat.com Mon Sep 11 16:47:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 11 Sep 2006 16:47:00 -0000 Subject: Patch: minor efficiency improvement in Host In-Reply-To: <450574DD.60204@redhat.com> References: <450574DD.60204@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Cagney writes: Andrew> this works around a bug in gcj; it has been found to corrupt final Andrew> parameters used in nested classes. Ok. I will back it out. But FYI: I did a 'make check' and didn't see an error. And, AFAIK there is no bug in GCC bugzilla for this. Tom From cagney@redhat.com Mon Sep 11 17:15:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 11 Sep 2006 17:15:00 -0000 Subject: Patch: minor efficiency improvement in Host In-Reply-To: References: <450574DD.60204@redhat.com> Message-ID: <450599C0.9030305@redhat.com> Tom Tromey wrote: >>>>>> "Andrew" == Andrew Cagney writes: >>>>>> > > Andrew> this works around a bug in gcj; it has been found to corrupt final > Andrew> parameters used in nested classes. > > Ok. I will back it out. > > But FYI: I did a 'make check' and didn't see an error. > And, AFAIK there is no bug in GCC bugzilla for this. > > Tom > Yea, it occurred to me that, perhaps, it is time to suck-and-see. We've seen heeps of gcj fixes, and one could easily have thwacked this. Andrew From ajocksch@redhat.com Mon Sep 11 23:03:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Mon, 11 Sep 2006 23:03:00 -0000 Subject: Getting inline function information Message-ID: <4505EB30.9030604@redhat.com> After conversing with Roland this afternoon, I think I've figured out the way we should be approaching this problem. It looks like we need to do the following things for each PC in the stack frame returned from libunwind: 1) get the scopes for that pc using dwarf_getscopes (already wrapped). 2) Started at the innermost scope, work our way backwards and check for a Dwarf_Die with the DW_TAG_inlined_subroutine tag on it. Attributes attached to this tag may give us more information about the call state of the inlined code. You can get the Dwarf tag by using dwarf_tag. He also suggested taking a look at elfutils/src/addr2line.c:print_dwarf_function (which I have yet to do but will do shortly) for more information. It looks like the things that need to be accomplished to get this working are a) Wrap dwarf_tag b) Wrap whatever we need to get any/all relevant attributes out of the dwarf_tag (this may very well end up becoming a part of step (a) ). Hopefully I should be able to get started on this sometime this week, so if anyone has any questions/comments/criticisms please feel free to respond :) Adam From mark@klomp.org Tue Sep 12 10:40:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 12 Sep 2006 10:40:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <20060908125442.GA1364@GreenHouse.cn.ibm.com> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> Message-ID: <1158057582.3087.29.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-09-08 at 20:54 +0800, Yao Qi wrote: > Some items are listed here to present what I did, > > 1. Move syscallList from Syscall.java to Linux.java. > syscallList is relative to OS+ISA, so I put this array in > Linux.java. Personally I would place the actual lists on their own class files to keep the rest of the class files smaller. But that depends on whether you like all code to be together as much as possible, or you want code as much as possible in separate files. As already mentioned the OS + Isa setup is a little odd at the moment. It seems part of the design works around the fact that a Isa isn't a SyscallEventDecoder, only OS + Isa is. But there is no way to know which Isa instance is a OS + Isa, and which are only an Isa. If we aren't going to support other OSes than GNU/Linux soon I would propose to collapse the Isa/Os classes together and make Isa implement SyscallEventDecoder. Currently we have an extra layer of abstraction that we aren't using at all. > However, I do not change the spec in syscallList. > It would take me a whole day to look up system call numbers for > different architectures. :) As soon as the setup is good enough for IA32 we should probably divide the task between people and make sure the tables are correct for the various primary platforms that people use. I would love to see ftrace work on x86_64 and strace and systemtap seem to have the appropriate lists already so I can help with that arch. > 2. New methods to Syscall. > Tom submitted a patch about part of this, and I integrate his patch in > my changes. Add equals() in Syscall. > > 3. New methods in SyscallEventInfo. > a) getSyscall (Task task) return a Syscall object when a syscall happens. Should document what happens when not in a syscall. > b) getSyscallList() and getUnknownSyscalls() return the > architecture-dependent syscallList and unknown syscall hash map from > Linux.java > c) syscallByNum() and syscallByName() are also from Tom's patch. I wonder whether you might want a map from names to syscalls. Depending on how much syscallByName() is used. It currently does a linear search through the array. This might be premature micro-optimizing though. Would it make sense to extend Syscall with a getArguments() that returns the number of arguments of the syscall? And maybe a way to access the arguments with their correct type? It seems we encode that info in the Syscall, but don't actually use it at all. That would be really handy for inspecting the actual arguments and return values. But maybe this is for later. > 4. Setup three syscallList for Ia32 to index syscall object by syscall > number and first argument directly. > I discussed this with Mark here, > http://sources.redhat.com/ml/frysk/2006-q3/msg00409.html > > One syscallList is for common syscalls.(indexed by syscall number) > One syscalLList is for socket "subcall".(indexed by first argument) > One syscallList is for ipc "subcall".(indexed by first argument) Where are these ipc subcalls documented? > This patch could setup a framework for multi-arch syscall list, and now > ftrace could recognize syscall "bind" or "send" as a standard system > call, but there are something we could go on if this patch is on a > right track. > 1) Code syscallList spec for every architecture except Ia32. I did not > code syscall spec for ipc "subcalls". > 2) fill in argument for these "subcalls" on ia32. > On ia32, these "subcalls" share the same system call number, but with > different name, and these "subcalls" could be distinguished by %ebx, > and their arguments are in memory addressed by %ecx. > > In my patch, I just let it return 0 now, so the output from ftrace is > 0 or NULL. Are the arguments not just shifted by one? if so then just make an explicit SubSyscall class for them which just does arg(Task t, int n) { return super.arg(t, n + 1); } > > Any comments are welcome! > > Here is an output from ftrace on x86, > (I input Ctrl-C to kill accept) Nice output! BTW, it should output the port it is listening on to stdin. Then you can connect to that port from some other terminal and see it continue. Cheers, Mark From mark@klomp.org Tue Sep 12 10:45:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 12 Sep 2006 10:45:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> Message-ID: <1158057896.3087.36.camel@dijkstra.wildebeest.org> Hi, On Fri, 2006-09-08 at 17:51 -0600, Tom Tromey wrote: > This makes the strace '-e' argument look a little weird now too. If > the user 'ftrace's all 'open' calls, should it be every open call from > every ISA? I suppose we could try to enumerate every ISA supported by > the host platform... Well a Task knows which Isa it belongs to, so whenever ftrace starts tracing a new Task (or rather Proc) it should just reinterpret the '-e' argument for that process. Cheers, Mark From mcvet@redhat.com Tue Sep 12 13:13:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 12 Sep 2006 13:13:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <44FCDBE0.6040608@cn.ibm.com> References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> <44FCDBE0.6040608@cn.ibm.com> Message-ID: <1158066806.2031.92.camel@towel.toronto.redhat.com> On Tue, 2006-09-05 at 10:07 +0800, Wu Zhou wrote: > ./TestRunner frysk.rt.tests.TestStackBacktrace > Running testBacktrace(frysk.rt.tests.TestStackBacktrace) ...Frame 1 > File: ../../frysk-clean/frysk-core/frysk/pkglibexecdir/funit-rt-looper.c > Func: baz > Line: 69 > Col: 0 > Addr: 134514264 > Frame 2 > File: ../../frysk-clean/frysk-core/frysk/pkglibexecdir/funit-rt-looper.c > Func: bar > Line: 72 > Col: 0 > Addr: 134514286 > Frame 3 > File: ../../frysk-clean/frysk-core/frysk/pkglibexecdir/funit-rt-looper.c > Func: foo > Line: 53 > Col: 0 > Addr: 134514315 > Frame 4 > File: null > Func: main > Line: 0 > Col: 0 > Addr: 134514973 > Frame 5 > File: null > Func: > Line: 0 > Col: 0 > Addr: 12773156 > Frame 6 > File: null > Func: > Line: 0 > Col: 0 > Addr: 134514081 > PASS > > Time: 0.274 > > OK (1 test) > > Regards > - Wu Zhou So last night, after some investigation, Kyle Galloway and I found out why the line numbers seemed to be off in our backtraces and why, in particular, the line number for main () is zero with its source file being null. In _UPT_get_dyn_info_list_addr (), a call is made to get_list_addr () in the same file: #if UNW_TARGET_IA64 && defined(__linux) static inline int get_list_addr (unw_addr_space_t as, unw_word_t *dil_addr, void *arg, int *countp) { . . /* implemented */ . } #else static inline int get_list_addr (unw_addr_space_t as, unw_word_t *dil_addr, void *arg, int *countp) { # warning Implement get_list_addr(), please. *countp = 0; return 0; } #endif Setting *countp to zero results in libunwind falling back to frame pointers to determine the call stack information, which is no good for our uses. - Mike From cagney@redhat.com Tue Sep 12 13:33:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 12 Sep 2006 13:33:00 -0000 Subject: Getting inline function information In-Reply-To: <4505EB30.9030604@redhat.com> References: <4505EB30.9030604@redhat.com> Message-ID: <4506B713.8070604@redhat.com> Adam, Yes, dwarf has two redundant sources of information here. To be honest I think both should be programmably accessable - scanning .debug_line is a lot cheaper than .debug_info and often simple file/line info is all the user is after. For instance, fstack would, by default, just want .debug_line for backtraces as that keeps things very fast. One got-ya with .debug_line though, I'm not sure if the spec clearly defines inline nesting rules? Andrew Adam Jocksch wrote: > After conversing with Roland this afternoon, I think I've figured out > the way we should be approaching this problem. It looks like we need > to do the following things for each PC in the stack frame returned > from libunwind: > > 1) get the scopes for that pc using dwarf_getscopes (already wrapped). > 2) Started at the innermost scope, work our way backwards and check > for a Dwarf_Die with the DW_TAG_inlined_subroutine tag on it. > Attributes attached to this tag may give us more information about the > call state of the inlined code. You can get the Dwarf tag by using > dwarf_tag. > > He also suggested taking a look at > elfutils/src/addr2line.c:print_dwarf_function (which I have yet to do > but will do shortly) for more information. It looks like the things > that need to be accomplished to get this working are > a) Wrap dwarf_tag > b) Wrap whatever we need to get any/all relevant attributes out of the > dwarf_tag (this may very well end up becoming a part of step (a) ). > > Hopefully I should be able to get started on this sometime this week, > so if anyone has any questions/comments/criticisms please feel free to > respond :) > > Adam From cagney@redhat.com Tue Sep 12 13:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 12 Sep 2006 13:38:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <20060911073724.GD19394@GreenHouse.cn.ibm.com> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> <20060911073724.GD19394@GreenHouse.cn.ibm.com> Message-ID: <4506B842.3040501@redhat.com> Yao, w.r.t., checking syscalls, Sami persued this and, I believe, got it working by cross checking against the audit package (that has a full system call list, and "must" be correct). Having the cross check is very important as, maintaining the list is never done - linux will continue to breed system calls. Perhaps Sami can fill in the details here. Andrew Yao Qi wrote: > On Fri, Sep 08, 2006 at 05:51:25PM -0600, Tom Tromey wrote: > >>>>>>> "Yao" == Yao Qi writes: >>>>>>> >> I generally like this patch. I've got a few comments about it. >> >> Yao> It would take me a whole day to look up system call numbers for >> Yao> different architectures. :) >> >> Automation would be good... too bad there's no way to do this >> dynamically. >> > Syscall spec of the same name is the same on all the architectures, so > most of the work is copy-paste. Luckily, this work is > once-done-for-ever. :) From tromey@redhat.com Tue Sep 12 15:28:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 12 Sep 2006 15:28:00 -0000 Subject: Patch: minor efficiency improvement in Host In-Reply-To: <450599C0.9030305@redhat.com> References: <450574DD.60204@redhat.com> <450599C0.9030305@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Cagney writes: Andrew> Yea, it occurred to me that, perhaps, it is time to suck-and-see. Ok, then unless you say otherwise, I will just leave the tree as-is. Tom From kasal@ucw.cz Tue Sep 12 17:01:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Tue, 12 Sep 2006 17:01:00 -0000 Subject: Updated build in FC5 Updates Message-ID: <20060912170122.GA6934@camelia.ucw.cz> Hello, there is a build of frysk-0.0.1.2006.09.08 in FC5 Updates. (Rawhide currently lags behind, I suppose it'll be fixed in two days.) Stepan From scox@redhat.com Tue Sep 12 20:12:00 2006 From: scox@redhat.com (Stan Cox) Date: Tue, 12 Sep 2006 20:12:00 -0000 Subject: question about Proc.java In-Reply-To: <45008220.5010002@redhat.com> References: <45008220.5010002@redhat.com> Message-ID: <1158091935.10612.344.camel@multics.rdu.redhat.com> On Thu, 2006-09-07 at 16:33 -0400, Andrew Cagney wrote: > I'm guessing that the caching was removed > because it simplified the case of exec (and ensured that the test > passed). Stan? There was some case where the cache would get stale, but I forget the exact scenario now. From tromey@redhat.com Tue Sep 12 20:22:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 12 Sep 2006 20:22:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: Alexandre> Adding more stack frames gives it more stack space to sync Alexandre> up, and then it does display function names correctly, but Alexandre> it still fails to print file/line numbers. I'm yet to Alexandre> figure out why. I've got some more data for you. Today I modified my copy of ftrace to add 'pstack' functionality. (This took about 5 minutes... yay frysk!) When I compare 'ftrace -s' to pstack, the results are quite different. I tried each on a bash process waiting for command line input. In particular the frysk-based trace is missing calls at both ends of the stack (and pstack seems a bit better at finding the function names, but that part isn't a surprise). opsy. pstack 26539 #0 0x45bdc402 in __kernel_vsyscall () #1 0x45cb3fa3 in __read_nocancel () from /lib/libc.so.6 #2 0x080c152c in rl_getc () #3 0x080c1933 in rl_read_key () #4 0x080b14d7 in readline_internal_char () #5 0x080b1885 in readline () #6 0x080642d8 in parse_string_to_word_list () #7 0x08060725 in decode_prompt_string () #8 0x0806182a in gather_here_documents () #9 0x08064856 in yyparse () #10 0x0805e67f in parse_command () #11 0x0805e733 in read_command () #12 0x0805e964 in reader_loop () #13 0x0805e397 in main () opsy. ./install/bin/fryski -cp /home/tromey/workspace/fdtrace/bin:/home/tromey/gnu/Generics/Gcjh/gcjh.jar frysk.ftrace.Ftrace -s -p 26539 Stack trace for task {frysk.proc.LinuxTask@6c89c0,pid=26539,tid=26539,state=Attached.WaitForContinueOrUnblock} at 0x45bdc402 at 0x80c1933 at 0x80b14d7 at 0x80b1885 at 0x80642d8 at 0x8060725 at 0x806182a at 0x8064856 at 0x805e67f Tom From aoliva@redhat.com Tue Sep 12 21:32:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Tue, 12 Sep 2006 21:32:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Tom Tromey's message of "12 Sep 2006 14:16:33 -0600") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 12, 2006, Tom Tromey wrote: Alexandre> Adding more stack frames gives it more stack space to sync Alexandre> up, and then it does display function names correctly, but Alexandre> it still fails to print file/line numbers. I'm yet to Alexandre> figure out why. > I've got some more data for you. Thanks. Last night I found a very serious problem in my patch. The combination of libunwind-ptrace with our own ptrace stuff is not working at all, it's just by sheer luck that we some accurate unwind info. Whenever libunwind attempts to read memory from the underlying process (which it currently doesn't because I passed it the wrong pid), it would crash because the argument to the callback data is to the ptrace info only, not to the original pointer that contains pointers to both unw-ptrace and frysk data. So we lose. I started working on a patch to mend that, but couldn't finish it last night. Will do today, I hope. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From qiyaoltc@cn.ibm.com Wed Sep 13 01:04:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 13 Sep 2006 01:04:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <4506B842.3040501@redhat.com> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> <20060911073724.GD19394@GreenHouse.cn.ibm.com> <4506B842.3040501@redhat.com> Message-ID: <20060913010359.GA17676@GreenHouse.cn.ibm.com> On Tue, Sep 12, 2006 at 09:38:10AM -0400, Andrew Cagney wrote: > Yao, > > w.r.t., checking syscalls, Sami persued this and, I believe, got it > working by cross checking against the audit package (that has a full > system call list, and "must" be correct). Having the cross check is > very important as, maintaining the list is never done - linux will > continue to breed system calls. That would be great if Sami could cross check these system calls. We have produced a "draft" system call list for these architectures, and still not sure for some details, such as arguments type. I will spend some time on modifying this patch per Mark's comments, and will submit a "formal" patch here, including these system call list "draft". -- Yao Qi From woodzltc@cn.ibm.com Wed Sep 13 01:35:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 13 Sep 2006 01:35:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <4506B842.3040501@redhat.com> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> <20060911073724.GD19394@GreenHouse.cn.ibm.com> <4506B842.3040501@redhat.com> Message-ID: <45076062.2090303@cn.ibm.com> Andrew Cagney wrote: > Yao, > > w.r.t., checking syscalls, Sami persued this and, I believe, got it > working by cross checking against the audit package (that has a full > system call list, and "must" be correct). Having the cross check is > very important as, maintaining the list is never done - linux will > continue to breed system calls. > > Perhaps Sami can fill in the details here. Sami, Can you add some details about using audit package to cross check the system calls? We can generate a draft list of the system call from each arch's asm-ARCH/unistd.h, but it is a little hard for us to fetch the argument list for each system call. We are now assuming system calls with same name has the same argument list on various architectures. So we are using the extant argument lists of x86 platform. We are not very sure this holds all the time, but we do some random checks, that makes sense. We are very happy to have a try with your cross checking method if you can give us some clues. Regards - Wu Zhou > > Andrew > > Yao Qi wrote: >> On Fri, Sep 08, 2006 at 05:51:25PM -0600, Tom Tromey wrote: >> >>>>>>>> "Yao" == Yao Qi writes: >>>>>>>> >>> I generally like this patch. I've got a few comments about it. >>> >>> Yao> It would take me a whole day to look up system call numbers for >>> Yao> different architectures. :) >>> >>> Automation would be good... too bad there's no way to do this >>> dynamically. >>> >> Syscall spec of the same name is the same on all the architectures, so >> most of the work is copy-paste. Luckily, this work is >> once-done-for-ever. :) > From woodzltc@cn.ibm.com Wed Sep 13 02:05:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 13 Sep 2006 02:05:00 -0000 Subject: no .ppc64.rpm for frysk in FC 5.92 ppc iso Message-ID: <4507674F.2020202@cn.ibm.com> Kasal, We notice fc-5.92 was out today, but there is no frysk-xxx.ppc64.rpm in the ppc iso. There is indeed frysk-xxx.ppc64.rpm in ppc64 rawhide however. Could it be possible that this get into a later update? Thanks! Regards - Wu Zhou From cmoller@redhat.com Wed Sep 13 03:27:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Wed, 13 Sep 2006 03:27:00 -0000 Subject: fc6 frysk-core failures. Message-ID: <45077A9C.1000604@redhat.com> Running ./frysk-core/TestRunner -c FINE frysk.proc.TestProcTasksObserver fails on fc6. The fc6 logs and the fc5 logs are, aside from minor variations in the order of things, are identical until they get to: 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown FINE: testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >>>>>>>>>>>>>>>> start tearDown 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown FINE: testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) kill -KILL 14860 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown FINE: testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) kill -CONT 14860 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown FINE: testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) detach -KILL 14860 (failed) under fc5, and 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) >>>>>>>>>>>>>>>> start tearDown 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill -KILL 29450 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill -CONT 29450 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) detach -KILL 29450 under fc6. I.e., prima facie, the detach -KILL seems shows a failure under fc6 and a pass under fc5. I'll poke at it some more tomorrow. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From zhengyo@cn.ibm.com Wed Sep 13 07:07:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 13 Sep 2006 07:07:00 -0000 Subject: Two patches to add bi-arch test in frysk. Message-ID: <1158131338.3390.103.camel@YZ_X86_64> hi, On PPC64, applications are compiled into 32-bit mode by default, which means most applications running on PPC64 are in 32-bit mode. So it's necessary for frysk to do bi-arch test on PPC64. On X86_64, although applications are compiled into 64-bit mode by default, it's also needed for us to do bi-arch test. We ever discussed this problem and got some precious feedbacks. Read the following URL for details: http://sourceware.org/ml/frysk/2006-q3/msg00278.html. Based on the feedbacks from the previous discussion, we take the following two steps to implement the bi-arch test: 1)Automatically generate 32-bit executable cases on PPC64 and X86_64. The file "common/Makefile.gen.sh" is modified to generate the rules for bi-arch test during frysk's configuration. As we all know, bi-arch tests are unnecessary on X86, so the file "common/m4/frysk-do-biarch-test.m4" is added, in which one macro is defined to control whether the rules for bi-arch test will take effect or not. After the above modifications, the 32-bit cases will be generated under $(BUILD)/frysk-core/frysk/pkglibexecdir/biarch after building frysk. 2)Modify the funit and TestRunner cases to support running bi-arch test. We expect the bi-arch test will do no changes on the previous usage of funit or TestRunner. So we add two options(-i and -b) to support bi-arch test in both funit and TestRunner. If no one of above two options is given, the funit or TestRunner will do what they used to do. The Runner.java(located at $(FRYSK)/frysk-imports/frysk/junit/) is refactored to achieve the above purpose. We split the modifications into two patches: frysk_common_for_biarch.patch and frysk_supplement_for_biarch.patch. The former patch is for $(FRYSK)/common and $(FRYSK)/frysk-/common. You may need to apply the patch for each directories(we just do one patch for each sub-directoies "common" under $(FRYSK) and $(FRYSK)/frysk- because they are of the same). And the latter patch should be applied just once at top directory $(FRYSK). After compiling frysk, you can take the following steps to run bi-arch test: cd $(build)/frysk-core ./TestRunner -i or ./TestRunner -b Of course, you also can do bi-arch test with the similar options through funit. If you don't want any bi-arch test , just run TestRunner or funit without the option "-i" or "-b". Note: the option "-i" means running bi-arch test after finishing running the common test cases; but the option "-b" means just running bi-arch test. You can choose freely according to your request. 2006-09-13 Yong Zheng * common/acinclude.m4: Call FRYSK_DO_BIARCH_TEST. * common/Makefile.gen.sh: (echo_biarch_PROGRAMS): Output of rules for bi-arch test. * common/Makefile.rules (pkglibexec_biarch_PROGRAMS, pkglibexec_biarchdir): Define. * common/TestRunner.javain: Refactor to suport bi-arch test. * common/m4/frysk-do-biarch-test.m4: New file, defines FRYSK_DO_BIARCH_TEST. * frysk-imports/frysk/Config.javain (PKGLIBEXEC_BIARCHDIR): Add. * frysk-core/frysk/pkglibexecdir/funit.java (main): Add support for bi-arch test. * frysk-imports/frysk/ju0nit/Runner.java (repeatValue, justBiarchTest, includingBiarchTest, testCases, parser): New. (usage): New method. (setTestCases, GetTestCases): New methods. (doRunner): New method. (doBiarchTestRunner): New method. (Runner): Refactor to support bi-arch test. Rebuilt and tested based on frysk cvs(09-09) on X86/X86_64/PPC64. Please review and any comments are welcome! Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_common_for_biarch.patch Type: text/x-patch Size: 6682 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_supplement_for_biarch.patch Type: text/x-patch Size: 13402 bytes Desc: not available URL: From aoliva@redhat.com Wed Sep 13 09:43:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 13 Sep 2006 09:43:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Alexandre Oliva's message of "Tue, 12 Sep 2006 18:32:05 -0300") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 12, 2006, Alexandre Oliva wrote: > On Sep 12, 2006, Tom Tromey wrote: Alexandre> Adding more stack frames gives it more stack space to sync Alexandre> up, and then it does display function names correctly, but Alexandre> it still fails to print file/line numbers. I'm yet to Alexandre> figure out why. >> I've got some more data for you. > Thanks. Last night I found a very serious problem in my patch. The > combination of libunwind-ptrace with our own ptrace stuff is not > working at all, it's just by sheer luck that we some accurate unwind > info. Whenever libunwind attempts to read memory from the underlying > process (which it currently doesn't because I passed it the wrong > pid), it would crash because the argument to the callback data is to > the ptrace info only, not to the original pointer that contains > pointers to both unw-ptrace and frysk data. So we lose. > I started working on a patch to mend that, but couldn't finish it last > night. Will do today, I hope. Here's something that works much better. We now get symbols out of glibc's dynamic libraries too, but there's still something broken in the way compute addresses for stack traces. The internal computations are carried out correctly, but when frysk::rt::StackFrame::initialize() calls unw_get_proc_info(), it often gets back a fake procedure spec because we can't find unwind info for it (apparently because of the lack for dyn_list_addr or some such), so it returns proc_info with a one-byte range covering only the given IP, but when it calls unw_get_proc_name(), it uses a difference piece of code that succeeds in locating information about the procedure, and then it sets offset according to that base address, so we end up adding the offset to the wrong base address and get wrong info printed out. It still fails to print line numbers for main and for kernel vdso syscalls and their callers, but other than that, it's much better than before. The patch is not quite ready for public consumption (still missing a ChangeLog, for one), but I thought I'd post it for people who'd like to use it as is. My plan is to use the same code htat unw_get_proc_name() uses to locate the procedure info and use that in unw_get_proc_info as a fallback, but that will have to wait until I get some sleep. I actually took a stab at dyn_list_addr, but I can't quite figure out whether this is even to be found somewhere in the memory map of the target process. At first I thought it was supposed to be the dynamic loader's linked list of dynamic libs, but that's not it. Does anyone know? -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-proc-info.patch Type: text/x-patch Size: 24503 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From qiyaoltc@cn.ibm.com Wed Sep 13 12:18:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 13 Sep 2006 12:18:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <1158057582.3087.29.camel@dijkstra.wildebeest.org> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> <1158057582.3087.29.camel@dijkstra.wildebeest.org> Message-ID: <20060913121843.GB17676@GreenHouse.cn.ibm.com> On Tue, Sep 12, 2006 at 12:39:41PM +0200, Mark Wielaard wrote: > Hi, > > On Fri, 2006-09-08 at 20:54 +0800, Yao Qi wrote: > > Some items are listed here to present what I did, > > > > Personally I would place the actual lists on their own class files to > keep the rest of the class files smaller. But that depends on whether > you like all code to be together as much as possible, or you want code > as much as possible in separate files. It is hard to cover when I put syscallList in Linux.java, it is too long. I will create new files LinuxSyscall.java for syscallList and relative stuff. > > As already mentioned the OS + Isa setup is a little odd at the moment. > It seems part of the design works around the fact that a Isa isn't a > SyscallEventDecoder, only OS + Isa is. But there is no way to know which > Isa instance is a OS + Isa, and which are only an Isa. > > If we aren't going to support other OSes than GNU/Linux soon I would > propose to collapse the Isa/Os classes together and make Isa implement > SyscallEventDecoder. Currently we have an extra layer of abstraction > that we aren't using at all. I agree. I did not do this along with multi-arch syscall, and that is what we could do in the next step. When syscallList works well for multi-arch, this could be done without too much effort. > > > However, I do not change the spec in syscallList. > > It would take me a whole day to look up system call numbers for > > different architectures. :) > > As soon as the setup is good enough for IA32 we should probably divide > the task between people and make sure the tables are correct for the > various primary platforms that people use. I would love to see ftrace > work on x86_64 and strace and systemtap seem to have the appropriate > lists already so I can help with that arch. Thanks! We have built up a "draft" syscallList for X86_64 and PPC64, but we are still not sure about some details. I will submit the patch later, including these syscallLists, and we could check syscalls for different architectures in a parallel way. > > > 2. New methods to Syscall. > > Tom submitted a patch about part of this, and I integrate his patch in > > my changes. Add equals() in Syscall. > > > > 3. New methods in SyscallEventInfo. > > a) getSyscall (Task task) return a Syscall object when a syscall happens. > > Should document what happens when not in a syscall. > getSyscall (Task task) will return a meaningless Syscall object when no syscall happens. getSyscall first get the number of this system call from a certain register, and find Syscall object by this system call number in syscallList. getSyscall (Task task) does everything on the assumption that there is an system call, and programmer want to know the information about this system call. > > b) getSyscallList() and getUnknownSyscalls() return the > > architecture-dependent syscallList and unknown syscall hash map from > > Linux.java > > c) syscallByNum() and syscallByName() are also from Tom's patch. > > I wonder whether you might want a map from names to syscalls. Depending > on how much syscallByName() is used. It currently does a linear search > through the array. This might be premature micro-optimizing though. syscallByName() is not called frequently, and it *may* be only used in ftrace. Currently, syscallByName() is not called anywhere. > > Would it make sense to extend Syscall with a getArguments() that returns > the number of arguments of the syscall? And maybe a way to access the > arguments with their correct type? It seems we encode that info in the > Syscall, but don't actually use it at all. That would be really handy > for inspecting the actual arguments and return values. But maybe this is > for later. I agree. I refactor Syscall as an abstract class, with abstract methods, getArguments() and getReturnCode(), and Syscall could be extended in every LinuxSyscall.java when setting up the syscallList. Child class is created for socket subcalls and ipc subcalls respectively, and getArguments() is overwritten to do different thing. > > > One syscalLList is for socket "subcall".(indexed by first argument) > > One syscallList is for ipc "subcall".(indexed by first argument) > > Where are these ipc subcalls documented? These subcalls are semop, semget, semctl, semtimedop, and so forth. I get them from the src of strace, and you could also find them in linux/syscallent.h and decode_subcall in syscall.c. > > Are the arguments not just shifted by one? if so then just make an > explicit SubSyscall class for them which just does > arg(Task t, int n) { return super.arg(t, n + 1); } For ipc subcalls, it is true. These arguments are shifted by one. For socket subcalls, it is not. All the arguments are dereferenced by %ecx (on X86). > > > > > Any comments are welcome! > > > > Here is an output from ftrace on x86, > > (I input Ctrl-C to kill accept) > > Nice output! > BTW, it should output the port it is listening on to stdin. Then you can > connect to that port from some other terminal and see it continue. How could I *connect* to that port in other terminal? -- Yao Qi From scox@redhat.com Wed Sep 13 12:39:00 2006 From: scox@redhat.com (Stan Cox) Date: Wed, 13 Sep 2006 12:39:00 -0000 Subject: minutes 20060912 Message-ID: <1158151164.10612.363.camel@multics.rdu.redhat.com> Dogtail Dogtail builds on FC6 but doesn't run due to the frame buffer changes not being pushed yet. Added tests but not checked in yet due to playback bug Progress on mind numbing script to walk the gui. Hard part is how to handle changes to the gui. Traveling salesman problem? Dogtail bugs: FC5/FC6 testing Discussion on event loop semantics and the logistics of catching errors in waitpid libunwind Not working completely correct for backtracing Might be able to do backtrace from system call Some upstream discussion, meanwhile also doing in-house parallel work 32/64 Most issues addressed Need 32 on 64 testing. This might require infrastructure changes. Upstream discussion of the syscall list continues Coverage Procedure to do coverage analysis for frysk is now documented. Breakpoints Can set breakpoints by address. Discussion of where to hook into this functionality: command level, ftrace, gui (probably only want high level breakpoints here) Event Viewer Progress continues on complex scrollbar. For example the google finance widget which gives an overall view. Discussion of time: absolute versus delta from a known event time. Inlining Strace Java Gnome No change Disassembler Similar to memory window just a different view and emphasis From mark@klomp.org Wed Sep 13 12:55:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 13 Sep 2006 12:55:00 -0000 Subject: no .ppc64.rpm for frysk in FC 5.92 ppc iso In-Reply-To: <4507674F.2020202@cn.ibm.com> References: <4507674F.2020202@cn.ibm.com> Message-ID: <1158152101.3144.30.camel@dijkstra.wildebeest.org> On Wed, 2006-09-13 at 10:05 +0800, Wu Zhou wrote: > We notice fc-5.92 was out today, but there is no frysk-xxx.ppc64.rpm in the ppc iso. There is > indeed frysk-xxx.ppc64.rpm in ppc64 rawhide however. Could it be possible that this get into a > later update? Thanks! This is tracked as the following bug against fedora/anaconda: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205235 Which blocks the frysk on ppc(64) install bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204787 From qiyaoltc@cn.ibm.com Wed Sep 13 13:11:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 13 Sep 2006 13:11:00 -0000 Subject: [patch] System call for multi-architecture Message-ID: <20060913131050.GC17676@GreenHouse.cn.ibm.com> There were two threads in this maillist about this issue, and I modified this patch for several time per Mark and Tom's comments, and feedback from these two threads. This patch could provide, 1) draft system call list(for x86, x86_64, and powerpc). 2) ftrace could work on these three platforms. This patch could not provide, or could provide in the next step, 1) 64-bit ftrace trace 32-bit app. 2) accurate arguments for some system calls. Mark, Sami, the patch could give you syscallLists for different architecture. 2006-09-13 Yao Qi * Isa.java (getSyscallList): New method. (getUnknownSyscalls): Likewise. (syscallByName): Likewise. * IsaEMT64.java: Implement them. * IsaIA32.java: Likewise. * IsaPPC.java: Likewise. * IsaPPC64.java: Likewise. * LinuxPowerPCSyscall.java: New file. * LinuxEMT64Syscall.java: New file. * LinuxIa32Syscall.java: New file. * LinuxIa32.java (returnCode): Removed. (arg): Removed. * LinuxEMT64.java: Likewise. * LinuxPPC.java: Likewise. * LinuxPPC64.java: Likewise. * Syscall.java (iterateSyscallByName): New method. * SyscallEventInfo.java (getSyscall): New abstract method. (arg): New method. (returnCode): Likewise. Tom Tromey * Syscall.java (syscallByNum): Updated javadoc. Fixed typo. Cache unknown syscalls. (unknownSyscalls): New field. (equals): New method. (syscallByName): Likewise. 2006-09-13 Yao Qi * observers/SysCallUtilyInfo.java: Get Syscall object from syscallEventInfo. Apply this patch to cvs head (09/13), and tested on x86/x86_64/ppc64. OK to commit? -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/bindir/ftrace.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/bindir/ftrace.java,v retrieving revision 1.18 diff -u -r1.18 ftrace.java --- frysk-core/frysk/bindir/ftrace.java 7 Aug 2006 20:22:15 -0000 1.18 +++ frysk-core/frysk/bindir/ftrace.java 13 Sep 2006 11:48:36 -0000 @@ -144,7 +144,9 @@ System.out.println("Got task exception " + e); return Action.CONTINUE; } - frysk.proc.Syscall syscall = frysk.proc.Syscall.syscallByNum(syscallEventInfo.number(task)); + + frysk.proc.Syscall syscall = syscallEventInfo.getSyscall(task); + PrintWriter printWriter = new PrintWriter(System.out); printWriter.print(task.getProc().getPid() + "." + task.getTid() + " "); syscall.printCall(printWriter, task, syscallEventInfo); @@ -165,7 +167,8 @@ System.out.println("Got task exception " + e); return Action.CONTINUE; } - frysk.proc.Syscall syscall = frysk.proc.Syscall.syscallByNum(syscallEventInfo.number(task)); + frysk.proc.Syscall syscall = syscallEventInfo.getSyscall(task); + PrintWriter printWriter = new PrintWriter(System.out); syscall.printReturn(printWriter, task, syscallEventInfo); printWriter.flush(); Index: frysk-core/frysk/proc/Isa.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Isa.java,v retrieving revision 1.11 diff -u -r1.11 Isa.java --- frysk-core/frysk/proc/Isa.java 23 Aug 2006 04:04:19 -0000 1.11 +++ frysk-core/frysk/proc/Isa.java 13 Sep 2006 11:48:36 -0000 @@ -39,6 +39,7 @@ package frysk.proc; +import java.util.HashMap; import java.util.Iterator; import inua.eio.ByteOrder; @@ -95,4 +96,13 @@ //{ //throw new RuntimeException ("not implemented"); //} + + /** @return Syscall[] return system call list for this Linux. */ + Syscall[] getSyscallList (); + /** @return HashMap return a HashMap for unknown system calls. */ + HashMap getUnknownSyscalls (); + + /** @return Syscall return system call object if the name could be + * found in syscallList, otherwise return null. */ + Syscall syscallByName (String Name); } Index: frysk-core/frysk/proc/IsaEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaEMT64.java,v retrieving revision 1.4 diff -u -r1.4 IsaEMT64.java --- frysk-core/frysk/proc/IsaEMT64.java 29 Aug 2006 05:35:43 -0000 1.4 +++ frysk-core/frysk/proc/IsaEMT64.java 13 Sep 2006 11:48:36 -0000 @@ -39,6 +39,7 @@ package frysk.proc; +import java.util.HashMap; import java.util.Iterator; import java.util.LinkedHashMap; import inua.eio.ByteOrder; @@ -165,4 +166,19 @@ return pcValue; } + + public Syscall[] getSyscallList () + { + return LinuxEMT64Syscall.syscallList; + } + + public HashMap getUnknownSyscalls () + { + return LinuxEMT64Syscall.unknownSyscalls; + } + + public Syscall syscallByName (String name) + { + return Syscall.iterateSyscallByName (name, LinuxEMT64Syscall.syscallList); + } } Index: frysk-core/frysk/proc/IsaIA32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaIA32.java,v retrieving revision 1.4 diff -u -r1.4 IsaIA32.java --- frysk-core/frysk/proc/IsaIA32.java 29 Aug 2006 05:35:43 -0000 1.4 +++ frysk-core/frysk/proc/IsaIA32.java 13 Sep 2006 11:48:36 -0000 @@ -39,6 +39,7 @@ package frysk.proc; +import java.util.HashMap; import java.util.Iterator; import java.util.LinkedHashMap; import inua.eio.ByteOrder; @@ -172,6 +173,33 @@ return pcValue; } -} + public Syscall[] getSyscallList () + { + return LinuxIa32Syscall.syscallList; + } + + public HashMap getUnknownSyscalls () + { + return LinuxIa32Syscall.unknownSyscalls; + } + + public Syscall syscallByName (String name) + { + Syscall syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxIa32Syscall.syscallList); + if (syscall != null) + return syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxIa32Syscall.socketSubcallList); + if (syscall != null) + return syscall; + syscall = Syscall.iterateSyscallByName (name, LinuxIa32Syscall.ipcSubcallList); + if (syscall != null) + return syscall; + + return null; + } +} Index: frysk-core/frysk/proc/IsaPPC.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC.java,v retrieving revision 1.2 diff -u -r1.2 IsaPPC.java --- frysk-core/frysk/proc/IsaPPC.java 23 Aug 2006 04:04:19 -0000 1.2 +++ frysk-core/frysk/proc/IsaPPC.java 13 Sep 2006 11:48:36 -0000 @@ -1,7 +1,45 @@ // This file is part of the program FRYSK. +// +// Copyright 2006 IBM Corp. +// +// FRYSK is free software; you can redistribute it and/or modify it +// under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// FRYSK is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with FRYSK; if not, write to the Free Software Foundation, +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// In addition, as a special exception, Red Hat, Inc. gives You the +// additional right to link the code of FRYSK with code not covered +// under the GNU General Public License ("Non-GPL Code") and to +// distribute linked combinations including the two, subject to the +// limitations in this paragraph. Non-GPL Code permitted under this +// exception must only link to the code of FRYSK through those well +// defined interfaces identified in the file named EXCEPTION found in +// the source code files (the "Approved Interfaces"). The files of +// Non-GPL Code may instantiate templates or use macros or inline +// functions from the Approved Interfaces without causing the +// resulting work to be covered by the GNU General Public +// License. Only Red Hat, Inc. may make changes or additions to the +// list of Approved Interfaces. You must obey the GNU General Public +// License in all respects for all of the FRYSK code and other code +// used in conjunction with FRYSK except the Non-GPL Code covered by +// this exception. If you modify this file, you may extend this +// exception to your version of the file, but you are not obligated to +// do so. If you do not wish to provide this exception without +// modification, you must delete this exception statement from your +// version and license this file solely under the GPL without +// exception. package frysk.proc; +import java.util.HashMap; import java.util.Iterator; import java.util.LinkedHashMap; @@ -109,4 +147,33 @@ { throw new RuntimeException("unsupported architecture: " + this); } + + public Syscall[] getSyscallList () + { + return LinuxPowerPCSyscall.syscallList; + } + + public HashMap getUnknownSyscalls () + { + return LinuxPowerPCSyscall.unknownSyscalls; + } + + public Syscall syscallByName (String name) + { + Syscall syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxPowerPCSyscall.syscallList); + if (syscall != null) + return syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxPowerPCSyscall.socketSubcallList); + if (syscall != null) + return syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxPowerPCSyscall.ipcSubcallList); + if (syscall != null) + return syscall; + + return null; + } } Index: frysk-core/frysk/proc/IsaPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/IsaPPC64.java,v retrieving revision 1.5 diff -u -r1.5 IsaPPC64.java --- frysk-core/frysk/proc/IsaPPC64.java 29 Aug 2006 05:35:43 -0000 1.5 +++ frysk-core/frysk/proc/IsaPPC64.java 13 Sep 2006 11:48:37 -0000 @@ -1,7 +1,44 @@ // This file is part of the program FRYSK. - +// +// Copyright 2006 IBM Corp. +// +// FRYSK is free software; you can redistribute it and/or modify it +// under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// FRYSK is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with FRYSK; if not, write to the Free Software Foundation, +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// In addition, as a special exception, Red Hat, Inc. gives You the +// additional right to link the code of FRYSK with code not covered +// under the GNU General Public License ("Non-GPL Code") and to +// distribute linked combinations including the two, subject to the +// limitations in this paragraph. Non-GPL Code permitted under this +// exception must only link to the code of FRYSK through those well +// defined interfaces identified in the file named EXCEPTION found in +// the source code files (the "Approved Interfaces"). The files of +// Non-GPL Code may instantiate templates or use macros or inline +// functions from the Approved Interfaces without causing the +// resulting work to be covered by the GNU General Public +// License. Only Red Hat, Inc. may make changes or additions to the +// list of Approved Interfaces. You must obey the GNU General Public +// License in all respects for all of the FRYSK code and other code +// used in conjunction with FRYSK except the Non-GPL Code covered by +// this exception. If you modify this file, you may extend this +// exception to your version of the file, but you are not obligated to +// do so. If you do not wish to provide this exception without +// modification, you must delete this exception statement from your +// version and license this file solely under the GPL without +// exception. package frysk.proc; +import java.util.HashMap; import java.util.Iterator; import java.util.LinkedHashMap; @@ -140,4 +177,33 @@ return pcValue; } + + public Syscall[] getSyscallList () + { + return LinuxPowerPCSyscall.syscallList; + } + + public HashMap getUnknownSyscalls () + { + return LinuxPowerPCSyscall.unknownSyscalls; + } + + public Syscall syscallByName (String name) + { + Syscall syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxPowerPCSyscall.syscallList); + if (syscall != null) + return syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxPowerPCSyscall.socketSubcallList); + if (syscall != null) + return syscall; + + syscall = Syscall.iterateSyscallByName (name, LinuxPowerPCSyscall.ipcSubcallList); + if (syscall != null) + return syscall; + + return null; + } } Index: frysk-core/frysk/proc/LinuxEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxEMT64.java,v retrieving revision 1.2 diff -u -r1.2 LinuxEMT64.java --- frysk-core/frysk/proc/LinuxEMT64.java 11 Jul 2006 21:25:25 -0000 1.2 +++ frysk-core/frysk/proc/LinuxEMT64.java 13 Sep 2006 11:48:37 -0000 @@ -39,53 +39,40 @@ package frysk.proc; +import java.util.HashMap; + class LinuxEMT64 - extends IsaEMT64 implements SyscallEventDecoder + extends IsaEMT64 implements SyscallEventDecoder { - private static LinuxEMT64 isa; - static LinuxEMT64 isaSingleton () - { - if (isa == null) - isa = new LinuxEMT64 (); - return isa; - } + private static LinuxEMT64 isa; + static LinuxEMT64 isaSingleton () + { + if (isa == null) + isa = new LinuxEMT64 (); + return isa; + } + + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; - private SyscallEventInfo info; - public SyscallEventInfo getSyscallEventInfo () - { - if (info == null) - info = new SyscallEventInfo () - { - public int number (Task task) - { - return (int)getRegisterByName ("orig_rax").get (task); - } - public long returnCode (Task task) - { - return getRegisterByName ("rax").get (task); - } - public long arg (Task task, int n) - { - switch (n) { - case 0: - return (long)number (task); - case 1: - return getRegisterByName("rdi").get (task); - case 2: - return getRegisterByName("rsi").get (task); - case 3: - return getRegisterByName("rdx").get (task); - case 4: - return getRegisterByName("r10").get (task); - case 5: - return getRegisterByName("r8").get (task); - case 6: - return getRegisterByName("r9").get (task); - default: - throw new RuntimeException ("unknown syscall arg"); - } - } - }; - return info; - } + private SyscallEventInfo info; + + public SyscallEventInfo getSyscallEventInfo () + { + if (info == null) + info = new SyscallEventInfo () + { + public int number (Task task) + { + return (int)getRegisterByName ("orig_rax").get (task); + } + public Syscall getSyscall(Task task) + { + int number = this.number(task); + return LinuxEMT64Syscall.syscallByNum (task, number); + } + }; + return info; + } } Index: frysk-core/frysk/proc/LinuxIa32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxIa32.java,v retrieving revision 1.8 diff -u -r1.8 LinuxIa32.java --- frysk-core/frysk/proc/LinuxIa32.java 11 Jul 2006 21:25:25 -0000 1.8 +++ frysk-core/frysk/proc/LinuxIa32.java 13 Sep 2006 11:48:37 -0000 @@ -40,52 +40,33 @@ package frysk.proc; class LinuxIa32 - extends IsaIA32 implements SyscallEventDecoder + extends IsaIA32 implements SyscallEventDecoder { - private static LinuxIa32 isa; - static LinuxIa32 isaSingleton () - { - if (isa == null) - isa = new LinuxIa32 (); - return isa; - } + private static LinuxIa32 isa; + static LinuxIa32 isaSingleton () + { + if (isa == null) + isa = new LinuxIa32 (); + return isa; + } + + private SyscallEventInfo info; + public SyscallEventInfo getSyscallEventInfo () + { + if (info == null) + info = new SyscallEventInfo () + { + public int number (Task task) + { + return (int)getRegisterByName ("orig_eax").get (task); + } + public Syscall getSyscall(Task task) + { + int number = this.number(task); + return LinuxIa32Syscall.syscallByNum (task, number); + } + }; + return info; + } - private SyscallEventInfo info; - public SyscallEventInfo getSyscallEventInfo () - { - if (info == null) - info = new SyscallEventInfo () - { - public int number (Task task) - { - return (int)getRegisterByName ("orig_eax").get (task); - } - public long returnCode (Task task) - { - return getRegisterByName ("eax").get (task); - } - public long arg (Task task, int n) - { - switch (n) { - case 0: - return (long)number (task); - case 1: - return getRegisterByName("ebx").get (task); - case 2: - return getRegisterByName("ecx").get (task); - case 3: - return getRegisterByName("edx").get (task); - case 4: - return getRegisterByName("esi").get (task); - case 5: - return getRegisterByName("edi").get (task); - case 6: - return getRegisterByName("eax").get (task); - default: - throw new RuntimeException ("unknown syscall arg"); - } - } - }; - return info; - } } Index: frysk-core/frysk/proc/LinuxPPC.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC.java,v retrieving revision 1.4 diff -u -r1.4 LinuxPPC.java --- frysk-core/frysk/proc/LinuxPPC.java 11 Sep 2006 20:50:39 -0000 1.4 +++ frysk-core/frysk/proc/LinuxPPC.java 13 Sep 2006 11:48:37 -0000 @@ -2,13 +2,15 @@ package frysk.proc; +import java.util.HashMap; + import java.util.logging.Level; import java.util.logging.Logger; class LinuxPPC extends IsaPPC implements SyscallEventDecoder { - private static Logger logger = Logger.getLogger ("frysk");//.proc"); + private static Logger logger = Logger.getLogger ("frysk");//.proc"); private static LinuxPPC isa; static LinuxPPC isaSingleton () @@ -18,6 +20,10 @@ return isa; } + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + private SyscallEventInfo info; public SyscallEventInfo getSyscallEventInfo () @@ -30,38 +36,13 @@ logger.log (Level.FINE, "Get GPR0 {0}\n", getRegisterByName("gpr0")); return (int)getRegisterByName("gpr0").get(task); } - public long returnCode (Task task) - { - int flag = (int) getRegisterByName("ccr").get(task); - - if ((flag & 0x10000000) != 0) - return -getRegisterByName("gpr3").get(task); - else - return getRegisterByName("gpr3").get(task); - } - public long arg (Task task, int n) - { - switch (n) - { - case 0: - return (long)number(task); - case 1: - return getRegisterByName("orig_r3").get(task); - case 2: - return getRegisterByName("gpr4").get(task); - case 3: - return getRegisterByName("gpr5").get(task); - case 4: - return getRegisterByName("gpr6").get(task); - case 5: - return getRegisterByName("gpr7").get(task); - case 6: - return getRegisterByName("gpr8").get(task); - default: - throw new RuntimeException ("unknown syscall arg"); - } - } + public Syscall getSyscall(Task task) + { + int number = this.number(task); + return LinuxPowerPCSyscall.syscallByNum (task, number); + } }; return info; } -} \ No newline at end of file + +} Index: frysk-core/frysk/proc/LinuxPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC64.java,v retrieving revision 1.4 diff -u -r1.4 LinuxPPC64.java --- frysk-core/frysk/proc/LinuxPPC64.java 11 Sep 2006 20:50:39 -0000 1.4 +++ frysk-core/frysk/proc/LinuxPPC64.java 13 Sep 2006 11:48:37 -0000 @@ -2,13 +2,14 @@ package frysk.proc; +import java.util.HashMap; import java.util.logging.Level; import java.util.logging.Logger; class LinuxPPC64 extends IsaPPC64 implements SyscallEventDecoder { - private static Logger logger = Logger.getLogger ("frysk");//.proc"); + private static Logger logger = Logger.getLogger ("frysk");//.proc"); private static LinuxPPC64 isa; static LinuxPPC64 isaSingleton () @@ -18,6 +19,10 @@ return isa; } + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + private SyscallEventInfo info; public SyscallEventInfo getSyscallEventInfo () { @@ -29,36 +34,13 @@ logger.log (Level.FINE, "Get GPR0 {0}\n",getRegisterByName("gpr0")); return (int)getRegisterByName("gpr0").get(task); } - public long returnCode (Task task) - { - int flag = (int)getRegisterByName("ccr").get(task); - if ((flag & 0x10000000) != 0) - return -getRegisterByName("gpr3").get(task); - else - return getRegisterByName("gpr3").get(task); - } - public long arg (Task task, int n) + + public Syscall getSyscall(Task task) { - switch (n) - { - case 0: - return (long)number (task); - case 1: - return getRegisterByName("orig_r3").get(task); - case 2: - return getRegisterByName("gpr4").get(task); - case 3: - return getRegisterByName("gpr5").get(task); - case 4: - return getRegisterByName("gpr6").get(task); - case 5: - return getRegisterByName("gpr7").get(task); - case 6: - return getRegisterByName("gpr8").get(task); - default: - throw new RuntimeException ("unknown syscall arg"); - } - } + int number = this.number(task); + return LinuxPowerPCSyscall.syscallByNum (task, number); + } + }; return info; } Index: frysk-core/frysk/proc/Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Syscall.java,v retrieving revision 1.12 diff -u -r1.12 Syscall.java --- frysk-core/frysk/proc/Syscall.java 6 Sep 2006 15:28:32 -0000 1.12 +++ frysk-core/frysk/proc/Syscall.java 13 Sep 2006 11:48:37 -0000 @@ -38,6 +38,7 @@ // exception. package frysk.proc; +import java.util.HashMap; import inua.util.PrintWriter; /** @@ -45,7 +46,7 @@ * used in combination with {@link SyscallEventInfo} and the * task to get information about a particular system call event. */ -public class Syscall +public abstract class Syscall { int number; public final int numArgs; @@ -96,23 +97,32 @@ { return number; } - - private void printStringArg (PrintWriter writer, - frysk.proc.Task task, - long addr) + /** Return true if this object equals the argument. */ + public boolean equals(Object other) { - if (addr == 0) - writer.print ("0x0"); - else { - writer.print ("\""); - StringBuffer x = new StringBuffer (); - task.memory.get (addr, 20, x); - if (x.length () == 20) - x.append ("..."); - x.append ("\""); - writer.print (x); - } + // Syscall objects are unique. + return this == other; + } + + abstract public long getArguments (Task task, int n); + abstract public long getReturnCode (Task task); + + private void printStringArg (PrintWriter writer, + frysk.proc.Task task, + long addr) + { + if (addr == 0) + writer.print ("0x0"); + else { + writer.print ("\""); + StringBuffer x = new StringBuffer (); + task.memory.get (addr, 20, x); + if (x.length () == 20) + x.append ("..."); + x.append ("\""); + writer.print (x); } + } /** * Print a textual representation of a system call. @@ -212,295 +222,116 @@ return writer; } - /** - * Given a system call's number, this will return the corresponding - * Syscall object. Note that system call numbers are platform - * dependent. - * XXX: Eventually this will be moved down to Linux, or even - * further. - * @param num the number of the system call - */ - public static Syscall syscallByNum (int num) - { - if(num >= syscallList.length || num < 0){ - return new Syscall("UKNOWN SYSCALL", num); + /** + * Given a system call's name, this will return the corresponding + * Syscall object. If no predefined system call with that name + * is available, this will return null. + * @param name the name of the system call + * @param syscallList system calls list + * @return the Syscall object, or null + */ + public static Syscall iterateSyscallByName (String name, Syscall[] syscallList) + { + for (int i = 0; i < syscallList.length; ++i) + if (name.equals(syscallList[i].name)) + return syscallList[i]; + return null; + } + + /** + * Given a system call's number, this will return the corresponding + * Syscall object. Note that system call numbers are platform + * dependent. This will return a Syscall object in all cases; if + * there is no predefined system call with the given number, a unique + * "unknown" system call with the indicated number will be saved in + * unknownSyscalls. + * @param num the number of the system call + * @param task the current task + * @return the Syscall object + */ + public static Syscall syscallByNum (int num, Task task) + { + Syscall[] syscallList; + HashMap unknownSyscalls; + + try + { + syscallList = task.getIsa().getSyscallList (); + unknownSyscalls = task.getIsa().getUnknownSyscalls (); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get the isa"); + } + + if (num < 0) + { + throw new RuntimeException ("Negative Syscall Number:" + + Integer.toString(num)); + } + else if (num >= syscallList.length) + { + synchronized (Syscall.class) + { + Integer key = new Integer(num); + if (unknownSyscalls == null) + unknownSyscalls = new HashMap(); + else if (unknownSyscalls.containsKey(key)) + return (Syscall) unknownSyscalls.get(key); + + class UnknownSyscall + extends Syscall + { + UnknownSyscall (String name, int number) + { + super (name, number); + } + + public long getArguments (Task task, int n) + { + return 0; + } + public long getReturnCode (Task task) + { + return 0; + } + } + Syscall result = new UnknownSyscall("UNKNOWN SYSCALL " + + Integer.toString(num), num); + + unknownSyscalls.put(key, result); + + return result; + } + } + else + { + return syscallList[num]; + } + } + + /** + * Given a system call's name, this will return the corresponding + * Syscall object. If no predefined system call with that name + * is available, this will return null. + * @param name the name of the system call + * @param task the cuurent task + * @return the Syscall object, or null + * @throws NullPointerException if name is null + */ + public static Syscall syscallByName (String name, Task task) + { + Syscall syscall; + + try + { + syscall = task.getIsa().syscallByName(name); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get the name of isa"); } - return syscallList[num]; - } - private static Syscall[] syscallList = { - new Syscall (0), - new Syscall ("exit", 1, 1), - new Syscall ("fork", 2, 0, "i: "), - new Syscall ("read", 3, 3, "i:ibn "), - new Syscall ("write", 4, 3, "i:ibn "), - new Syscall ("open", 5, 3, "i:siv "), - new Syscall ("close", 6, 1, "i:i "), - new Syscall ("waitpid", 7, 3, "i:ipi "), - new Syscall ("creat", 8, 2, "i:sv"), - new Syscall ("link", 9, 2, "i:ss "), - new Syscall ("unlink", 10, 1, "i:s "), - new Syscall ("execve", 11, 3, "i:ppp "), - new Syscall ("chdir", 12, 1, "i:s "), - new Syscall ("time", 13, 1, "i:P "), - new Syscall ("sys_mknod", 14, 3, "i:sii "), - new Syscall ("chmod", 15, 2, "i:si "), - new Syscall ("lchown", 16, 3, "i:sii "), - new Syscall ("break", 17), - new Syscall ("old_stat", 18, 3, "i:pp "), - new Syscall ("lseek", 19, 3, "i:iii "), - new Syscall ("getpid", 20, 0, "i: "), - new Syscall ("mount", 21, 5, "i:sssip "), - new Syscall ("umount", 22, 1, "i:s "), - new Syscall ("setuid", 23, 1, "i:i "), - new Syscall ("getuid", 24, 0, "i: "), - new Syscall ("stime", 25, 1, "i:p "), - new Syscall ("ptrace", 26, 4, "i:iiii "), - new Syscall ("alarm", 27, 1, "i:i "), - new Syscall ("old_fstat", 28, 2, "i:ip "), - new Syscall ("pause", 29, 0, "i: "), - new Syscall ("utime", 30, 2, "i:sP "), - new Syscall ("stty", 31), - new Syscall ("gtty", 32), - new Syscall ("access", 33, 2, "i:si "), - new Syscall ("nice", 34, 1, "i:i "), - new Syscall ("ftime", 35, 1, "i:p "), - new Syscall ("sync", 36, 0, "i: "), - new Syscall ("kill", 37, 2, "i:ii "), - new Syscall ("rename", 38, 2, "i:ss "), - new Syscall ("mkdir", 39, 2, "i:si "), - new Syscall ("rmdir", 40, 1, "i:s "), - new Syscall ("dup", 41, 1, "i:i "), - new Syscall ("pipe", 42, 1, "i:f "), - new Syscall ("times", 43, 1, "i:p "), - new Syscall ("prof", 44), - new Syscall ("brk", 45, 1, "i:p "), - new Syscall ("setgid", 46, 1, "i:i "), - new Syscall ("getgid", 47, 0, "i: "), - new Syscall ("signal", 48, 2, "i:ii "), - new Syscall ("geteuid", 49, 0, "i: "), - new Syscall ("getegid", 50, 0, "i: "), - new Syscall ("acct", 51, 1, "i:S "), - new Syscall ("umount2", 52, 2, "i:si "), - new Syscall ("lock", 53), - new Syscall ("ioctl", 54, 3, "i:iiI "), - new Syscall ("fcntl", 55, 3, "i:iiF "), - new Syscall ("mpx", 56), - new Syscall ("setpgid", 57, 2, "i:ii "), - new Syscall ("ulimit", 58, 2, "i:ii "), - new Syscall ("oldolduname", 59), - new Syscall ("umask", 60, 1, "i:i "), - new Syscall ("chroot", 61, 1, "i:s "), - new Syscall ("ustat", 62, 2, "i:ip "), - new Syscall ("dup2", 63, 2, "i:ii "), - new Syscall ("getppid", 64, 0, "i: "), - new Syscall ("getpgrp", 65, 0, "i: "), - new Syscall ("setsid", 66, 0, "i: "), - new Syscall ("sigaction", 67, 3, "i:ipp "), - new Syscall ("sgetmask", 68), - new Syscall ("ssetmask", 69), - new Syscall ("setreuid", 70, 2, "i:ii "), - new Syscall ("setregid", 71, 2, "i:ii "), - new Syscall ("sigsuspend", 72, 1, "i:p "), - new Syscall ("sigpending", 73, 1, "i:p "), - new Syscall ("sethostname", 74, 2, "i:pi "), - new Syscall ("setrlimit", 75, 2, "i:ip "), - new Syscall ("getrlimit", 76, 2, "i:ip "), - new Syscall ("getrusage", 77, 2, "i:ip "), - new Syscall ("gettimeofday", 78, 2, "i:PP "), - new Syscall ("settimeofday", 79, 2, "i:PP "), - new Syscall ("getgroups", 80, 2, "i:ip "), - new Syscall ("setgroups", 81, 2, "i:ip "), - new Syscall ("select", 82, 5, "i:iPPPP "), - new Syscall ("symlink", 83, 2, "i:ss "), - new Syscall ("oldlstat", 84, 2, "i:pp "), - new Syscall ("readlink", 85, 3, "i:spi "), - new Syscall ("uselib", 86, 1, "i:s "), - new Syscall ("swapon", 87, 2, "i:si "), - new Syscall ("reboot", 88, 1, "i:i "), - new Syscall (89), - new Syscall ("mmap", 90, 6, "b:aniiii "), - new Syscall ("munmap", 91, 2, "i:ai "), - new Syscall ("truncate", 92, 2, "i:si "), - new Syscall ("ftruncate", 93, 2, "i:ii "), - new Syscall ("fchmod", 94, 2, "i:ii "), - new Syscall ("fchown", 95, 3, "i:iii "), - new Syscall ("getpriority", 96, 2, "i:ii "), - new Syscall ("setpriority", 97, 3, "i:iii "), - new Syscall ("profil", 98, 4, "i:piii "), - new Syscall ("statfs", 99, 2, "i:sp "), - new Syscall ("fstatfs", 100, 2, "i:ip "), - new Syscall ("ioperm", 101, 3, "i:iii "), - new Syscall ("socketcall", 102, 2, "i:ip "), - new Syscall ("klogctl", 103, 3, "i:isi "), - new Syscall ("setitimer", 104, 3, "i:ipp "), - new Syscall ("getitimer", 105, 2, "i:ip "), - new Syscall ("sys_stat", 106, 2, "i:sp "), - new Syscall ("sys_lstat", 107, 2, "i:sp "), - new Syscall ("sys_fstat", 108, 2, "i:ip "), - new Syscall ("old_uname", 109, 1, "i:p "), - new Syscall ("iopl", 110, 1, "i:i "), - new Syscall ("vhangup", 111, 1, "i:i "), - new Syscall ("idle", 112, 0, "i: "), - new Syscall (113), - new Syscall ("wait4", 114, 4, "i:iWiP "), - new Syscall ("swapoff", 115, 1, "i:s "), - new Syscall ("sysinfo", 116, 1, "i:p "), - new Syscall ("ipc", 117, 6, "i:iiiipi "), - new Syscall ("fsync", 118, 1, "i:i "), - new Syscall ("sigreturn", 119), - new Syscall ("clone", 120, 2, "i:ip "), - new Syscall ("setdomain", 121, 2, "i:si "), - new Syscall ("uname", 122, 1, "i:p "), - new Syscall ("modify_ldt", 123, 3, "i:ipi "), - new Syscall ("adjtimex", 124, 1, "i:p "), - new Syscall ("mprotect", 125, 3, "i:aii "), - new Syscall ("sigprocmask", 126, 3, "i:ipp "), - new Syscall ("create_module", 127, 3), - new Syscall ("init_module", 128, 5), - new Syscall ("delete_module", 129, 3), - new Syscall ("get_kernel_syms", 130, 1, "i:p "), - new Syscall ("quotactl", 131, 4, "i:isip "), - new Syscall ("getpgid", 132, 1, "i:i "), - new Syscall ("fchdir", 133, 1, "i:i "), - new Syscall ("bdflush", 134, 2, "i:ii "), - new Syscall ("sysfs", 135, 1, "i:i "), - new Syscall ("personality", 136, 1, "i:i "), - new Syscall ("afs_syscall", 137), - new Syscall ("setfsuid", 138, 1, "i:i "), - new Syscall ("setfsgid", 139, 1, "i:i "), - new Syscall ("llseek", 140, 5, "i:iuupi "), - new Syscall ("s_getdents", 141, 3, "i:ipi "), - new Syscall ("select", 142, 5, "i:iPPPP "), - new Syscall ("flock", 143, 2, "i:ii "), - new Syscall ("msync", 144, 3, "i:aii "), - new Syscall ("readv", 145, 3, "i:ipi "), - new Syscall ("writev", 146, 3, "i:ipi "), - new Syscall ("getsid", 147, 1, "i:i "), - new Syscall ("fdatasync", 148, 1, "i:i "), - new Syscall ("sysctl", 149, 1, "i:p "), - new Syscall ("mlock", 150, 2, "i:bn "), - new Syscall ("munlock", 151, 2, "i:ai "), - new Syscall ("mlockall", 152, 1, "i:i "), - new Syscall ("munlockall", 153, 0, "i: "), - new Syscall ("sched_setp", 154, 2, "i:ip "), - new Syscall ("sched_getp", 155, 2, "i:ip "), - new Syscall ("sched_sets", 156, 3, "i:iip "), - new Syscall ("sched_gets", 157, 1, "i:i "), - new Syscall ("sched_yield", 158, 0, "i: "), - new Syscall ("sched_primax", 159, 1, "i:i "), - new Syscall ("sched_primin", 160, 1, "i:i "), - new Syscall ("sched_rr_gi", 161, 2, "i:ip "), - new Syscall ("nanosleep", 162, 2, "i:pp "), - new Syscall ("mremap", 163, 4, "b:aini "), - new Syscall ("setresuid", 164, 3, "i:iii "), - new Syscall ("getresuid", 165, 3, "i:ppp "), - new Syscall ("vm86", 166, 1, "i:p "), - new Syscall ("query_module", 167, 5, "i:sipip "), - new Syscall ("poll", 168, 3, "i:pii "), - new Syscall ("nfsservctl", 169, 3, "i:ipp "), - new Syscall ("setresgid", 170, 3, "i:iii "), - new Syscall ("getresgid", 171, 3, "i:ppp "), - new Syscall ("prctl", 172, 5, "i:iiiii "), - new Syscall ("rt_sigreturn", 173), - new Syscall ("rt_sigaction", 174), - new Syscall ("rt_sigprocmask", 175), - new Syscall ("rt_sigpending", 176), - new Syscall ("rt_sigtimedwait", 177), - new Syscall ("rt_sigqueueinfo", 178), - new Syscall ("rt_sigsuspend", 179), - new Syscall ("pread64", 180), - new Syscall ("pwrite64", 181), - new Syscall ("chown", 182, 3, "i:sii "), - new Syscall ("getcwd", 183, 2, "i:bi "), - new Syscall ("capget", 184, 2, "i:pp "), - new Syscall ("capset", 185, 2, "i:pp "), - new Syscall ("sigaltstack", 186, 2, "i:PP "), - new Syscall ("sendfile", 187, 4, "i:iipi "), - new Syscall ("getpmsg", 188), - new Syscall ("putpmsg", 189), - new Syscall ("vfork", 190, 0, "i: "), - new Syscall ("ugetrlimit", 191), - new Syscall ("mmap", 192, 6, "b:aniiii "), - new Syscall ("truncate64", 193, 3, "i:shl "), - new Syscall ("ftruncate64", 194, 3, "i:ihl "), - new Syscall ("stat64", 195, 2, "i:sp "), - new Syscall ("lstat64", 196, 2, "i:sp "), - new Syscall ("fstat64", 197, 2, "i:ip "), - new Syscall ("lchown32", 198, 3, "i:sii "), - new Syscall ("getuid32", 199), - new Syscall ("getgid32", 200), - new Syscall ("geteuid32", 201), - new Syscall ("getegid32", 202), - new Syscall ("setreuid32", 203, 2, "i:ii "), - new Syscall ("setregid32", 204, 2, "i:ii "), - new Syscall ("getgroups32", 205, 2, "i:ip "), - new Syscall ("setgroups32", 206, 2, "i:ip "), - new Syscall ("fchown32", 207, 3, "i:iii "), - new Syscall ("setresuid32", 208, 3, "i:iii "), - new Syscall ("getresuid32", 209, 3, "i:ppp "), - new Syscall ("setresgid32", 210, 3, "i:iii "), - new Syscall ("getresgid32", 211, 3, "i:ppp "), - new Syscall ("chown32", 212, 3, "i:sii "), - new Syscall ("setuid32", 213, 1, "i:i "), - new Syscall ("setgid32", 214, 1, "i:i "), - new Syscall ("setfsuid32", 215, 1, "i:i "), - new Syscall ("setfsgid32", 216, 1, "i:i "), - new Syscall ("pivot_root", 217, 2, "i:ss "), - new Syscall ("mincore", 218, 3, "i:anV "), - new Syscall ("madvise", 219, 3, "i:pii "), - new Syscall ("getdents64", 220, 3, "i:ipi "), - new Syscall ("fcntl64", 221, 3, "i:iip "), - new Syscall (222), - new Syscall (223), - new Syscall ("gettid", 224, 0), - new Syscall ("readahead", 225, 4, "i:ihli "), - new Syscall ("setxattr", 226), - new Syscall ("lsetxattr", 227), - new Syscall ("fsetxattr", 228), - new Syscall ("getxattr", 229), - new Syscall ("lgetxattr", 230), - new Syscall ("fgetxattr", 231), - new Syscall ("listxattr", 232), - new Syscall ("llistxattr", 233), - new Syscall ("flistxattr", 234), - new Syscall ("removexattr", 235), - new Syscall ("lremovexattr", 236), - new Syscall ("fremovexattr", 237), - new Syscall ("tkill", 238, 2, "i:ii "), - new Syscall ("sendfile64", 239, 4, "i:iipi "), - new Syscall ("futex", 240, 4, "i:piip "), - new Syscall ("sched_setaffinity", 241), - new Syscall ("sched_getaffinity", 242), - new Syscall ("set_thread_area", 243, 1, "i:p "), - new Syscall ("get_thread_area", 244, 1, "i:p "), - new Syscall ("io_setup", 245, 2, "i:ip "), - new Syscall ("io_destroy", 246, 1, "i:i "), - new Syscall ("io_getevents", 247, 5, "i:iiipp "), - new Syscall ("io_submit", 248, 3, "i:iip "), - new Syscall ("io_cancel", 249, 3, "i:ipp "), - new Syscall ("fadvise64", 250), - new Syscall (251), - new Syscall ("exit_group", 252, 1, " :i ", true), - new Syscall ("lookup_dcookie", 253), - new Syscall ("epoll_create", 254), - new Syscall ("epoll_ctl", 255), - new Syscall ("epoll_wait", 256), - new Syscall ("remap_file_pages", 257), - new Syscall ("set_tid_address", 258), - new Syscall ("timer_create", 259), - new Syscall ("timer_settime", 260), - new Syscall ("timer_gettime", 261), - new Syscall ("timer_getoverrun", 262), - new Syscall ("timer_delete", 263), - new Syscall ("clock_settime", 264), - new Syscall ("clock_gettime", 265), - new Syscall ("clock_getres", 266), - new Syscall ("clock_nanosleep", 267), - new Syscall ("statfs64", 268), - new Syscall ("fstatfs64", 269), - new Syscall ("tgkill", 270), - new Syscall ("utimes", 271), - new Syscall ("fadvise64_64", 272), - }; + return syscall; + } } Index: frysk-core/frysk/proc/SyscallEventInfo.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/SyscallEventInfo.java,v retrieving revision 1.4 diff -u -r1.4 SyscallEventInfo.java --- frysk-core/frysk/proc/SyscallEventInfo.java 11 Jul 2006 21:25:25 -0000 1.4 +++ frysk-core/frysk/proc/SyscallEventInfo.java 13 Sep 2006 11:48:37 -0000 @@ -44,11 +44,36 @@ */ public abstract class SyscallEventInfo { - public final static int ENTER = 0; - public final static int EXIT = 1; - public final static int UNKNOWN = -1; + public final static int ENTER = 0; + public final static int EXIT = 1; + public final static int UNKNOWN = -1; + + public abstract int number (Task task); + /** + * getSyscall does everything on the assumption that there is a + * system, and programmer want to know the information about this + * system call. A meaningless Syscall object is returned when + * getSyscall is called at the moment no system call occurs. + * @param task the task that system call occured + * @return the Syscall object + */ + public abstract Syscall getSyscall (Task task); - public abstract int number (Task task); - public abstract long arg (Task task, int n); - public abstract long returnCode (Task task); + /** + * @param task the task that system call occured + * @param n the number of this argument + * @return value of this argument + */ + public long arg (Task task, int n) + { + return getSyscall(task).getArguments(task, n); + } + /** + * @param task the task that system call occured + * @return return value of this system call + */ + public long returnCode (Task task) + { + return getSyscall(task).getReturnCode(task); + } } Index: frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java =================================================================== RCS file: /cvs/frysk/frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java,v retrieving revision 1.4 diff -u -r1.4 SysCallUtilyInfo.java --- frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java 6 Sep 2006 17:43:08 -0000 1.4 +++ frysk-gui/frysk/gui/monitor/observers/SysCallUtilyInfo.java 13 Sep 2006 12:21:13 -0000 @@ -58,8 +58,7 @@ return ""; } - Syscall syscall = Syscall - .syscallByNum(syscallEventInfo.number(task)); + Syscall syscall = syscallEventInfo.getSyscall(task); enterCall = syscall.getName(); if (syscall.numArgs > 0) enterCall += " ("; @@ -119,7 +118,7 @@ return ""; } - Syscall syscall = Syscall.syscallByNum(syscallEventInfo.number(task)); + Syscall syscall = syscallEventInfo.getSyscall(task); returnCall += syscall.getName() + " returns with value "; --- /dev/null 2006-09-01 16:42:34.468363500 +0800 +++ frysk-core/frysk/proc/LinuxPowerPCSyscall.java 2006-09-13 19:41:53.000000000 +0800 @@ -0,0 +1,541 @@ +// This file is part of the program FRYSK. +// +// Copyright 2006 IBM Corp. +// +// FRYSK is free software; you can redistribute it and/or modify it +// under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// FRYSK is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with FRYSK; if not, write to the Free Software Foundation, +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// In addition, as a special exception, Red Hat, Inc. gives You the +// additional right to link the code of FRYSK with code not covered +// under the GNU General Public License ("Non-GPL Code") and to +// distribute linked combinations including the two, subject to the +// limitations in this paragraph. Non-GPL Code permitted under this +// exception must only link to the code of FRYSK through those well +// defined interfaces identified in the file named EXCEPTION found in +// the source code files (the "Approved Interfaces"). The files of +// Non-GPL Code may instantiate templates or use macros or inline +// functions from the Approved Interfaces without causing the +// resulting work to be covered by the GNU General Public +// License. Only Red Hat, Inc. may make changes or additions to the +// list of Approved Interfaces. You must obey the GNU General Public +// License in all respects for all of the FRYSK code and other code +// used in conjunction with FRYSK except the Non-GPL Code covered by +// this exception. If you modify this file, you may extend this +// exception to your version of the file, but you are not obligated to +// do so. If you do not wish to provide this exception without +// modification, you must delete this exception statement from your +// version and license this file solely under the GPL without +// exception. + +package frysk.proc; + +import java.util.HashMap; + +public class LinuxPowerPCSyscall +{ + static final int SOCKET_NUM = 102; + static final int IPC_NUM = 117; + + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + + static class PowerPCSyscall + extends Syscall + { + PowerPCSyscall (String name, int number, int numArgs, + String argList, boolean noreturn) + { + super (name, number, numArgs, argList, noreturn); + } + PowerPCSyscall (String name, int number, int numArgs, String argList) + { + super (name, number, numArgs, argList); + } + PowerPCSyscall (String name, int number, int numArgs) + { + super (name, number, numArgs); + } + PowerPCSyscall (String name, int number) + { + super (name, number); + } + PowerPCSyscall (int number) + { + super (number); + } + + public long getArguments (Task task, int n) + { + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + + switch (n) + { + case 0: + return isa.getRegisterByName("gpr0").get(task); + case 1: + return isa.getRegisterByName("orig_r3").get(task); + case 2: + return isa.getRegisterByName("gpr4").get(task); + case 3: + return isa.getRegisterByName("gpr5").get(task); + case 4: + return isa.getRegisterByName("gpr6").get(task); + case 5: + return isa.getRegisterByName("gpr7").get(task); + case 6: + return isa.getRegisterByName("gpr8").get(task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + public long getReturnCode (Task task) + { + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + + int flag = (int) isa.getRegisterByName("ccr").get(task); + + if ((flag & 0x10000000) != 0) + return -isa.getRegisterByName("gpr3").get(task); + else + return isa.getRegisterByName("gpr3").get(task); + } + } + + static Syscall[] syscallList = { + new PowerPCSyscall (0), + new PowerPCSyscall ("write", 1, 3, "i:ibn "), + new PowerPCSyscall ("open", 2, 3, "i:siv "), + new PowerPCSyscall ("read", 3, 3, "i:ibn "), + new PowerPCSyscall ("write", 4, 3, "i:ibn "), + new PowerPCSyscall ("open", 5, 3, "i:siv "), + new PowerPCSyscall ("close", 6, 1, "i:i "), + new PowerPCSyscall ("waitpid", 7, 3, "i:ipi "), + new PowerPCSyscall ("creat", 8, 2, "i:sv"), + new PowerPCSyscall ("link", 9, 2, "i:ss "), + new PowerPCSyscall ("unlink", 10, 1, "i:s "), + new PowerPCSyscall ("execve", 11, 3, "i:ppp "), + new PowerPCSyscall ("chdir", 12, 1, "i:s "), + new PowerPCSyscall ("time", 13, 1, "i:P "), + new PowerPCSyscall ("mknod", 14), + new PowerPCSyscall ("chmod", 15, 2, "i:si "), + new PowerPCSyscall ("lchown", 16, 3, "i:sii "), + new PowerPCSyscall ("break", 17 ), + new PowerPCSyscall ("oldstat", 18), + new PowerPCSyscall ("lseek", 19, 3, "i:iii "), + new PowerPCSyscall ("getpid", 20, 0, "i: "), + new PowerPCSyscall ("mount", 21, 5, "i:sssip "), + new PowerPCSyscall ("umount", 22, 1, "i:s "), + new PowerPCSyscall ("setuid", 23, 1, "i:i "), + new PowerPCSyscall ("getuid", 24, 0, "i: "), + new PowerPCSyscall ("stime", 25, 1, "i:p "), + new PowerPCSyscall ("ptrace", 26, 4, "i:iiii "), + new PowerPCSyscall ("alarm", 27, 1, "i:i "), + new PowerPCSyscall ("oldfstat", 28), + new PowerPCSyscall ("pause", 29, 0, "i: "), + new PowerPCSyscall ("utime", 30, 2, "i:sP "), + new PowerPCSyscall ("stty", 31), + new PowerPCSyscall ("gtty", 32), + new PowerPCSyscall ("access", 33, 2, "i:si "), + new PowerPCSyscall ("nice", 34, 1, "i:i "), + new PowerPCSyscall ("ftime", 35, 1, "i:p "), + new PowerPCSyscall ("sync", 36, 0, "i: "), + new PowerPCSyscall ("kill", 37, 2, "i:ii "), + new PowerPCSyscall ("rename", 38, 2, "i:ss "), + new PowerPCSyscall ("mkdir", 39, 2, "i:si "), + new PowerPCSyscall ("rmdir", 40, 1, "i:s "), + new PowerPCSyscall ("dup", 41, 1, "i:i "), + new PowerPCSyscall ("pipe", 42, 1, "i:f "), + new PowerPCSyscall ("times", 43, 1, "i:p "), + new PowerPCSyscall ("prof", 44), + new PowerPCSyscall ("brk", 45, 1, "i:p "), + new PowerPCSyscall ("setgid", 46, 1, "i:i "), + new PowerPCSyscall ("getgid", 47, 0, "i: "), + new PowerPCSyscall ("signal", 48, 2, "i:ii "), + new PowerPCSyscall ("geteuid", 49, 0, "i: "), + new PowerPCSyscall ("getegid", 50, 0, "i: "), + new PowerPCSyscall ("acct", 51, 1, "i:S "), + new PowerPCSyscall ("umount2", 52, 2, "i:si "), + new PowerPCSyscall ("lock", 53), + new PowerPCSyscall ("ioctl", 54, 3, "i:iiI "), + new PowerPCSyscall ("fcntl", 55, 3, "i:iiF "), + new PowerPCSyscall ("mpx", 56), + new PowerPCSyscall ("setpgid", 57, 2, "i:ii "), + new PowerPCSyscall ("ulimit", 58, 2, "i:ii "), + new PowerPCSyscall ("oldolduname", 59), + new PowerPCSyscall ("umask", 60, 1, "i:i "), + new PowerPCSyscall ("chroot", 61, 1, "i:s "), + new PowerPCSyscall ("ustat", 62, 2, "i:ip "), + new PowerPCSyscall ("dup2", 63, 2, "i:ii "), + new PowerPCSyscall ("getppid", 64, 0, "i: "), + new PowerPCSyscall ("getpgrp", 65, 0, "i: "), + new PowerPCSyscall ("setsid", 66, 0, "i: "), + new PowerPCSyscall ("sigaction", 67, 3, "i:ipp "), + new PowerPCSyscall ("sgetmask", 68), + new PowerPCSyscall ("ssetmask", 69), + new PowerPCSyscall ("setreuid", 70, 2, "i:ii "), + new PowerPCSyscall ("setregid", 71, 2, "i:ii "), + new PowerPCSyscall ("sigsuspend", 72, 1, "i:p "), + new PowerPCSyscall ("sigpending", 73, 1, "i:p "), + new PowerPCSyscall ("sethostname", 74, 2, "i:pi "), + new PowerPCSyscall ("setrlimit", 75, 2, "i:ip "), + new PowerPCSyscall ("getrlimit", 76, 2, "i:ip "), + new PowerPCSyscall ("getrusage", 77, 2, "i:ip "), + new PowerPCSyscall ("gettimeofday", 78, 2, "i:PP "), + new PowerPCSyscall ("settimeofday", 79, 2, "i:PP "), + new PowerPCSyscall ("getgroups", 80, 2, "i:ip "), + new PowerPCSyscall ("setgroups", 81, 2, "i:ip "), + new PowerPCSyscall ("select", 82, 5, "i:iPPPP "), + new PowerPCSyscall ("symlink", 83, 2, "i:ss "), + new PowerPCSyscall ("oldlstat", 84, 2, "i:pp "), + new PowerPCSyscall ("readlink", 85, 3, "i:spi "), + new PowerPCSyscall ("uselib", 86, 1, "i:s "), + new PowerPCSyscall ("swapon", 87, 2, "i:si "), + new PowerPCSyscall ("reboot", 88, 1, "i:i "), + new PowerPCSyscall ("readdir", 89), + new PowerPCSyscall ("mmap", 90, 6, "b:aniiii "), + new PowerPCSyscall ("munmap", 91, 2, "i:ai "), + new PowerPCSyscall ("truncate", 92, 2, "i:si "), + new PowerPCSyscall ("ftruncate", 93, 2, "i:ii "), + new PowerPCSyscall ("fchmod", 94, 2, "i:ii "), + new PowerPCSyscall ("fchown", 95, 3, "i:iii "), + new PowerPCSyscall ("getpriority", 96, 2, "i:ii "), + new PowerPCSyscall ("setpriority", 97, 3, "i:iii "), + new PowerPCSyscall ("profil", 98, 4, "i:piii "), + new PowerPCSyscall ("statfs", 99, 2, "i:sp "), + new PowerPCSyscall ("fstatfs", 100, 2, "i:ip "), + new PowerPCSyscall ("ioperm", 101, 3, "i:iii "), + new PowerPCSyscall ("socketcall", 102, 2, "i:ip "), + new PowerPCSyscall ("syslog", 103), + new PowerPCSyscall ("setitimer", 104, 3, "i:ipp "), + new PowerPCSyscall ("getitimer", 105, 2, "i:ip "), + new PowerPCSyscall ("stat", 106), + new PowerPCSyscall ("lstat", 107), + new PowerPCSyscall ("fstat", 108), + new PowerPCSyscall ("olduname", 109), + new PowerPCSyscall ("iopl", 110, 1, "i:i "), + new PowerPCSyscall ("vhangup", 111, 1, "i:i "), + new PowerPCSyscall ("idle", 112, 0, "i: "), + new PowerPCSyscall ("vm86", 113, 1, "i:p "), + new PowerPCSyscall ("wait4", 114, 4, "i:iWiP "), + new PowerPCSyscall ("swapoff", 115, 1, "i:s "), + new PowerPCSyscall ("sysinfo", 116, 1, "i:p "), + new PowerPCSyscall ("ipc", 117, 6, "i:iiiipi "), + new PowerPCSyscall ("fsync", 118, 1, "i:i "), + new PowerPCSyscall ("sigreturn", 119), + new PowerPCSyscall ("clone", 120, 2, "i:ip "), + new PowerPCSyscall ("setdomainname", 121), + new PowerPCSyscall ("uname", 122, 1, "i:p "), + new PowerPCSyscall ("modify_ldt", 123, 3, "i:ipi "), + new PowerPCSyscall ("adjtimex", 124, 1, "i:p "), + new PowerPCSyscall ("mprotect", 125, 3, "i:aii "), + new PowerPCSyscall ("sigprocmask", 126, 3, "i:ipp "), + new PowerPCSyscall ("create_module", 127, 3), + new PowerPCSyscall ("init_module", 128, 5), + new PowerPCSyscall ("delete_module", 129, 3), + new PowerPCSyscall ("get_kernel_syms", 130, 1, "i:p "), + new PowerPCSyscall ("quotactl", 131, 4, "i:isip "), + new PowerPCSyscall ("getpgid", 132, 1, "i:i "), + new PowerPCSyscall ("fchdir", 133, 1, "i:i "), + new PowerPCSyscall ("bdflush", 134, 2, "i:ii "), + new PowerPCSyscall ("sysfs", 135, 1, "i:i "), + new PowerPCSyscall ("personality", 136, 1, "i:i "), + new PowerPCSyscall ("afs_syscall", 137), + new PowerPCSyscall ("setfsuid", 138, 1, "i:i "), + new PowerPCSyscall ("setfsgid", 139, 1, "i:i "), + new PowerPCSyscall ("_llseek", 140), + new PowerPCSyscall ("getdents", 141), + new PowerPCSyscall ("_newselect", 142), + new PowerPCSyscall ("flock", 143, 2, "i:ii "), + new PowerPCSyscall ("msync", 144, 3, "i:aii "), + new PowerPCSyscall ("readv", 145, 3, "i:ipi "), + new PowerPCSyscall ("writev", 146, 3, "i:ipi "), + new PowerPCSyscall ("getsid", 147, 1, "i:i "), + new PowerPCSyscall ("fdatasync", 148, 1, "i:i "), + new PowerPCSyscall ("_sysctl", 149), + new PowerPCSyscall ("mlock", 150, 2, "i:bn "), + new PowerPCSyscall ("munlock", 151, 2, "i:ai "), + new PowerPCSyscall ("mlockall", 152, 1, "i:i "), + new PowerPCSyscall ("munlockall", 153, 0, "i: "), + new PowerPCSyscall ("sched_setparam", 154), + new PowerPCSyscall ("sched_getparam", 155), + new PowerPCSyscall ("sched_setscheduler", 156), + new PowerPCSyscall ("sched_getscheduler", 157), + new PowerPCSyscall ("sched_yield", 158, 0, "i: "), + new PowerPCSyscall ("sched_get_priority_max", 159), + new PowerPCSyscall ("sched_get_priority_min", 160), + new PowerPCSyscall ("sched_rr_get_interval", 161), + new PowerPCSyscall ("nanosleep", 162, 2, "i:pp "), + new PowerPCSyscall ("mremap", 163, 4, "b:aini "), + new PowerPCSyscall ("setresuid", 164, 3, "i:iii "), + new PowerPCSyscall ("getresuid", 165, 3, "i:ppp "), + new PowerPCSyscall ("query_module", 166, 5, "i:sipip "), + new PowerPCSyscall ("poll", 167, 3, "i:pii "), + new PowerPCSyscall ("nfsservctl", 168, 3, "i:ipp "), + new PowerPCSyscall ("setresgid", 169, 3, "i:iii "), + new PowerPCSyscall ("getresgid", 170, 3, "i:ppp "), + new PowerPCSyscall ("prctl", 171, 5, "i:iiiii "), + new PowerPCSyscall ("rt_sigreturn", 172), + new PowerPCSyscall ("rt_sigaction", 173), + new PowerPCSyscall ("rt_sigprocmask", 174), + new PowerPCSyscall ("rt_sigpending", 175), + new PowerPCSyscall ("rt_sigtimedwait", 176), + new PowerPCSyscall ("rt_sigqueueinfo", 177), + new PowerPCSyscall ("rt_sigsuspend", 178), + new PowerPCSyscall ("pread64", 179), + new PowerPCSyscall ("pwrite64", 180), + new PowerPCSyscall ("chown", 181, 3, "i:sii "), + new PowerPCSyscall ("getcwd", 182, 2, "i:bi "), + new PowerPCSyscall ("capget", 183, 2, "i:pp "), + new PowerPCSyscall ("capset", 184, 2, "i:pp "), + new PowerPCSyscall ("sigaltstack", 185, 2, "i:PP "), + new PowerPCSyscall ("sendfile", 186, 4, "i:iipi "), + new PowerPCSyscall ("getpmsg", 187), + new PowerPCSyscall ("putpmsg", 188), + new PowerPCSyscall ("vfork", 189, 0, "i: "), + new PowerPCSyscall ("ugetrlimit", 190), + new PowerPCSyscall ("readahead", 191, 4, "i:ihli "), + new PowerPCSyscall ("mmap2", 192), + new PowerPCSyscall ("truncate64", 193, 3, "i:shl "), + new PowerPCSyscall ("ftruncate64", 194, 3, "i:ihl "), + new PowerPCSyscall ("stat64", 195, 2, "i:sp "), + new PowerPCSyscall ("lstat64", 196, 2, "i:sp "), + new PowerPCSyscall ("fstat64", 197, 2, "i:ip "), + new PowerPCSyscall ("pciconfig_read", 198), + new PowerPCSyscall ("pciconfig_write", 199), + new PowerPCSyscall ("pciconfig_iobase", 200), + new PowerPCSyscall ("multiplexer", 201), + new PowerPCSyscall ("getdents64", 202, 3, "i:ipi "), + new PowerPCSyscall ("pivot_root", 203, 2, "i:ss "), + new PowerPCSyscall ("fcntl64", 204, 3, "i:iip "), + new PowerPCSyscall ("madvise", 205, 3, "i:pii "), + new PowerPCSyscall ("mincore", 206, 3, "i:anV "), + new PowerPCSyscall ("gettid", 207, 0), + new PowerPCSyscall ("tkill", 208, 2, "i:ii "), + new PowerPCSyscall ("setxattr", 209), + new PowerPCSyscall ("lsetxattr", 210), + new PowerPCSyscall ("fsetxattr", 211), + new PowerPCSyscall ("getxattr", 212), + new PowerPCSyscall ("lgetxattr", 213), + new PowerPCSyscall ("fgetxattr", 214), + new PowerPCSyscall ("listxattr", 215), + new PowerPCSyscall ("llistxattr", 216), + new PowerPCSyscall ("flistxattr", 217), + new PowerPCSyscall ("removexattr", 218), + new PowerPCSyscall ("lremovexattr", 219), + new PowerPCSyscall ("fremovexattr", 220), + new PowerPCSyscall ("futex", 221, 4, "i:piip "), + new PowerPCSyscall ("sched_setaffinity", 222), + new PowerPCSyscall ("sched_getaffinity", 223), + new PowerPCSyscall (224), + new PowerPCSyscall (225), + new PowerPCSyscall ("sendfile64", 226, 4, "i:iipi "), + new PowerPCSyscall ("io_setup", 227, 2, "i:ip "), + new PowerPCSyscall ("io_destroy", 228, 1, "i:i "), + new PowerPCSyscall ("io_getevents", 229, 5, "i:iiipp "), + new PowerPCSyscall ("io_submit", 230, 3, "i:iip "), + new PowerPCSyscall ("io_cancel", 231, 3, "i:ipp "), + new PowerPCSyscall ("set_tid_address", 232), + new PowerPCSyscall ("fadvise64", 233), + new PowerPCSyscall ("exit_group", 234, 1, " :i "), + new PowerPCSyscall ("lookup_dcookie", 235), + new PowerPCSyscall ("epoll_create", 236), + new PowerPCSyscall ("epoll_ctl", 237), + new PowerPCSyscall ("epoll_wait", 238), + new PowerPCSyscall ("remap_file_pages", 239), + new PowerPCSyscall ("timer_create", 240), + new PowerPCSyscall ("timer_settime", 241), + new PowerPCSyscall ("timer_gettime", 242), + new PowerPCSyscall ("timer_getoverrun", 243), + new PowerPCSyscall ("timer_delete", 244), + new PowerPCSyscall ("clock_settime", 245), + new PowerPCSyscall ("clock_gettime", 246), + new PowerPCSyscall ("clock_getres", 247), + new PowerPCSyscall ("clock_nanosleep", 248), + new PowerPCSyscall ("swapcontext", 249), + new PowerPCSyscall ("tgkill", 250), + new PowerPCSyscall ("utimes", 251), + new PowerPCSyscall ("statfs64", 252 ), + new PowerPCSyscall ("fstatfs64", 253), + new PowerPCSyscall ("fadvise64_64", 254), + new PowerPCSyscall ("rtas", 255), + new PowerPCSyscall ("sys_debug_setcontext", 256), + new PowerPCSyscall (257), + new PowerPCSyscall (258), + new PowerPCSyscall (259), + new PowerPCSyscall ("get_mempolicy", 260), + new PowerPCSyscall ("set_mempolicy", 261), + new PowerPCSyscall ("mq_open", 262), + new PowerPCSyscall ("mq_unlink", 263), + new PowerPCSyscall ("mq_timedsend", 264), + new PowerPCSyscall ("mq_timedreceive", 265), + new PowerPCSyscall ("mq_notify", 266), + new PowerPCSyscall ("mq_getsetattr", 267), + new PowerPCSyscall ("kexec_load", 268), + new PowerPCSyscall ("add_key", 269), + new PowerPCSyscall ("request_key", 270), + new PowerPCSyscall ("keyctl", 271), + new PowerPCSyscall ("waitid", 272), + new PowerPCSyscall ("ioprio_set", 273), + new PowerPCSyscall ("ioprio_get", 274), + new PowerPCSyscall ("inotify_init", 275), + new PowerPCSyscall ("inotify_add_watch", 276), + new PowerPCSyscall ("inotify_rm_watch", 277), + new PowerPCSyscall ("syscalls", 278) + }; + + static class SocketSubSyscall + extends PowerPCSyscall + { + SocketSubSyscall (String name, int number) + { + super (name, number); + } + SocketSubSyscall (String name, int number, int numArgs, String argList) + { + super (name, number, numArgs, argList); + } + public long getArguments (Task task, int n) + { + /** Arguments in socket subcalls are dereferenced. */ + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + long base = isa.getRegisterByName("gpr4").get (task); + + // FIXME: There are some bi-arch issues + return task.memory.getInt(base + (n-1) * isa.getWordSize()); + } + } + + static Syscall[] socketSubcallList = { + new SocketSubSyscall ("", SOCKET_NUM), + new SocketSubSyscall ("socket", SOCKET_NUM, 3, "i:iii"), + new SocketSubSyscall ("bind", SOCKET_NUM, 3, "i:ipi "), + new SocketSubSyscall ("connect", SOCKET_NUM, 3, "i:ipi "), + new SocketSubSyscall ("listen", SOCKET_NUM, 2, "i:ii "), + new SocketSubSyscall ("accept", SOCKET_NUM, 3, "i:ipp "), + new SocketSubSyscall ("getsockname",SOCKET_NUM, 3, "i:ipp "), + new SocketSubSyscall ("getpeername",SOCKET_NUM, 4, "i:iiip "), + new SocketSubSyscall ("socketpair", SOCKET_NUM, 4, "i:iiip "), + new SocketSubSyscall ("send", SOCKET_NUM, 4, "i:ipii "), + new SocketSubSyscall ("recv", SOCKET_NUM, 4, "i:ipii "), + new SocketSubSyscall ("sendto", SOCKET_NUM, 6, "i:ipiipi"), + new SocketSubSyscall ("recvfrom", SOCKET_NUM, 6, "i:ipiipp "), + new SocketSubSyscall ("shutdown", SOCKET_NUM, 2, "i:ii "), + new SocketSubSyscall ("setsockopt", SOCKET_NUM, 5, "i:iiipp "), + new SocketSubSyscall ("getsockopt", SOCKET_NUM, 5, "i:iiipp "), + new SocketSubSyscall ("sendmsg", SOCKET_NUM, 5, "i:iiipp "), + new SocketSubSyscall ("recvmsg", SOCKET_NUM, 5, "i:iiipp ") + }; + + + static class IpcSubSyscall + extends PowerPCSyscall + { + IpcSubSyscall (String name, int number) + { + super (name, number); + } + IpcSubSyscall (String name, int number, int numArgs, String argList) + { + super (name, number, numArgs, argList); + } + + public long getArguments (Task task, int n) + { + if (n == 0) + return super.getArguments (task, 0); + else + // these arguements are shifted by one. + return super.getArguments (task, n+1); + } + + } + static Syscall[] ipcSubcallList = { + new IpcSubSyscall ("semop", IPC_NUM), + new IpcSubSyscall("semget", IPC_NUM), + new IpcSubSyscall("semctl", IPC_NUM), + new IpcSubSyscall("semtimedop", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("msgsnd", IPC_NUM), + new IpcSubSyscall("msgrcv", IPC_NUM), + new IpcSubSyscall("msgget", IPC_NUM), + new IpcSubSyscall("msgctl", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("", IPC_NUM), + new IpcSubSyscall("shmat", IPC_NUM), + new IpcSubSyscall("shmdt", IPC_NUM), + new IpcSubSyscall("shmget", IPC_NUM), + new IpcSubSyscall("shmctl", IPC_NUM) + }; + + public static Syscall syscallByNum (Task task, int number) + { + if (number != SOCKET_NUM && number != IPC_NUM) + return Syscall.syscallByNum (number, task); + else + { + /** sub syscall number is in . */ + int subSyscallNumber = 0; + try + { + subSyscallNumber = (int) task.getIsa().getRegisterByName("orig_r3").get(task); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + + if (number == SOCKET_NUM) + { + return socketSubcallList[subSyscallNumber]; + } + else + { + return ipcSubcallList[subSyscallNumber]; + } + } + } +} --- /dev/null 2006-09-01 16:42:34.468363500 +0800 +++ frysk-core/frysk/proc/LinuxIa32Syscall.java 2006-09-13 17:12:51.000000000 +0800 @@ -0,0 +1,531 @@ +// This file is part of the program FRYSK. +// +// Copyright 2006 Red Hat Inc. +// +// FRYSK is free software; you can redistribute it and/or modify it +// under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// FRYSK is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with FRYSK; if not, write to the Free Software Foundation, +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// In addition, as a special exception, Red Hat, Inc. gives You the +// additional right to link the code of FRYSK with code not covered +// under the GNU General Public License ("Non-GPL Code") and to +// distribute linked combinations including the two, subject to the +// limitations in this paragraph. Non-GPL Code permitted under this +// exception must only link to the code of FRYSK through those well +// defined interfaces identified in the file named EXCEPTION found in +// the source code files (the "Approved Interfaces"). The files of +// Non-GPL Code may instantiate templates or use macros or inline +// functions from the Approved Interfaces without causing the +// resulting work to be covered by the GNU General Public +// License. Only Red Hat, Inc. may make changes or additions to the +// list of Approved Interfaces. You must obey the GNU General Public +// License in all respects for all of the FRYSK code and other code +// used in conjunction with FRYSK except the Non-GPL Code covered by +// this exception. If you modify this file, you may extend this +// exception to your version of the file, but you are not obligated to +// do so. If you do not wish to provide this exception without +// modification, you must delete this exception statement from your +// version and license this file solely under the GPL without +// exception. + +package frysk.proc; + +import java.util.HashMap; + +public class LinuxIa32Syscall +{ + static final int SOCKET_NUM = 102; + static final int IPC_NUM = 117; + + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + + static class Ia32Syscall + extends Syscall + { + Ia32Syscall (String name, int number, int numArgs, + String argList, boolean noreturn) + { + super (name, number, numArgs, argList, noreturn); + } + Ia32Syscall (String name, int number, int numArgs, String argList) + { + super (name, number, numArgs, argList); + } + Ia32Syscall (String name, int number, int numArgs) + { + super (name, number, numArgs); + } + Ia32Syscall (String name, int number) + { + super (name, number); + } + Ia32Syscall (int number) + { + super (number); + } + + public long getArguments (Task task, int n) + { + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + + switch (n) + { + case 0: + return isa.getRegisterByName ("orig_eax").get (task); + case 1: + return isa.getRegisterByName("ebx").get (task); + case 2: + return isa.getRegisterByName("ecx").get (task); + case 3: + return isa.getRegisterByName("edx").get (task); + case 4: + return isa.getRegisterByName("esi").get (task); + case 5: + return isa.getRegisterByName("edi").get (task); + case 6: + return isa.getRegisterByName("eax").get (task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + public long getReturnCode (Task task) + { + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + return isa.getRegisterByName ("eax").get (task); + } + } + + static Syscall[] syscallList = { + new Ia32Syscall (0), + new Ia32Syscall ("exit", 1, 1), + new Ia32Syscall ("fork", 2, 0, "i: "), + new Ia32Syscall ("read", 3, 3, "i:ibn "), + new Ia32Syscall ("write", 4, 3, "i:ibn "), + new Ia32Syscall ("open", 5, 3, "i:siv "), + new Ia32Syscall ("close", 6, 1, "i:i "), + new Ia32Syscall ("waitpid", 7, 3, "i:ipi "), + new Ia32Syscall ("creat", 8, 2, "i:sv"), + new Ia32Syscall ("link", 9, 2, "i:ss "), + new Ia32Syscall ("unlink", 10, 1, "i:s "), + new Ia32Syscall ("execve", 11, 3, "i:ppp "), + new Ia32Syscall ("chdir", 12, 1, "i:s "), + new Ia32Syscall ("time", 13, 1, "i:P "), + new Ia32Syscall ("sys_mknod", 14, 3, "i:sii "), + new Ia32Syscall ("chmod", 15, 2, "i:si "), + new Ia32Syscall ("lchown", 16, 3, "i:sii "), + new Ia32Syscall ("break", 17), + new Ia32Syscall ("old_stat", 18, 3, "i:pp "), + new Ia32Syscall ("lseek", 19, 3, "i:iii "), + new Ia32Syscall ("getpid", 20, 0, "i: "), + new Ia32Syscall ("mount", 21, 5, "i:sssip "), + new Ia32Syscall ("umount", 22, 1, "i:s "), + new Ia32Syscall ("setuid", 23, 1, "i:i "), + new Ia32Syscall ("getuid", 24, 0, "i: "), + new Ia32Syscall ("stime", 25, 1, "i:p "), + new Ia32Syscall ("ptrace", 26, 4, "i:iiii "), + new Ia32Syscall ("alarm", 27, 1, "i:i "), + new Ia32Syscall ("old_fstat", 28, 2, "i:ip "), + new Ia32Syscall ("pause", 29, 0, "i: "), + new Ia32Syscall ("utime", 30, 2, "i:sP "), + new Ia32Syscall ("stty", 31), + new Ia32Syscall ("gtty", 32), + new Ia32Syscall ("access", 33, 2, "i:si "), + new Ia32Syscall ("nice", 34, 1, "i:i "), + new Ia32Syscall ("ftime", 35, 1, "i:p "), + new Ia32Syscall ("sync", 36, 0, "i: "), + new Ia32Syscall ("kill", 37, 2, "i:ii "), + new Ia32Syscall ("rename", 38, 2, "i:ss "), + new Ia32Syscall ("mkdir", 39, 2, "i:si "), + new Ia32Syscall ("rmdir", 40, 1, "i:s "), + new Ia32Syscall ("dup", 41, 1, "i:i "), + new Ia32Syscall ("pipe", 42, 1, "i:f "), + new Ia32Syscall ("times", 43, 1, "i:p "), + new Ia32Syscall ("prof", 44), + new Ia32Syscall ("brk", 45, 1, "i:p "), + new Ia32Syscall ("setgid", 46, 1, "i:i "), + new Ia32Syscall ("getgid", 47, 0, "i: "), + new Ia32Syscall ("signal", 48, 2, "i:ii "), + new Ia32Syscall ("geteuid", 49, 0, "i: "), + new Ia32Syscall ("getegid", 50, 0, "i: "), + new Ia32Syscall ("acct", 51, 1, "i:S "), + new Ia32Syscall ("umount2", 52, 2, "i:si "), + new Ia32Syscall ("lock", 53), + new Ia32Syscall ("ioctl", 54, 3, "i:iiI "), + new Ia32Syscall ("fcntl", 55, 3, "i:iiF "), + new Ia32Syscall ("mpx", 56), + new Ia32Syscall ("setpgid", 57, 2, "i:ii "), + new Ia32Syscall ("ulimit", 58, 2, "i:ii "), + new Ia32Syscall ("oldolduname", 59), + new Ia32Syscall ("umask", 60, 1, "i:i "), + new Ia32Syscall ("chroot", 61, 1, "i:s "), + new Ia32Syscall ("ustat", 62, 2, "i:ip "), + new Ia32Syscall ("dup2", 63, 2, "i:ii "), + new Ia32Syscall ("getppid", 64, 0, "i: "), + new Ia32Syscall ("getpgrp", 65, 0, "i: "), + new Ia32Syscall ("setsid", 66, 0, "i: "), + new Ia32Syscall ("sigaction", 67, 3, "i:ipp "), + new Ia32Syscall ("sgetmask", 68), + new Ia32Syscall ("ssetmask", 69), + new Ia32Syscall ("setreuid", 70, 2, "i:ii "), + new Ia32Syscall ("setregid", 71, 2, "i:ii "), + new Ia32Syscall ("sigsuspend", 72, 1, "i:p "), + new Ia32Syscall ("sigpending", 73, 1, "i:p "), + new Ia32Syscall ("sethostname", 74, 2, "i:pi "), + new Ia32Syscall ("setrlimit", 75, 2, "i:ip "), + new Ia32Syscall ("getrlimit", 76, 2, "i:ip "), + new Ia32Syscall ("getrusage", 77, 2, "i:ip "), + new Ia32Syscall ("gettimeofday", 78, 2, "i:PP "), + new Ia32Syscall ("settimeofday", 79, 2, "i:PP "), + new Ia32Syscall ("getgroups", 80, 2, "i:ip "), + new Ia32Syscall ("setgroups", 81, 2, "i:ip "), + new Ia32Syscall ("select", 82, 5, "i:iPPPP "), + new Ia32Syscall ("symlink", 83, 2, "i:ss "), + new Ia32Syscall ("oldlstat", 84, 2, "i:pp "), + new Ia32Syscall ("readlink", 85, 3, "i:spi "), + new Ia32Syscall ("uselib", 86, 1, "i:s "), + new Ia32Syscall ("swapon", 87, 2, "i:si "), + new Ia32Syscall ("reboot", 88, 1, "i:i "), + new Ia32Syscall (89), + new Ia32Syscall ("mmap", 90, 6, "b:aniiii "), + new Ia32Syscall ("munmap", 91, 2, "i:ai "), + new Ia32Syscall ("truncate", 92, 2, "i:si "), + new Ia32Syscall ("ftruncate", 93, 2, "i:ii "), + new Ia32Syscall ("fchmod", 94, 2, "i:ii "), + new Ia32Syscall ("fchown", 95, 3, "i:iii "), + new Ia32Syscall ("getpriority", 96, 2, "i:ii "), + new Ia32Syscall ("setpriority", 97, 3, "i:iii "), + new Ia32Syscall ("profil", 98, 4, "i:piii "), + new Ia32Syscall ("statfs", 99, 2, "i:sp "), + new Ia32Syscall ("fstatfs", 100, 2, "i:ip "), + new Ia32Syscall ("ioperm", 101, 3, "i:iii "), + new Ia32Syscall ("socketcall", 102, 2, "i:ip "), + new Ia32Syscall ("klogctl", 103, 3, "i:isi "), + new Ia32Syscall ("setitimer", 104, 3, "i:ipp "), + new Ia32Syscall ("getitimer", 105, 2, "i:ip "), + new Ia32Syscall ("sys_stat", 106, 2, "i:sp "), + new Ia32Syscall ("sys_lstat", 107, 2, "i:sp "), + new Ia32Syscall ("sys_fstat", 108, 2, "i:ip "), + new Ia32Syscall ("old_uname", 109, 1, "i:p "), + new Ia32Syscall ("iopl", 110, 1, "i:i "), + new Ia32Syscall ("vhangup", 111, 1, "i:i "), + new Ia32Syscall ("idle", 112, 0, "i: "), + new Ia32Syscall (113), + new Ia32Syscall ("wait4", 114, 4, "i:iWiP "), + new Ia32Syscall ("swapoff", 115, 1, "i:s "), + new Ia32Syscall ("sysinfo", 116, 1, "i:p "), + new Ia32Syscall ("ipc", 117, 6, "i:iiiipi "), + new Ia32Syscall ("fsync", 118, 1, "i:i "), + new Ia32Syscall ("sigreturn", 119), + new Ia32Syscall ("clone", 120, 2, "i:ip "), + new Ia32Syscall ("setdomain", 121, 2, "i:si "), + new Ia32Syscall ("uname", 122, 1, "i:p "), + new Ia32Syscall ("modify_ldt", 123, 3, "i:ipi "), + new Ia32Syscall ("adjtimex", 124, 1, "i:p "), + new Ia32Syscall ("mprotect", 125, 3, "i:aii "), + new Ia32Syscall ("sigprocmask", 126, 3, "i:ipp "), + new Ia32Syscall ("create_module", 127, 3), + new Ia32Syscall ("init_module", 128, 5), + new Ia32Syscall ("delete_module", 129, 3), + new Ia32Syscall ("get_kernel_syms", 130, 1, "i:p "), + new Ia32Syscall ("quotactl", 131, 4, "i:isip "), + new Ia32Syscall ("getpgid", 132, 1, "i:i "), + new Ia32Syscall ("fchdir", 133, 1, "i:i "), + new Ia32Syscall ("bdflush", 134, 2, "i:ii "), + new Ia32Syscall ("sysfs", 135, 1, "i:i "), + new Ia32Syscall ("personality", 136, 1, "i:i "), + new Ia32Syscall ("afs_syscall", 137), + new Ia32Syscall ("setfsuid", 138, 1, "i:i "), + new Ia32Syscall ("setfsgid", 139, 1, "i:i "), + new Ia32Syscall ("llseek", 140, 5, "i:iuupi "), + new Ia32Syscall ("s_getdents", 141, 3, "i:ipi "), + new Ia32Syscall ("select", 142, 5, "i:iPPPP "), + new Ia32Syscall ("flock", 143, 2, "i:ii "), + new Ia32Syscall ("msync", 144, 3, "i:aii "), + new Ia32Syscall ("readv", 145, 3, "i:ipi "), + new Ia32Syscall ("writev", 146, 3, "i:ipi "), + new Ia32Syscall ("getsid", 147, 1, "i:i "), + new Ia32Syscall ("fdatasync", 148, 1, "i:i "), + new Ia32Syscall ("sysctl", 149, 1, "i:p "), + new Ia32Syscall ("mlock", 150, 2, "i:bn "), + new Ia32Syscall ("munlock", 151, 2, "i:ai "), + new Ia32Syscall ("mlockall", 152, 1, "i:i "), + new Ia32Syscall ("munlockall", 153, 0, "i: "), + new Ia32Syscall ("sched_setp", 154, 2, "i:ip "), + new Ia32Syscall ("sched_getp", 155, 2, "i:ip "), + new Ia32Syscall ("sched_sets", 156, 3, "i:iip "), + new Ia32Syscall ("sched_gets", 157, 1, "i:i "), + new Ia32Syscall ("sched_yield", 158, 0, "i: "), + new Ia32Syscall ("sched_primax", 159, 1, "i:i "), + new Ia32Syscall ("sched_primin", 160, 1, "i:i "), + new Ia32Syscall ("sched_rr_gi", 161, 2, "i:ip "), + new Ia32Syscall ("nanosleep", 162, 2, "i:pp "), + new Ia32Syscall ("mremap", 163, 4, "b:aini "), + new Ia32Syscall ("setresuid", 164, 3, "i:iii "), + new Ia32Syscall ("getresuid", 165, 3, "i:ppp "), + new Ia32Syscall ("vm86", 166, 1, "i:p "), + new Ia32Syscall ("query_module", 167, 5, "i:sipip "), + new Ia32Syscall ("poll", 168, 3, "i:pii "), + new Ia32Syscall ("nfsservctl", 169, 3, "i:ipp "), + new Ia32Syscall ("setresgid", 170, 3, "i:iii "), + new Ia32Syscall ("getresgid", 171, 3, "i:ppp "), + new Ia32Syscall ("prctl", 172, 5, "i:iiiii "), + new Ia32Syscall ("rt_sigreturn", 173), + new Ia32Syscall ("rt_sigaction", 174), + new Ia32Syscall ("rt_sigprocmask", 175), + new Ia32Syscall ("rt_sigpending", 176), + new Ia32Syscall ("rt_sigtimedwait", 177), + new Ia32Syscall ("rt_sigqueueinfo", 178), + new Ia32Syscall ("rt_sigsuspend", 179), + new Ia32Syscall ("pread64", 180), + new Ia32Syscall ("pwrite64", 181), + new Ia32Syscall ("chown", 182, 3, "i:sii "), + new Ia32Syscall ("getcwd", 183, 2, "i:bi "), + new Ia32Syscall ("capget", 184, 2, "i:pp "), + new Ia32Syscall ("capset", 185, 2, "i:pp "), + new Ia32Syscall ("sigaltstack", 186, 2, "i:PP "), + new Ia32Syscall ("sendfile", 187, 4, "i:iipi "), + new Ia32Syscall ("getpmsg", 188), + new Ia32Syscall ("putpmsg", 189), + new Ia32Syscall ("vfork", 190, 0, "i: "), + new Ia32Syscall ("ugetrlimit", 191), + new Ia32Syscall ("mmap", 192, 6, "b:aniiii "), + new Ia32Syscall ("truncate64", 193, 3, "i:shl "), + new Ia32Syscall ("ftruncate64", 194, 3, "i:ihl "), + new Ia32Syscall ("stat64", 195, 2, "i:sp "), + new Ia32Syscall ("lstat64", 196, 2, "i:sp "), + new Ia32Syscall ("fstat64", 197, 2, "i:ip "), + new Ia32Syscall ("lchown32", 198, 3, "i:sii "), + new Ia32Syscall ("getuid32", 199), + new Ia32Syscall ("getgid32", 200), + new Ia32Syscall ("geteuid32", 201), + new Ia32Syscall ("getegid32", 202), + new Ia32Syscall ("setreuid32", 203, 2, "i:ii "), + new Ia32Syscall ("setregid32", 204, 2, "i:ii "), + new Ia32Syscall ("getgroups32", 205, 2, "i:ip "), + new Ia32Syscall ("setgroups32", 206, 2, "i:ip "), + new Ia32Syscall ("fchown32", 207, 3, "i:iii "), + new Ia32Syscall ("setresuid32", 208, 3, "i:iii "), + new Ia32Syscall ("getresuid32", 209, 3, "i:ppp "), + new Ia32Syscall ("setresgid32", 210, 3, "i:iii "), + new Ia32Syscall ("getresgid32", 211, 3, "i:ppp "), + new Ia32Syscall ("chown32", 212, 3, "i:sii "), + new Ia32Syscall ("setuid32", 213, 1, "i:i "), + new Ia32Syscall ("setgid32", 214, 1, "i:i "), + new Ia32Syscall ("setfsuid32", 215, 1, "i:i "), + new Ia32Syscall ("setfsgid32", 216, 1, "i:i "), + new Ia32Syscall ("pivot_root", 217, 2, "i:ss "), + new Ia32Syscall ("mincore", 218, 3, "i:anV "), + new Ia32Syscall ("madvise", 219, 3, "i:pii "), + new Ia32Syscall ("getdents64", 220, 3, "i:ipi "), + new Ia32Syscall ("fcntl64", 221, 3, "i:iip "), + new Ia32Syscall (222), + new Ia32Syscall (223), + new Ia32Syscall ("gettid", 224, 0), + new Ia32Syscall ("readahead", 225, 4, "i:ihli "), + new Ia32Syscall ("setxattr", 226), + new Ia32Syscall ("lsetxattr", 227), + new Ia32Syscall ("fsetxattr", 228), + new Ia32Syscall ("getxattr", 229), + new Ia32Syscall ("lgetxattr", 230), + new Ia32Syscall ("fgetxattr", 231), + new Ia32Syscall ("listxattr", 232), + new Ia32Syscall ("llistxattr", 233), + new Ia32Syscall ("flistxattr", 234), + new Ia32Syscall ("removexattr", 235), + new Ia32Syscall ("lremovexattr", 236), + new Ia32Syscall ("fremovexattr", 237), + new Ia32Syscall ("tkill", 238, 2, "i:ii "), + new Ia32Syscall ("sendfile64", 239, 4, "i:iipi "), + new Ia32Syscall ("futex", 240, 4, "i:piip "), + new Ia32Syscall ("sched_setaffinity", 241), + new Ia32Syscall ("sched_getaffinity", 242), + new Ia32Syscall ("set_thread_area", 243, 1, "i:p "), + new Ia32Syscall ("get_thread_area", 244, 1, "i:p "), + new Ia32Syscall ("io_setup", 245, 2, "i:ip "), + new Ia32Syscall ("io_destroy", 246, 1, "i:i "), + new Ia32Syscall ("io_getevents", 247, 5, "i:iiipp "), + new Ia32Syscall ("io_submit", 248, 3, "i:iip "), + new Ia32Syscall ("io_cancel", 249, 3, "i:ipp "), + new Ia32Syscall ("fadvise64", 250), + new Ia32Syscall (251), + new Ia32Syscall ("exit_group", 252, 1, " :i ", true), + new Ia32Syscall ("lookup_dcookie", 253), + new Ia32Syscall ("epoll_create", 254), + new Ia32Syscall ("epoll_ctl", 255), + new Ia32Syscall ("epoll_wait", 256), + new Ia32Syscall ("remap_file_pages", 257), + new Ia32Syscall ("set_tid_address", 258), + new Ia32Syscall ("timer_create", 259), + new Ia32Syscall ("timer_settime", 260), + new Ia32Syscall ("timer_gettime", 261), + new Ia32Syscall ("timer_getoverrun", 262), + new Ia32Syscall ("timer_delete", 263), + new Ia32Syscall ("clock_settime", 264), + new Ia32Syscall ("clock_gettime", 265), + new Ia32Syscall ("clock_getres", 266), + new Ia32Syscall ("clock_nanosleep", 267), + new Ia32Syscall ("statfs64", 268), + new Ia32Syscall ("fstatfs64", 269), + new Ia32Syscall ("tgkill", 270), + new Ia32Syscall ("utimes", 271), + new Ia32Syscall ("fadvise64_64", 272) + }; + + + static class SocketSubSyscall + extends Ia32Syscall + { + SocketSubSyscall (String name, int number) + { + super (name, number); + } + SocketSubSyscall (String name, int number, int numArgs, String argList) + { + super (name, number, numArgs, argList); + } + + public long getArguments (Task task, int n) + { + /** Arguments in socket subcalls are dereferenced. */ + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + long base = isa.getRegisterByName("ecx").get (task); + + //System.out.println(Long.toHexString(base) + " " + n); + return task.memory.getInt(base + (n-1) * isa.getWordSize()); + } + } + + static Syscall[] socketSubcallList = { + new SocketSubSyscall ("", SOCKET_NUM), + new SocketSubSyscall ("socket", SOCKET_NUM, 3, "i:iii"), + new SocketSubSyscall ("bind", SOCKET_NUM, 3, "i:ipi "), + new SocketSubSyscall ("connect", SOCKET_NUM, 3, "i:ipi "), + new SocketSubSyscall ("listen", SOCKET_NUM, 2, "i:ii "), + new SocketSubSyscall ("accept", SOCKET_NUM, 3, "i:ipp "), + new SocketSubSyscall ("getsockname",SOCKET_NUM, 3, "i:ipp "), + new SocketSubSyscall ("getpeername",SOCKET_NUM, 4, "i:iiip "), + new SocketSubSyscall ("socketpair", SOCKET_NUM, 4, "i:iiip "), + new SocketSubSyscall ("send", SOCKET_NUM, 4, "i:ipii "), + new SocketSubSyscall ("recv", SOCKET_NUM, 4, "i:ipii "), + new SocketSubSyscall ("sendto", SOCKET_NUM, 6, "i:ipiipi"), + new SocketSubSyscall ("recvfrom", SOCKET_NUM, 6, "i:ipiipp "), + new SocketSubSyscall ("shutdown", SOCKET_NUM, 2, "i:ii "), + new SocketSubSyscall ("setsockopt", SOCKET_NUM, 5, "i:iiipp "), + new SocketSubSyscall ("getsockopt", SOCKET_NUM, 5, "i:iiipp "), + new SocketSubSyscall ("sendmsg", SOCKET_NUM, 5, "i:iiipp "), + new SocketSubSyscall ("recvmsg", SOCKET_NUM, 5, "i:iiipp ") + }; + + + static class IpcSubSyscall + extends Ia32Syscall + { + IpcSubSyscall (String name, int number) + { + super (name, number); + } + IpcSubSyscall (String name, int number, int numArgs, String argList) + { + super (name, number, numArgs, argList); + } + public long getArguments (Task task, int n) + { + if (n == 0) + return super.getArguments (task, 0); + else + // these arguements are shifted by one. + return super.getArguments (task, n+1); + } + + } + /**FIXME: No argument list here.*/ + static Syscall[] ipcSubcallList = { + new IpcSubSyscall ("semop", IPC_NUM), + new IpcSubSyscall ("semget", IPC_NUM), + new IpcSubSyscall ("semctl", IPC_NUM), + new IpcSubSyscall ("semtimedop", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("msgsnd", IPC_NUM), + new IpcSubSyscall ("msgrcv", IPC_NUM), + new IpcSubSyscall ("msgget", IPC_NUM), + new IpcSubSyscall ("msgctl", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("", IPC_NUM), + new IpcSubSyscall ("shmat", IPC_NUM), + new IpcSubSyscall ("shmdt", IPC_NUM), + new IpcSubSyscall ("shmget", IPC_NUM), + new IpcSubSyscall ("shmctl", IPC_NUM) + }; + + public static Syscall syscallByNum (Task task, int number) + { + if (number != SOCKET_NUM && number != IPC_NUM) + return Syscall.syscallByNum (number, task); + else + { + /** sub syscall number is in %ebx. */ + int subSyscallNumber = 0; + try + { + subSyscallNumber = (int) task.getIsa().getRegisterByName("ebx").get (task); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + + if (number == SOCKET_NUM) + { + return socketSubcallList[subSyscallNumber]; + } + else + { + return ipcSubcallList[subSyscallNumber]; + } + } + } +} --- /dev/null 2006-09-01 16:42:34.468363500 +0800 +++ frysk-core/frysk/proc/LinuxEMT64Syscall.java 2006-09-13 17:29:38.000000000 +0800 @@ -0,0 +1,383 @@ +// This file is part of the program FRYSK. +// +// Copyright 2005, 2006 Red Hat Inc. +// +// FRYSK is free software; you can redistribute it and/or modify it +// under the terms of the GNU General Public License as published by +// the Free Software Foundation; version 2 of the License. +// +// FRYSK is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +// General Public License for more details. +// +// You should have received a copy of the GNU General Public License +// along with FRYSK; if not, write to the Free Software Foundation, +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// In addition, as a special exception, Red Hat, Inc. gives You the +// additional right to link the code of FRYSK with code not covered +// under the GNU General Public License ("Non-GPL Code") and to +// distribute linked combinations including the two, subject to the +// limitations in this paragraph. Non-GPL Code permitted under this +// exception must only link to the code of FRYSK through those well +// defined interfaces identified in the file named EXCEPTION found in +// the source code files (the "Approved Interfaces"). The files of +// Non-GPL Code may instantiate templates or use macros or inline +// functions from the Approved Interfaces without causing the +// resulting work to be covered by the GNU General Public +// License. Only Red Hat, Inc. may make changes or additions to the +// list of Approved Interfaces. You must obey the GNU General Public +// License in all respects for all of the FRYSK code and other code +// used in conjunction with FRYSK except the Non-GPL Code covered by +// this exception. If you modify this file, you may extend this +// exception to your version of the file, but you are not obligated to +// do so. If you do not wish to provide this exception without +// modification, you must delete this exception statement from your +// version and license this file solely under the GPL without +// exception. + +package frysk.proc; + +import java.util.HashMap; + +public class LinuxEMT64Syscall +{ + + // This is used to keep track of syscalls whose number we do not + // know. + static HashMap unknownSyscalls; + + static class EMT64Syscall + extends Syscall + { + EMT64Syscall (String name, int number, int numArgs, + String argList, boolean noreturn) + { + super (name, number, numArgs, argList, noreturn); + } + EMT64Syscall (String name, int number, int numArgs, String argList) + { + super (name, number, numArgs, argList); + } + EMT64Syscall (String name, int number, int numArgs) + { + super (name, number, numArgs); + } + EMT64Syscall (String name, int number) + { + super (name, number); + } + EMT64Syscall (int number) + { + super (number); + } + public long getArguments (Task task, int n) + { + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + + switch (n) { + case 0: + return isa.getRegisterByName ("orig_rax").get(task); + case 1: + return isa.getRegisterByName("rdi").get(task); + case 2: + return isa.getRegisterByName("rsi").get (task); + case 3: + return isa.getRegisterByName("rdx").get (task); + case 4: + return isa.getRegisterByName("r10").get (task); + case 5: + return isa.getRegisterByName("r8").get (task); + case 6: + return isa.getRegisterByName("r9").get (task); + default: + throw new RuntimeException ("unknown syscall arg"); + } + } + public long getReturnCode (Task task) + { + Isa isa; + try + { + isa = task.getIsa(); + } + catch (Exception e) + { + throw new RuntimeException ("Could not get isa"); + } + return isa.getRegisterByName ("rax").get (task); + } + } + static Syscall[] syscallList = { + new EMT64Syscall ("read", 0, 3, "i:ibn "), + new EMT64Syscall ("write", 1, 3, "i:ibn "), + new EMT64Syscall ("open", 2, 3, "i:siv "), + new EMT64Syscall ("close", 3, 1, "i:i "), + new EMT64Syscall ("stat", 4, 2, "i:sp "), + new EMT64Syscall ("fstat", 5, 2, "i:ip "), + new EMT64Syscall ("lstat", 6, 2, "i:sp "), + new EMT64Syscall ("poll", 7, 3, "i:pii "), + new EMT64Syscall ("lseek", 8, 3, "i:iii "), + new EMT64Syscall ("mmap", 9, 6, "b:aniiii "), + new EMT64Syscall ("mprotect", 10, 3, "i:aii "), + new EMT64Syscall ("munmap", 11, 2, "i:ai "), + new EMT64Syscall ("brk", 12, 1, "i:p "), + new EMT64Syscall ("rt_sigaction", 13), + new EMT64Syscall ("rt_sigprocmask", 14), + new EMT64Syscall ("rt_sigreturn", 15), + new EMT64Syscall ("ioctl", 16, 3, "i:iiI "), + new EMT64Syscall ("pread64", 17), + new EMT64Syscall ("pwrite64", 18), + new EMT64Syscall ("readv", 19, 3, "i:ipi "), + new EMT64Syscall ("writev", 20, 3, "i:ipi "), + new EMT64Syscall ("access", 21, 2, "i:si "), + new EMT64Syscall ("pipe", 22, 1, "i:f "), + new EMT64Syscall ("select", 23, 5, "i:iPPPP "), + new EMT64Syscall ("sched_yield", 24, 0, "i: "), + new EMT64Syscall ("mremap", 25, 4, "b:aini "), + new EMT64Syscall ("msync", 26, 3, "i:aii "), + new EMT64Syscall ("mincore", 27, 3, "i:anV "), + new EMT64Syscall ("madvise", 28, 3, "i:pii "), + new EMT64Syscall ("shmget", 29, 3, "i:iii "), + new EMT64Syscall ("shmat", 30, 3, "p:ipi "), + new EMT64Syscall ("shmctl", 31, 3, "i:iip "), + new EMT64Syscall ("dup", 32, 1, "i:i "), + new EMT64Syscall ("dup2", 33, 2, "i:ii "), + new EMT64Syscall ("pause", 34, 0, "i: "), + new EMT64Syscall ("nanosleep", 35, 2, "i:pp "), + new EMT64Syscall ("getitimer", 36, 2, "i:ip "), + new EMT64Syscall ("alarm", 37, 1, "i:i "), + new EMT64Syscall ("setitimer", 38, 3, "i:ipp "), + new EMT64Syscall ("getpid", 39, 0, "i: "), + new EMT64Syscall ("sendfile", 40, 4, "i:iipi "), + new EMT64Syscall ("socket", 41, 3, "i:iii "), + new EMT64Syscall ("connect", 42), + new EMT64Syscall ("accept", 43), + new EMT64Syscall ("sendto", 44), + new EMT64Syscall ("recvfrom", 45), + new EMT64Syscall ("sendmsg", 46), + new EMT64Syscall ("recvmsg", 47), + new EMT64Syscall ("shutdown", 48), + new EMT64Syscall ("bind", 49, 3, "i:ipi "), + new EMT64Syscall ("listen", 50, 2, "i:ii "), + new EMT64Syscall ("getsockname", 51, 3, "i:ipp "), + new EMT64Syscall ("getpeername", 52, 4, "i:iiip "), + new EMT64Syscall ("socketpair", 53, 4, "i:iiip "), + new EMT64Syscall ("setsockopt", 54, 5, "i:iiipp "), + new EMT64Syscall ("getsockopt", 55, 5, "i:iiipp "), + new EMT64Syscall ("clone", 56, 2, "i:ip "), + new EMT64Syscall (58), + new EMT64Syscall ("fork", 57, 0, "i: "), + new EMT64Syscall ("execve", 59, 3, "i:ppp "), + new EMT64Syscall ("exit", 60, 1), + new EMT64Syscall ("wait4", 61, 4, "i:iWiP "), + new EMT64Syscall ("kill", 62, 2, "i:ii "), + new EMT64Syscall ("uname", 63, 1, "i:p "), + new EMT64Syscall ("semget", 64), + new EMT64Syscall ("semop", 65), + new EMT64Syscall ("semctl", 66), + new EMT64Syscall ("shmdt", 67), + new EMT64Syscall ("msgget", 68), + new EMT64Syscall ("msgsnd", 69), + new EMT64Syscall ("msgrcv", 70), + new EMT64Syscall ("msgctl", 71), + new EMT64Syscall ("fcntl", 72, 3, "i:iiF "), + new EMT64Syscall ("flock", 73, 2, "i:ii "), + new EMT64Syscall ("fsync", 74, 1, "i:i "), + new EMT64Syscall ("fdatasync", 75, 1, "i:i "), + new EMT64Syscall ("truncate", 76, 2, "i:si "), + new EMT64Syscall ("ftruncate", 77, 2, "i:ii "), + new EMT64Syscall ("getdents", 78), + new EMT64Syscall ("getcwd", 79, 2, "i:bi "), + new EMT64Syscall ("chdir", 80, 1, "i:s "), + new EMT64Syscall ("fchdir", 81, 1, "i:i "), + new EMT64Syscall ("rename", 82, 2, "i:ss "), + new EMT64Syscall ("mkdir", 83, 2, "i:si "), + new EMT64Syscall ("rmdir", 84, 1, "i:s "), + new EMT64Syscall ("creat", 85, 2, "i:sv"), + new EMT64Syscall ("link", 86, 2, "i:ss "), + new EMT64Syscall ("unlink", 87, 1, "i:s "), + new EMT64Syscall ("symlink", 88, 2, "i:ss "), + new EMT64Syscall ("readlink", 89, 3, "i:spi "), + new EMT64Syscall ("chmod", 90, 2, "i:si "), + new EMT64Syscall ("fchmod", 91, 2, "i:ii "), + new EMT64Syscall ("chown", 92, 3, "i:sii "), + new EMT64Syscall ("fchown", 93, 3, "i:iii "), + new EMT64Syscall ("lchown", 94, 3, "i:sii "), + new EMT64Syscall ("umask", 95, 1, "i:i "), + new EMT64Syscall ("gettimeofday", 96, 2, "i:PP "), + new EMT64Syscall ("getrlimit", 97, 2, "i:ip "), + new EMT64Syscall ("getrusage", 98, 2, "i:ip "), + new EMT64Syscall ("sysinfo", 99, 1, "i:p "), + new EMT64Syscall ("times", 100, 1, "i:p "), + new EMT64Syscall ("ptrace", 101, 4, "i:iiii "), + new EMT64Syscall ("getuid", 102, 0, "i: "), + new EMT64Syscall ("syslog", 103), + new EMT64Syscall ("getgid", 104, 0, "i: "), + new EMT64Syscall ("setuid", 105, 1, "i:i "), + new EMT64Syscall ("setgid", 106, 1, "i:i "), + new EMT64Syscall ("geteuid", 107, 0, "i: "), + new EMT64Syscall ("getegid", 108, 0, "i: "), + new EMT64Syscall ("setpgid", 109, 2, "i:ii "), + new EMT64Syscall ("getppid", 110, 0, "i: "), + new EMT64Syscall ("getpgrp", 111, 0, "i: "), + new EMT64Syscall ("setsid", 112, 0, "i: "), + new EMT64Syscall ("setreuid", 113, 2, "i:ii "), + new EMT64Syscall ("setregid", 114, 2, "i:ii "), + new EMT64Syscall ("getgroups", 115, 2, "i:ip "), + new EMT64Syscall ("setgroups", 116, 2, "i:ip "), + new EMT64Syscall ("setresuid", 117, 3, "i:iii "), + new EMT64Syscall ("getresuid", 118, 3, "i:ppp "), + new EMT64Syscall ("setresgid", 119, 3, "i:iii "), + new EMT64Syscall ("getresgid", 120, 3, "i:ppp "), + new EMT64Syscall ("getpgid", 121, 1, "i:i "), + new EMT64Syscall ("setfsuid", 122, 1, "i:i "), + new EMT64Syscall ("setfsgid", 123, 1, "i:i "), + new EMT64Syscall ("getsid", 124, 1, "i:i "), + new EMT64Syscall ("capget", 125, 2, "i:pp "), + new EMT64Syscall ("capset", 126, 2, "i:pp "), + new EMT64Syscall ("rt_sigpending", 127, 2, "i:pi "), + new EMT64Syscall ("rt_sigtimedwait", 128, 4, "i:pppi " ), + new EMT64Syscall ("rt_sigqueueinfo", 129 ), + new EMT64Syscall ("rt_sigsuspend", 130 ), + new EMT64Syscall ("sigaltstack", 131, 2, "i:PP "), + new EMT64Syscall ("utime", 132, 2, "i:sP "), + new EMT64Syscall ("mknod", 133, 3, "i:sii "), + new EMT64Syscall ("uselib", 134, 1, "i:s "), + new EMT64Syscall ("personality", 135, 1, "i:i "), + new EMT64Syscall ("ustat", 136, 2, "i:ip "), + new EMT64Syscall ("statfs", 137, 2, "i:sp "), + new EMT64Syscall ("fstatfs", 138, 2, "i:ip "), + new EMT64Syscall ("sysfs", 139, 1, "i:i "), + new EMT64Syscall ("getpriority", 140, 2, "i:ii "), + new EMT64Syscall ("setpriority", 141, 3, "i:iii "), + new EMT64Syscall ("sched_setparam", 142), + new EMT64Syscall ("sched_getparam", 143), + new EMT64Syscall ("sched_setscheduler", 144), + new EMT64Syscall ("sched_getscheduler", 145), + new EMT64Syscall ("sched_get_priority_max", 146), + new EMT64Syscall ("sched_get_priority_min", 147), + new EMT64Syscall ("sched_rr_get_interval", 148), + new EMT64Syscall ("mlock", 149, 2, "i:bn "), + new EMT64Syscall ("munlock", 150, 2, "i:ai "), + new EMT64Syscall ("mlockall", 151, 1, "i:i "), + new EMT64Syscall ("munlockall", 152, 0, "i: "), + new EMT64Syscall ("vhangup", 153, 1, "i:i "), + new EMT64Syscall ("modify_ldt", 154, 3, "i:ipi "), + new EMT64Syscall ("pivot_root", 155, 2, "i:ss "), + new EMT64Syscall ("_sysctl", 156), + new EMT64Syscall ("prctl", 157, 5, "i:iiiii "), + new EMT64Syscall ("arch_prctl", 158), + new EMT64Syscall ("adjtimex", 159, 1, "i:p "), + new EMT64Syscall ("setrlimit", 160, 2, "i:ip "), + new EMT64Syscall ("chroot", 161, 1, "i:s "), + new EMT64Syscall ("sync", 162, 0, "i: "), + new EMT64Syscall ("acct", 163, 1, "i:S "), + new EMT64Syscall ("settimeofday", 164, 2, "i:PP "), + new EMT64Syscall ("mount", 165, 5, "i:sssip "), + new EMT64Syscall ("umount2", 166, 2, "i:si "), + new EMT64Syscall ("swapon", 167, 2, "i:si "), + new EMT64Syscall ("swapoff", 168, 1, "i:s "), + new EMT64Syscall ("reboot", 169, 1, "i:i "), + new EMT64Syscall ("sethostname", 170, 2, "i:pi "), + new EMT64Syscall ("setdomainname", 171), + new EMT64Syscall ("iopl", 172, 1, "i:i "), + new EMT64Syscall ("ioperm", 173, 3, "i:iii "), + new EMT64Syscall ("create_module", 174, 3), + new EMT64Syscall ("init_module", 175, 5), + new EMT64Syscall ("delete_module", 176, 3), + new EMT64Syscall ("get_kernel_syms", 177, 1, "i:p "), + new EMT64Syscall ("query_module", 178, 5, "i:sipip "), + new EMT64Syscall ("quotactl", 179, 4, "i:isip "), + new EMT64Syscall ("nfsservctl", 180, 3, "i:ipp "), + new EMT64Syscall ("getpmsg", 181), + new EMT64Syscall ("putpmsg", 182), + new EMT64Syscall ("afs_syscall", 183), + new EMT64Syscall ("tuxcall", 184), + new EMT64Syscall ("security", 185), + new EMT64Syscall ("gettid", 186, 0), + new EMT64Syscall ("readahead", 187, 4, "i:ihli "), + new EMT64Syscall ("setxattr", 188), + new EMT64Syscall ("lsetxattr", 189 ), + new EMT64Syscall ("fsetxattr", 190 ), + new EMT64Syscall ("getxattr", 191 ), + new EMT64Syscall ("lgetxattr", 192 ), + new EMT64Syscall ("fgetxattr", 193 ), + new EMT64Syscall ("listxattr", 194 ), + new EMT64Syscall ("llistxattr", 195 ), + new EMT64Syscall ("flistxattr", 196 ), + new EMT64Syscall ("removexattr", 197 ), + new EMT64Syscall ("lremovexattr", 198 ), + new EMT64Syscall ("fremovexattr", 199 ), + new EMT64Syscall ("tkill", 200, 2, "i:ii "), + new EMT64Syscall ("time", 201, 1, "i:P "), + new EMT64Syscall ("futex", 202, 4, "i:piip "), + new EMT64Syscall ("sched_setaffinity", 203 ), + new EMT64Syscall ("sched_getaffinity", 204 ), + new EMT64Syscall ("set_thread_area", 205, 1, "i:p "), + new EMT64Syscall ("io_setup", 206, 2, "i:ip "), + new EMT64Syscall ("io_destroy", 207, 1, "i:i "), + new EMT64Syscall ("io_getevents", 208, 5, "i:iiipp "), + new EMT64Syscall ("io_submit", 209, 3, "i:iip "), + new EMT64Syscall ("io_cancel", 210, 3, "i:ipp "), + new EMT64Syscall ("get_thread_area", 211, 1, "i:p "), + new EMT64Syscall ("lookup_dcookie", 212), + new EMT64Syscall ("epoll_create", 213), + new EMT64Syscall ("epoll_ctl_old", 214), + new EMT64Syscall ("epoll_wait_old", 215), + new EMT64Syscall ("remap_file_pages", 216), + new EMT64Syscall ("getdents64", 217, 3, "i:ipi "), + new EMT64Syscall ("set_tid_address", 218), + new EMT64Syscall ("restart_syscall", 219), + new EMT64Syscall ("semtimedop", 220), + new EMT64Syscall ("fadvise64", 221), + new EMT64Syscall ("timer_create", 222), + new EMT64Syscall ("timer_settime", 223), + new EMT64Syscall (224), + new EMT64Syscall (225), + new EMT64Syscall ("timer_delete", 226), + new EMT64Syscall ("clock_settime", 227), + new EMT64Syscall ("clock_gettime", 228), + new EMT64Syscall ("clock_getres", 229), + new EMT64Syscall ("clock_nanosleep", 230), + new EMT64Syscall ("exit_group", 231, 1, " :i "), + new EMT64Syscall ("epoll_wait", 232), + new EMT64Syscall ("epoll_ctl", 233), + new EMT64Syscall ("tgkill", 234), + new EMT64Syscall ("utimes", 235), + new EMT64Syscall ("vserver", 236), + new EMT64Syscall ("mbind", 237), + new EMT64Syscall ("set_mempolicy", 238), + new EMT64Syscall ("get_mempolicy", 239), + new EMT64Syscall ("mq_open", 240), + new EMT64Syscall ("mq_unlink", 241), + new EMT64Syscall ("mq_timedsend", 242), + new EMT64Syscall ("mq_timedreceive", 243), + new EMT64Syscall ("mq_notify", 244), + new EMT64Syscall ("mq_getsetattr", 245), + new EMT64Syscall ("kexec_load", 246), + new EMT64Syscall ("waitid", 247), + new EMT64Syscall ("add_key", 248), + new EMT64Syscall ("request_key", 249), + new EMT64Syscall ("keyctl", 250), + new EMT64Syscall ("ioprio_set", 251), + new EMT64Syscall ("ioprio_get", 252), + new EMT64Syscall ("inotify_init", 253), + new EMT64Syscall ("inotify_add_watch", 254), + new EMT64Syscall ("inotify_rm_watch", 255) + }; + + public static Syscall syscallByNum (Task task, int number) + { + return Syscall.syscallByNum (number, task); + } +} From qiyaoltc@cn.ibm.com Wed Sep 13 13:21:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 13 Sep 2006 13:21:00 -0000 Subject: [patch] System call for multi-architecture In-Reply-To: <20060913131050.GC17676@GreenHouse.cn.ibm.com> References: <20060913131050.GC17676@GreenHouse.cn.ibm.com> Message-ID: <20060913132126.GD17676@GreenHouse.cn.ibm.com> On Wed, Sep 13, 2006 at 09:10:57PM +0800, Yao Qi wrote: > There were two threads in this maillist about this issue, and I > modified this patch for several time per Mark and Tom's comments, and > feedback from these two threads. > > This patch could provide, > 1) draft system call list(for x86, x86_64, and powerpc). > 2) ftrace could work on these three platforms. A sample output of ftrace on x86_64, [qiyao@YZ_X86_64 ~/build-frysk/frysk-core]$ ./frysk/bindir/ftrace frysk/pkglibexecdir/funit-syscall-running ftrace.main() Proc.getPid() 2494 ftrace.main() Proc.getPid() /home/qiyao/build-frysk/frysk-core/frysk/pkglibexecdir/funit-syscall-running 2494.2494 brk (NULL) = 5246976 2494.2494 mmap (NULL,4096,3,34,-1,0) = 0x2aaaaaaab000 2494.2494 uname (0x7fff4cc32200) = 0 2494.2494 access ("",4) = -1 ERRNO=2 2494.2494 open ("",0,1) = 3 2494.2494 fstat (3,0x7fff4cc318e0) = 0 2494.2494 mmap (NULL,150516,1,2,3,0) = 0x2aaaaaaac000 2494.2494 close (3) = 0 2494.2494 open ("",0,-1431654400) = 3 2494.2494 read (3,0x7fff4cc31a68,832) = 832 2494.2494 fstat (3,0x7fff4cc31940) = 0 2494.2494 mmap (NULL,4096,3,34,-1,0) = 0x2aaaaaad1000 2494.2494 mmap (0x35a0200000,2392200,5,2050,3,0) = 0x35a0200000 2494.2494 mprotect (0x35a033f000,1048576,0) = 0 2494.2494 mmap (0x35a043f000,20480,3,2066,3,1306624) = 0x35a043f000 2494.2494 mmap (0x35a0444000,16520,3,50,-1,0) = 0x35a0444000 2494.2494 close (3) = 0 2494.2494 mmap (NULL,4096,3,34,-1,0) = 0x2aaaaaad2000 2494.2494 arch_prctl () = 0 2494.2494 mprotect (0x35a043f000,16384,1) = 0 2494.2494 mprotect (0x35a0119000,4096,1) = 0 2494.2494 munmap (0x2aaaaaaac000,150516) = 0 2494.2494 socket (2,1,0) = 3 2494.2494 bind (3,0x7fff4cc32430,16) = 0 2494.2494 getsockname (3,0x7fff4cc32430,0x7fff4cc3242c) = 0 2494.2494 listen (3,0) = 0 2494.2494 fstat (1,0x7fff4cc31b40) = 0 2494.2494 mmap (NULL,4096,3,34,-1,0) = 0x2aaaaaaac000 2494.2494 write (1,0x2aaaaaaac000,6)43924 = 6 2494.2494 accept () And a sample output on x86, [qiyao@GreenHouse frysk-core]$ ./frysk/bindir/ftrace frysk/pkglibexecdir/funit-syscall-running ftrace.main() Proc.getPid() 19858 ftrace.main() Proc.getPid() /home/qiyao/source/cvs/build-frysk/frysk-core/frysk/pkglibexecdir/funit-syscall-running 19858.19858 brk (NULL) = 162381824 19858.19858 mmap (NULL,4096,3,34,-1,-38) = 0xb7f6e000 19858.19858 access ("/etc/ld.so.preload",4) = -1 ERRNO=2 19858.19858 open ("/etc/ld.so.cache",0,0) = 3 19858.19858 fstat64 (3,0xbfa5d8cc) = 0 19858.19858 mmap (NULL,67623,1,2,3,-38) = 0xb7f5d000 19858.19858 close (3) = 0 19858.19858 open ("/lib/libc.so.6",0,699) = 3 19858.19858 read (3,0xbfa5da1c,512) = 512 19858.19858 fstat64 (3,0xbfa5d92c) = 0 19858.19858 mmap (0x743000,1295780,5,2050,3,-38) = 0x743000 19858.19858 mmap (0x87a000,12288,3,2066,3,-38) = 0x87a000 19858.19858 mmap (0x87d000,9636,3,50,-1,-38) = 0x87d000 19858.19858 close (3) = 0 19858.19858 mmap (NULL,4096,3,34,-1,-38) = 0xb7f5c000 19858.19858 set_thread_area (0xbfa5de10) = 0 19858.19858 mprotect (0x87a000,8192,1) = 0 19858.19858 mprotect (0x73f000,4096,1) = 0 19858.19858 munmap (0xb7f5d000,67623) = 0 19858.19858 socket (2,1,0) = 3 19858.19858 bind (3,0xffffffffbfa5e1c8,16) = 0 19858.19858 getsockname (3,0xffffffffbfa5e1c8,0xffffffffbfa5e1c4) = 0 19858.19858 listen (3,0) = 0 19858.19858 fstat64 (1,0xbfa5da84) = 0 19858.19858 mmap (NULL,4096,3,34,-1,-38) = 0xb7f6d000 19858.19858 write (1,0xb7f6d000,6)36086 = 6 19858.19858 accept (3,0xffffffffbfa5e1b4,0xffffffffbfa5e1c4) A sample output on ppc64, [qiyao@power-frysk1 ~/build-frysk/frysk-core]$ ./frysk/bindir/ftrace frysk/pkglibexecdir/funit-syscall-running ftrace.main() Proc.getPid() 7855 ftrace.main() Proc.getPid() /home/qiyao/build-frysk/frysk-core/frysk/pkglibexecdir/funit-syscall-running 7855.7855 brk (NULL) = 268509184 7855.7855 mmap (NULL,4096,3,34,-1,0) = 0x40000000000 7855.7855 access ("",4) = -1 ERRNO=2 7855.7855 open ("",0,1) = 3 7855.7855 fstat () = 0 7855.7855 mmap (NULL,80861,1,2,3,0) = 0x40000001000 7855.7855 close (3) = 0 7855.7855 open ("",0,-55593184) = 3 7855.7855 read (3,0xfffffb6d588,832) = 832 7855.7855 fstat () = 0 7855.7855 mmap (NULL,4096,3,34,-1,0) = 0x40000015000 7855.7855 mmap (0x80fcb00000,1713168,5,2050,3,0) = 0x80fcb00000 7855.7855 mprotect (0x80fcc7c000,61440,0) = 0 7855.7855 mmap (0x80fcc8b000,81920,3,2066,3,1552384) = 0x80fcc8b000 7855.7855 mmap (0x80fcc9f000,13328,3,50,-1,0) = 0x80fcc9f000 7855.7855 close (3) = 0 7855.7855 mmap (NULL,4096,3,34,-1,0) = 0x40000016000 7855.7855 mprotect (0x80fcc8b000,16384,1) = 0 7855.7855 mprotect (0x80fcaf8000,4096,1) = 0 7855.7855 munmap (0x40000001000,80861) = 0 7855.7855 socket (0,0,0) = 3 7855.7855 bind (0,0xfff,0) = 0 7855.7855 getsockname (0,0xfff,0xfff) = 0 7855.7855 listen (0,0) = 0 7855.7855 fstat () = 0 7855.7855 mmap (NULL,4096,3,34,-1,0) = 0x40000001000 7855.7855 write (1,0x40000001000,6)45578 = 6 7855.7855 accept (0,0xfff,0xfff) -- Yao Qi From mcvet@redhat.com Wed Sep 13 13:43:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Wed, 13 Sep 2006 13:43:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: <1158155019.2031.109.camel@towel.toronto.redhat.com> On Wed, 2006-09-13 at 06:43 -0300, Alexandre Oliva wrote: > It still fails to print line numbers for main and for kernel vdso > syscalls and their callers, but other than that, it's much better than > before. > The patch is not quite ready for public consumption (still missing a > ChangeLog, for one), but I thought I'd post it for people who'd like > to use it as is. > > My plan is to use the same code htat unw_get_proc_name() uses to > locate the procedure info and use that in unw_get_proc_info as a > fallback, but that will have to wait until I get some sleep. > > I actually took a stab at dyn_list_addr, but I can't quite figure out > whether this is even to be found somewhere in the memory map of the > target process. At first I thought it was supposed to be the dynamic > loader's linked list of dynamic libs, but that's not it. Does anyone > know? > According to upstream, all the dyn_list_* stuff is to handle dynamically-generated code only. So, probably shouldn't have an effect on what we're doing currently anyway. - Mike From cagney@redhat.com Wed Sep 13 17:17:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 13 Sep 2006 17:17:00 -0000 Subject: fc6 frysk-core failures. In-Reply-To: <45077A9C.1000604@redhat.com> References: <45077A9C.1000604@redhat.com> Message-ID: <45083D27.1020108@redhat.com> Chris, This is good progress and the thing to be looking at. Unfortunatly, it may, or may not be the source of the problems, hard to say right now. Broadly what is happening is that the test as successfully run (true? was there an earlier message reporting fail?) and now the tearDown code is going through and trying to destroy (using very brute force) any processes created during the test's run. The brute force process, put simply, throws everything and anything repeatedly at the processes -- kill -9, kill -cont, detach, ... -- in the hope it can be made to go away. A failure here could be due to kernel differences, but could just as easily be a timing issue. In the log, going backwards from: testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >>>>>>>>>>>>>>>> start tearDown what are the last few interactions involving pid 14860? In particular is there anything indicating the state of that pid/tid's object. Andrew Chris Moller wrote: > Running ./frysk-core/TestRunner -c FINE frysk.proc.TestProcTasksObserver > fails on fc6. The fc6 logs and the fc5 logs are, aside from minor > variations in the order of things, are identical until they get to: > > 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown > FINE: > testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) > >>>>>>>>>>>>>>>> start tearDown > > 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown > FINE: > testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) > kill -KILL 14860 > > 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown > FINE: > testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) > kill -CONT 14860 > > 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown > FINE: > testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) > detach -KILL 14860 (failed) > > > > under fc5, and > > 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown > FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) > >>>>>>>>>>>>>>>> start tearDown > > 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown > FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill > -KILL 29450 > > 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown > FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill > -CONT 29450 > > 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown > FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) detach > -KILL 29450 > > under fc6. I.e., prima facie, the detach -KILL seems shows a failure > under fc6 and a pass under fc5. I'll poke at it some more tomorrow. > > > From cmoller@redhat.com Wed Sep 13 17:37:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Wed, 13 Sep 2006 17:37:00 -0000 Subject: fc6 frysk-core failures. In-Reply-To: <45083D27.1020108@redhat.com> References: <45077A9C.1000604@redhat.com> <45083D27.1020108@redhat.com> Message-ID: <450841B1.1040609@redhat.com> Andrew, I've been cross matching the history of the failing vs. passing pids all morning. so far the most significant difference appears to be in the way signals are handled. E.g., at one point, the failing fc6 log shows: 17742.17742: argv[0]=/home/moller/tinkering/frysk/09-12/build/frysk-core/frysk/pkglibexecdir/funit-child 17742.17742: argv[1]=--wait=suspend 17742.17742: argv[2]=10 17742.17742: argv[3]=17739 17742.17742: starting 17742 17742.17742: new thread 17742.17742 17742.17742: notify 17739 with 10 (User defined signal 1) -- new thread 17742.17742 The passing fc5 code is identical except that it /doesn't/ have that last 'notify...' line. Then, later the passing version shows: 17015.17015: clone 0x40a00940 @ 0 created (added) 17015.17015: notify 17012 with 12 (User defined signal 2) -- clone 0x40a00940 @ 0 created (added) 13-Sep-06 11:07:31 AM frysk.proc.LinuxHost$PollWaitOnSigChld$2 getTask FINE:{TaskId,17017}stopped 13-Sep-06 11:07:31 AM frysk.proc.Host get FINE: {frysk.proc.LinuxHost@2e1bd335,state=running} get TaskId whereas the failing log shows about 90 lines of stuff between the "FINE:{TaskId,17017}stopped" line and the "13-Sep-06 11:07:31 AM frysk.proc.Host get" line. The intervening stuff includes things like: 13-Sep-06 11:07:42 AM frysk.event.EventLoop remove FINEST: ... return {frysk.proc.TestLib$AckHandler$AckSignal@26bdb0,sig=Sig_USR2} 13-Sep-06 11:07:42 AM frysk.proc.TestLib$AckHandler$AckSignal execute FINE: {frysk.proc.TestLib$AckHandler$AckSignal@26bdb0,sig=Sig_USR2} execute (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) and a bunch of other things the passing code doesn't seem to do. I'm trying to narrow that down for significance now. Chris Andrew Cagney mumbled something on 09/13/2006 01:17 PM: > Chris, > > This is good progress and the thing to be looking at. Unfortunatly, > it may, or may not be the source of the problems, hard to say right now. > > Broadly what is happening is that the test as successfully run (true? > was there an earlier message reporting fail?) and now the tearDown > code is going through and trying to destroy (using very brute force) > any processes created during the test's run. The brute force process, > put simply, throws everything and anything repeatedly at the processes > -- kill -9, kill -cont, detach, ... -- in the hope it can be made to > go away. A failure here could be due to kernel differences, but could > just as easily be a timing issue. > > In the log, going backwards from: > > testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) > >>>>>>>>>>>>>>>> start tearDown > > what are the last few interactions involving pid 14860? In particular > is there anything indicating the state of that pid/tid's object. > > Andrew > > > > Chris Moller wrote: >> Running ./frysk-core/TestRunner -c FINE frysk.proc.TestProcTasksObserver >> fails on fc6. The fc6 logs and the fc5 logs are, aside from minor >> variations in the order of things, are identical until they get to: >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> >>>>>>>>>>>>>>>> start tearDown >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> kill -KILL 14860 >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> kill -CONT 14860 >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> detach -KILL 14860 (failed) >> >> >> >> under fc5, and >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) >> >>>>>>>>>>>>>>>> start tearDown >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill >> -KILL 29450 >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill >> -CONT 29450 >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) detach >> -KILL 29450 >> >> under fc6. I.e., prima facie, the detach -KILL seems shows a failure >> under fc6 and a pass under fc5. I'll poke at it some more tomorrow. >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From cagney@redhat.com Wed Sep 13 17:54:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 13 Sep 2006 17:54:00 -0000 Subject: [patch] System call for multi-architecture In-Reply-To: <20060913131050.GC17676@GreenHouse.cn.ibm.com> References: <20060913131050.GC17676@GreenHouse.cn.ibm.com> Message-ID: <450845B2.3010704@redhat.com> Yao, this is good, and a great jump forward. Thanks! One political nit, can you use the name x86_64, instead of em64t or emt64 or amd64 for the 64-bit ISA that is an extension of ia32? Andrew Yao Qi wrote: > There were two threads in this maillist about this issue, and I > modified this patch for several time per Mark and Tom's comments, and > feedback from these two threads. > > This patch could provide, > 1) draft system call list(for x86, x86_64, and powerpc). > 2) ftrace could work on these three platforms. > > This patch could not provide, or could provide in the next step, > 1) 64-bit ftrace trace 32-bit app. > 2) accurate arguments for some system calls. > > Mark, Sami, > the patch could give you syscallLists for different architecture. > > > + new IpcSubSyscall ("semop", IPC_NUM), > + new IpcSubSyscall("semget", IPC_NUM), > + new IpcSubSyscall("semctl", IPC_NUM), > + new IpcSubSyscall("semtimedop", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("msgsnd", IPC_NUM), > + new IpcSubSyscall("msgrcv", IPC_NUM), > + new IpcSubSyscall("msgget", IPC_NUM), > + new IpcSubSyscall("msgctl", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("", IPC_NUM), > + new IpcSubSyscall("shmat", IPC_NUM), > + new IpcSubSyscall("shmdt", IPC_NUM), > + new IpcSubSyscall("shmget", IPC_NUM), > + new IpcSubSyscall("shmctl", IPC_NUM) > + }; > + > + public static Syscall syscallByNum (Task task, int number) > + { > + if (number != SOCKET_NUM && number != IPC_NUM) > + return Syscall.syscallByNum (number, task); > + else > + { > + /** sub syscall number is in . */ > + int subSyscallNumber = 0; > + try > + { > + subSyscallNumber = (int) task.getIsa().getRegisterByName("orig_r3").get(task); > + } > + catch (Exception e) > + { > + throw new RuntimeException ("Could not get isa"); > + } > + > + if (number == SOCKET_NUM) > + { > + return socketSubcallList[subSyscallNumber]; > + } > + else > + { > + return ipcSubcallList[subSyscallNumber]; > + } > + } > + } > +} > --- /dev/null 2006-09-01 16:42:34.468363500 +0800 > +++ frysk-core/frysk/proc/LinuxIa32Syscall.java 2006-09-13 17:12:51.000000000 +0800 > @@ -0,0 +1,531 @@ > +// This file is part of the program FRYSK. > +// > +// Copyright 2006 Red Hat Inc. > +// > +// FRYSK is free software; you can redistribute it and/or modify it > +// under the terms of the GNU General Public License as published by > +// the Free Software Foundation; version 2 of the License. > +// > +// FRYSK is distributed in the hope that it will be useful, but > +// WITHOUT ANY WARRANTY; without even the implied warranty of > +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +// General Public License for more details. > +// > +// You should have received a copy of the GNU General Public License > +// along with FRYSK; if not, write to the Free Software Foundation, > +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. > +// > +// In addition, as a special exception, Red Hat, Inc. gives You the > +// additional right to link the code of FRYSK with code not covered > +// under the GNU General Public License ("Non-GPL Code") and to > +// distribute linked combinations including the two, subject to the > +// limitations in this paragraph. Non-GPL Code permitted under this > +// exception must only link to the code of FRYSK through those well > +// defined interfaces identified in the file named EXCEPTION found in > +// the source code files (the "Approved Interfaces"). The files of > +// Non-GPL Code may instantiate templates or use macros or inline > +// functions from the Approved Interfaces without causing the > +// resulting work to be covered by the GNU General Public > +// License. Only Red Hat, Inc. may make changes or additions to the > +// list of Approved Interfaces. You must obey the GNU General Public > +// License in all respects for all of the FRYSK code and other code > +// used in conjunction with FRYSK except the Non-GPL Code covered by > +// this exception. If you modify this file, you may extend this > +// exception to your version of the file, but you are not obligated to > +// do so. If you do not wish to provide this exception without > +// modification, you must delete this exception statement from your > +// version and license this file solely under the GPL without > +// exception. > + > +package frysk.proc; > + > +import java.util.HashMap; > + > +public class LinuxIa32Syscall > +{ > + static final int SOCKET_NUM = 102; > + static final int IPC_NUM = 117; > + > + // This is used to keep track of syscalls whose number we do not > + // know. > + static HashMap unknownSyscalls; > + > + static class Ia32Syscall > + extends Syscall > + { > + Ia32Syscall (String name, int number, int numArgs, > + String argList, boolean noreturn) > + { > + super (name, number, numArgs, argList, noreturn); > + } > + Ia32Syscall (String name, int number, int numArgs, String argList) > + { > + super (name, number, numArgs, argList); > + } > + Ia32Syscall (String name, int number, int numArgs) > + { > + super (name, number, numArgs); > + } > + Ia32Syscall (String name, int number) > + { > + super (name, number); > + } > + Ia32Syscall (int number) > + { > + super (number); > + } > + > + public long getArguments (Task task, int n) > + { > + Isa isa; > + try > + { > + isa = task.getIsa(); > + } > + catch (Exception e) > + { > + throw new RuntimeException ("Could not get isa"); > + } > + > + switch (n) > + { > + case 0: > + return isa.getRegisterByName ("orig_eax").get (task); > + case 1: > + return isa.getRegisterByName("ebx").get (task); > + case 2: > + return isa.getRegisterByName("ecx").get (task); > + case 3: > + return isa.getRegisterByName("edx").get (task); > + case 4: > + return isa.getRegisterByName("esi").get (task); > + case 5: > + return isa.getRegisterByName("edi").get (task); > + case 6: > + return isa.getRegisterByName("eax").get (task); > + default: > + throw new RuntimeException ("unknown syscall arg"); > + } > + } > + public long getReturnCode (Task task) > + { > + Isa isa; > + try > + { > + isa = task.getIsa(); > + } > + catch (Exception e) > + { > + throw new RuntimeException ("Could not get isa"); > + } > + return isa.getRegisterByName ("eax").get (task); > + } > + } > + > + static Syscall[] syscallList = { > + new Ia32Syscall (0), > + new Ia32Syscall ("exit", 1, 1), > + new Ia32Syscall ("fork", 2, 0, "i: "), > + new Ia32Syscall ("read", 3, 3, "i:ibn "), > + new Ia32Syscall ("write", 4, 3, "i:ibn "), > + new Ia32Syscall ("open", 5, 3, "i:siv "), > + new Ia32Syscall ("close", 6, 1, "i:i "), > + new Ia32Syscall ("waitpid", 7, 3, "i:ipi "), > + new Ia32Syscall ("creat", 8, 2, "i:sv"), > + new Ia32Syscall ("link", 9, 2, "i:ss "), > + new Ia32Syscall ("unlink", 10, 1, "i:s "), > + new Ia32Syscall ("execve", 11, 3, "i:ppp "), > + new Ia32Syscall ("chdir", 12, 1, "i:s "), > + new Ia32Syscall ("time", 13, 1, "i:P "), > + new Ia32Syscall ("sys_mknod", 14, 3, "i:sii "), > + new Ia32Syscall ("chmod", 15, 2, "i:si "), > + new Ia32Syscall ("lchown", 16, 3, "i:sii "), > + new Ia32Syscall ("break", 17), > + new Ia32Syscall ("old_stat", 18, 3, "i:pp "), > + new Ia32Syscall ("lseek", 19, 3, "i:iii "), > + new Ia32Syscall ("getpid", 20, 0, "i: "), > + new Ia32Syscall ("mount", 21, 5, "i:sssip "), > + new Ia32Syscall ("umount", 22, 1, "i:s "), > + new Ia32Syscall ("setuid", 23, 1, "i:i "), > + new Ia32Syscall ("getuid", 24, 0, "i: "), > + new Ia32Syscall ("stime", 25, 1, "i:p "), > + new Ia32Syscall ("ptrace", 26, 4, "i:iiii "), > + new Ia32Syscall ("alarm", 27, 1, "i:i "), > + new Ia32Syscall ("old_fstat", 28, 2, "i:ip "), > + new Ia32Syscall ("pause", 29, 0, "i: "), > + new Ia32Syscall ("utime", 30, 2, "i:sP "), > + new Ia32Syscall ("stty", 31), > + new Ia32Syscall ("gtty", 32), > + new Ia32Syscall ("access", 33, 2, "i:si "), > + new Ia32Syscall ("nice", 34, 1, "i:i "), > + new Ia32Syscall ("ftime", 35, 1, "i:p "), > + new Ia32Syscall ("sync", 36, 0, "i: "), > + new Ia32Syscall ("kill", 37, 2, "i:ii "), > + new Ia32Syscall ("rename", 38, 2, "i:ss "), > + new Ia32Syscall ("mkdir", 39, 2, "i:si "), > + new Ia32Syscall ("rmdir", 40, 1, "i:s "), > + new Ia32Syscall ("dup", 41, 1, "i:i "), > + new Ia32Syscall ("pipe", 42, 1, "i:f "), > + new Ia32Syscall ("times", 43, 1, "i:p "), > + new Ia32Syscall ("prof", 44), > + new Ia32Syscall ("brk", 45, 1, "i:p "), > + new Ia32Syscall ("setgid", 46, 1, "i:i "), > + new Ia32Syscall ("getgid", 47, 0, "i: "), > + new Ia32Syscall ("signal", 48, 2, "i:ii "), > + new Ia32Syscall ("geteuid", 49, 0, "i: "), > + new Ia32Syscall ("getegid", 50, 0, "i: "), > + new Ia32Syscall ("acct", 51, 1, "i:S "), > + new Ia32Syscall ("umount2", 52, 2, "i:si "), > + new Ia32Syscall ("lock", 53), > + new Ia32Syscall ("ioctl", 54, 3, "i:iiI "), > + new Ia32Syscall ("fcntl", 55, 3, "i:iiF "), > + new Ia32Syscall ("mpx", 56), > + new Ia32Syscall ("setpgid", 57, 2, "i:ii "), > + new Ia32Syscall ("ulimit", 58, 2, "i:ii "), > + new Ia32Syscall ("oldolduname", 59), > + new Ia32Syscall ("umask", 60, 1, "i:i "), > + new Ia32Syscall ("chroot", 61, 1, "i:s "), > + new Ia32Syscall ("ustat", 62, 2, "i:ip "), > + new Ia32Syscall ("dup2", 63, 2, "i:ii "), > + new Ia32Syscall ("getppid", 64, 0, "i: "), > + new Ia32Syscall ("getpgrp", 65, 0, "i: "), > + new Ia32Syscall ("setsid", 66, 0, "i: "), > + new Ia32Syscall ("sigaction", 67, 3, "i:ipp "), > + new Ia32Syscall ("sgetmask", 68), > + new Ia32Syscall ("ssetmask", 69), > + new Ia32Syscall ("setreuid", 70, 2, "i:ii "), > + new Ia32Syscall ("setregid", 71, 2, "i:ii "), > + new Ia32Syscall ("sigsuspend", 72, 1, "i:p "), > + new Ia32Syscall ("sigpending", 73, 1, "i:p "), > + new Ia32Syscall ("sethostname", 74, 2, "i:pi "), > + new Ia32Syscall ("setrlimit", 75, 2, "i:ip "), > + new Ia32Syscall ("getrlimit", 76, 2, "i:ip "), > + new Ia32Syscall ("getrusage", 77, 2, "i:ip "), > + new Ia32Syscall ("gettimeofday", 78, 2, "i:PP "), > + new Ia32Syscall ("settimeofday", 79, 2, "i:PP "), > + new Ia32Syscall ("getgroups", 80, 2, "i:ip "), > + new Ia32Syscall ("setgroups", 81, 2, "i:ip "), > + new Ia32Syscall ("select", 82, 5, "i:iPPPP "), > + new Ia32Syscall ("symlink", 83, 2, "i:ss "), > + new Ia32Syscall ("oldlstat", 84, 2, "i:pp "), > + new Ia32Syscall ("readlink", 85, 3, "i:spi "), > + new Ia32Syscall ("uselib", 86, 1, "i:s "), > + new Ia32Syscall ("swapon", 87, 2, "i:si "), > + new Ia32Syscall ("reboot", 88, 1, "i:i "), > + new Ia32Syscall (89), > + new Ia32Syscall ("mmap", 90, 6, "b:aniiii "), > + new Ia32Syscall ("munmap", 91, 2, "i:ai "), > + new Ia32Syscall ("truncate", 92, 2, "i:si "), > + new Ia32Syscall ("ftruncate", 93, 2, "i:ii "), > + new Ia32Syscall ("fchmod", 94, 2, "i:ii "), > + new Ia32Syscall ("fchown", 95, 3, "i:iii "), > + new Ia32Syscall ("getpriority", 96, 2, "i:ii "), > + new Ia32Syscall ("setpriority", 97, 3, "i:iii "), > + new Ia32Syscall ("profil", 98, 4, "i:piii "), > + new Ia32Syscall ("statfs", 99, 2, "i:sp "), > + new Ia32Syscall ("fstatfs", 100, 2, "i:ip "), > + new Ia32Syscall ("ioperm", 101, 3, "i:iii "), > + new Ia32Syscall ("socketcall", 102, 2, "i:ip "), > + new Ia32Syscall ("klogctl", 103, 3, "i:isi "), > + new Ia32Syscall ("setitimer", 104, 3, "i:ipp "), > + new Ia32Syscall ("getitimer", 105, 2, "i:ip "), > + new Ia32Syscall ("sys_stat", 106, 2, "i:sp "), > + new Ia32Syscall ("sys_lstat", 107, 2, "i:sp "), > + new Ia32Syscall ("sys_fstat", 108, 2, "i:ip "), > + new Ia32Syscall ("old_uname", 109, 1, "i:p "), > + new Ia32Syscall ("iopl", 110, 1, "i:i "), > + new Ia32Syscall ("vhangup", 111, 1, "i:i "), > + new Ia32Syscall ("idle", 112, 0, "i: "), > + new Ia32Syscall (113), > + new Ia32Syscall ("wait4", 114, 4, "i:iWiP "), > + new Ia32Syscall ("swapoff", 115, 1, "i:s "), > + new Ia32Syscall ("sysinfo", 116, 1, "i:p "), > + new Ia32Syscall ("ipc", 117, 6, "i:iiiipi "), > + new Ia32Syscall ("fsync", 118, 1, "i:i "), > + new Ia32Syscall ("sigreturn", 119), > + new Ia32Syscall ("clone", 120, 2, "i:ip "), > + new Ia32Syscall ("setdomain", 121, 2, "i:si "), > + new Ia32Syscall ("uname", 122, 1, "i:p "), > + new Ia32Syscall ("modify_ldt", 123, 3, "i:ipi "), > + new Ia32Syscall ("adjtimex", 124, 1, "i:p "), > + new Ia32Syscall ("mprotect", 125, 3, "i:aii "), > + new Ia32Syscall ("sigprocmask", 126, 3, "i:ipp "), > + new Ia32Syscall ("create_module", 127, 3), > + new Ia32Syscall ("init_module", 128, 5), > + new Ia32Syscall ("delete_module", 129, 3), > + new Ia32Syscall ("get_kernel_syms", 130, 1, "i:p "), > + new Ia32Syscall ("quotactl", 131, 4, "i:isip "), > + new Ia32Syscall ("getpgid", 132, 1, "i:i "), > + new Ia32Syscall ("fchdir", 133, 1, "i:i "), > + new Ia32Syscall ("bdflush", 134, 2, "i:ii "), > + new Ia32Syscall ("sysfs", 135, 1, "i:i "), > + new Ia32Syscall ("personality", 136, 1, "i:i "), > + new Ia32Syscall ("afs_syscall", 137), > + new Ia32Syscall ("setfsuid", 138, 1, "i:i "), > + new Ia32Syscall ("setfsgid", 139, 1, "i:i "), > + new Ia32Syscall ("llseek", 140, 5, "i:iuupi "), > + new Ia32Syscall ("s_getdents", 141, 3, "i:ipi "), > + new Ia32Syscall ("select", 142, 5, "i:iPPPP "), > + new Ia32Syscall ("flock", 143, 2, "i:ii "), > + new Ia32Syscall ("msync", 144, 3, "i:aii "), > + new Ia32Syscall ("readv", 145, 3, "i:ipi "), > + new Ia32Syscall ("writev", 146, 3, "i:ipi "), > + new Ia32Syscall ("getsid", 147, 1, "i:i "), > + new Ia32Syscall ("fdatasync", 148, 1, "i:i "), > + new Ia32Syscall ("sysctl", 149, 1, "i:p "), > + new Ia32Syscall ("mlock", 150, 2, "i:bn "), > + new Ia32Syscall ("munlock", 151, 2, "i:ai "), > + new Ia32Syscall ("mlockall", 152, 1, "i:i "), > + new Ia32Syscall ("munlockall", 153, 0, "i: "), > + new Ia32Syscall ("sched_setp", 154, 2, "i:ip "), > + new Ia32Syscall ("sched_getp", 155, 2, "i:ip "), > + new Ia32Syscall ("sched_sets", 156, 3, "i:iip "), > + new Ia32Syscall ("sched_gets", 157, 1, "i:i "), > + new Ia32Syscall ("sched_yield", 158, 0, "i: "), > + new Ia32Syscall ("sched_primax", 159, 1, "i:i "), > + new Ia32Syscall ("sched_primin", 160, 1, "i:i "), > + new Ia32Syscall ("sched_rr_gi", 161, 2, "i:ip "), > + new Ia32Syscall ("nanosleep", 162, 2, "i:pp "), > + new Ia32Syscall ("mremap", 163, 4, "b:aini "), > + new Ia32Syscall ("setresuid", 164, 3, "i:iii "), > + new Ia32Syscall ("getresuid", 165, 3, "i:ppp "), > + new Ia32Syscall ("vm86", 166, 1, "i:p "), > + new Ia32Syscall ("query_module", 167, 5, "i:sipip "), > + new Ia32Syscall ("poll", 168, 3, "i:pii "), > + new Ia32Syscall ("nfsservctl", 169, 3, "i:ipp "), > + new Ia32Syscall ("setresgid", 170, 3, "i:iii "), > + new Ia32Syscall ("getresgid", 171, 3, "i:ppp "), > + new Ia32Syscall ("prctl", 172, 5, "i:iiiii "), > + new Ia32Syscall ("rt_sigreturn", 173), > + new Ia32Syscall ("rt_sigaction", 174), > + new Ia32Syscall ("rt_sigprocmask", 175), > + new Ia32Syscall ("rt_sigpending", 176), > + new Ia32Syscall ("rt_sigtimedwait", 177), > + new Ia32Syscall ("rt_sigqueueinfo", 178), > + new Ia32Syscall ("rt_sigsuspend", 179), > + new Ia32Syscall ("pread64", 180), > + new Ia32Syscall ("pwrite64", 181), > + new Ia32Syscall ("chown", 182, 3, "i:sii "), > + new Ia32Syscall ("getcwd", 183, 2, "i:bi "), > + new Ia32Syscall ("capget", 184, 2, "i:pp "), > + new Ia32Syscall ("capset", 185, 2, "i:pp "), > + new Ia32Syscall ("sigaltstack", 186, 2, "i:PP "), > + new Ia32Syscall ("sendfile", 187, 4, "i:iipi "), > + new Ia32Syscall ("getpmsg", 188), > + new Ia32Syscall ("putpmsg", 189), > + new Ia32Syscall ("vfork", 190, 0, "i: "), > + new Ia32Syscall ("ugetrlimit", 191), > + new Ia32Syscall ("mmap", 192, 6, "b:aniiii "), > + new Ia32Syscall ("truncate64", 193, 3, "i:shl "), > + new Ia32Syscall ("ftruncate64", 194, 3, "i:ihl "), > + new Ia32Syscall ("stat64", 195, 2, "i:sp "), > + new Ia32Syscall ("lstat64", 196, 2, "i:sp "), > + new Ia32Syscall ("fstat64", 197, 2, "i:ip "), > + new Ia32Syscall ("lchown32", 198, 3, "i:sii "), > + new Ia32Syscall ("getuid32", 199), > + new Ia32Syscall ("getgid32", 200), > + new Ia32Syscall ("geteuid32", 201), > + new Ia32Syscall ("getegid32", 202), > + new Ia32Syscall ("setreuid32", 203, 2, "i:ii "), > + new Ia32Syscall ("setregid32", 204, 2, "i:ii "), > + new Ia32Syscall ("getgroups32", 205, 2, "i:ip "), > + new Ia32Syscall ("setgroups32", 206, 2, "i:ip "), > + new Ia32Syscall ("fchown32", 207, 3, "i:iii "), > + new Ia32Syscall ("setresuid32", 208, 3, "i:iii "), > + new Ia32Syscall ("getresuid32", 209, 3, "i:ppp "), > + new Ia32Syscall ("setresgid32", 210, 3, "i:iii "), > + new Ia32Syscall ("getresgid32", 211, 3, "i:ppp "), > + new Ia32Syscall ("chown32", 212, 3, "i:sii "), > + new Ia32Syscall ("setuid32", 213, 1, "i:i "), > + new Ia32Syscall ("setgid32", 214, 1, "i:i "), > + new Ia32Syscall ("setfsuid32", 215, 1, "i:i "), > + new Ia32Syscall ("setfsgid32", 216, 1, "i:i "), > + new Ia32Syscall ("pivot_root", 217, 2, "i:ss "), > + new Ia32Syscall ("mincore", 218, 3, "i:anV "), > + new Ia32Syscall ("madvise", 219, 3, "i:pii "), > + new Ia32Syscall ("getdents64", 220, 3, "i:ipi "), > + new Ia32Syscall ("fcntl64", 221, 3, "i:iip "), > + new Ia32Syscall (222), > + new Ia32Syscall (223), > + new Ia32Syscall ("gettid", 224, 0), > + new Ia32Syscall ("readahead", 225, 4, "i:ihli "), > + new Ia32Syscall ("setxattr", 226), > + new Ia32Syscall ("lsetxattr", 227), > + new Ia32Syscall ("fsetxattr", 228), > + new Ia32Syscall ("getxattr", 229), > + new Ia32Syscall ("lgetxattr", 230), > + new Ia32Syscall ("fgetxattr", 231), > + new Ia32Syscall ("listxattr", 232), > + new Ia32Syscall ("llistxattr", 233), > + new Ia32Syscall ("flistxattr", 234), > + new Ia32Syscall ("removexattr", 235), > + new Ia32Syscall ("lremovexattr", 236), > + new Ia32Syscall ("fremovexattr", 237), > + new Ia32Syscall ("tkill", 238, 2, "i:ii "), > + new Ia32Syscall ("sendfile64", 239, 4, "i:iipi "), > + new Ia32Syscall ("futex", 240, 4, "i:piip "), > + new Ia32Syscall ("sched_setaffinity", 241), > + new Ia32Syscall ("sched_getaffinity", 242), > + new Ia32Syscall ("set_thread_area", 243, 1, "i:p "), > + new Ia32Syscall ("get_thread_area", 244, 1, "i:p "), > + new Ia32Syscall ("io_setup", 245, 2, "i:ip "), > + new Ia32Syscall ("io_destroy", 246, 1, "i:i "), > + new Ia32Syscall ("io_getevents", 247, 5, "i:iiipp "), > + new Ia32Syscall ("io_submit", 248, 3, "i:iip "), > + new Ia32Syscall ("io_cancel", 249, 3, "i:ipp "), > + new Ia32Syscall ("fadvise64", 250), > + new Ia32Syscall (251), > + new Ia32Syscall ("exit_group", 252, 1, " :i ", true), > + new Ia32Syscall ("lookup_dcookie", 253), > + new Ia32Syscall ("epoll_create", 254), > + new Ia32Syscall ("epoll_ctl", 255), > + new Ia32Syscall ("epoll_wait", 256), > + new Ia32Syscall ("remap_file_pages", 257), > + new Ia32Syscall ("set_tid_address", 258), > + new Ia32Syscall ("timer_create", 259), > + new Ia32Syscall ("timer_settime", 260), > + new Ia32Syscall ("timer_gettime", 261), > + new Ia32Syscall ("timer_getoverrun", 262), > + new Ia32Syscall ("timer_delete", 263), > + new Ia32Syscall ("clock_settime", 264), > + new Ia32Syscall ("clock_gettime", 265), > + new Ia32Syscall ("clock_getres", 266), > + new Ia32Syscall ("clock_nanosleep", 267), > + new Ia32Syscall ("statfs64", 268), > + new Ia32Syscall ("fstatfs64", 269), > + new Ia32Syscall ("tgkill", 270), > + new Ia32Syscall ("utimes", 271), > + new Ia32Syscall ("fadvise64_64", 272) > + }; > + > + > + static class SocketSubSyscall > + extends Ia32Syscall > + { > + SocketSubSyscall (String name, int number) > + { > + super (name, number); > + } > + SocketSubSyscall (String name, int number, int numArgs, String argList) > + { > + super (name, number, numArgs, argList); > + } > + > + public long getArguments (Task task, int n) > + { > + /** Arguments in socket subcalls are dereferenced. */ > + Isa isa; > + try > + { > + isa = task.getIsa(); > + } > + catch (Exception e) > + { > + throw new RuntimeException ("Could not get isa"); > + } > + long base = isa.getRegisterByName("ecx").get (task); > + > + //System.out.println(Long.toHexString(base) + " " + n); > + return task.memory.getInt(base + (n-1) * isa.getWordSize()); > + } > + } > + > + static Syscall[] socketSubcallList = { > + new SocketSubSyscall ("", SOCKET_NUM), > + new SocketSubSyscall ("socket", SOCKET_NUM, 3, "i:iii"), > + new SocketSubSyscall ("bind", SOCKET_NUM, 3, "i:ipi "), > + new SocketSubSyscall ("connect", SOCKET_NUM, 3, "i:ipi "), > + new SocketSubSyscall ("listen", SOCKET_NUM, 2, "i:ii "), > + new SocketSubSyscall ("accept", SOCKET_NUM, 3, "i:ipp "), > + new SocketSubSyscall ("getsockname",SOCKET_NUM, 3, "i:ipp "), > + new SocketSubSyscall ("getpeername",SOCKET_NUM, 4, "i:iiip "), > + new SocketSubSyscall ("socketpair", SOCKET_NUM, 4, "i:iiip "), > + new SocketSubSyscall ("send", SOCKET_NUM, 4, "i:ipii "), > + new SocketSubSyscall ("recv", SOCKET_NUM, 4, "i:ipii "), > + new SocketSubSyscall ("sendto", SOCKET_NUM, 6, "i:ipiipi"), > + new SocketSubSyscall ("recvfrom", SOCKET_NUM, 6, "i:ipiipp "), > + new SocketSubSyscall ("shutdown", SOCKET_NUM, 2, "i:ii "), > + new SocketSubSyscall ("setsockopt", SOCKET_NUM, 5, "i:iiipp "), > + new SocketSubSyscall ("getsockopt", SOCKET_NUM, 5, "i:iiipp "), > + new SocketSubSyscall ("sendmsg", SOCKET_NUM, 5, "i:iiipp "), > + new SocketSubSyscall ("recvmsg", SOCKET_NUM, 5, "i:iiipp ") > + }; > + > + > + static class IpcSubSyscall > + extends Ia32Syscall > + { > + IpcSubSyscall (String name, int number) > + { > + super (name, number); > + } > + IpcSubSyscall (String name, int number, int numArgs, String argList) > + { > + super (name, number, numArgs, argList); > + } > + public long getArguments (Task task, int n) > + { > + if (n == 0) > + return super.getArguments (task, 0); > + else > + // these arguements are shifted by one. > + return super.getArguments (task, n+1); > + } > + > + } > + /**FIXME: No argument list here.*/ > + static Syscall[] ipcSubcallList = { > + new IpcSubSyscall ("semop", IPC_NUM), > + new IpcSubSyscall ("semget", IPC_NUM), > + new IpcSubSyscall ("semctl", IPC_NUM), > + new IpcSubSyscall ("semtimedop", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("msgsnd", IPC_NUM), > + new IpcSubSyscall ("msgrcv", IPC_NUM), > + new IpcSubSyscall ("msgget", IPC_NUM), > + new IpcSubSyscall ("msgctl", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("", IPC_NUM), > + new IpcSubSyscall ("shmat", IPC_NUM), > + new IpcSubSyscall ("shmdt", IPC_NUM), > + new IpcSubSyscall ("shmget", IPC_NUM), > + new IpcSubSyscall ("shmctl", IPC_NUM) > + }; > + > + public static Syscall syscallByNum (Task task, int number) > + { > + if (number != SOCKET_NUM && number != IPC_NUM) > + return Syscall.syscallByNum (number, task); > + else > + { > + /** sub syscall number is in %ebx. */ > + int subSyscallNumber = 0; > + try > + { > + subSyscallNumber = (int) task.getIsa().getRegisterByName("ebx").get (task); > + } > + catch (Exception e) > + { > + throw new RuntimeException ("Could not get isa"); > + } > + > + if (number == SOCKET_NUM) > + { > + return socketSubcallList[subSyscallNumber]; > + } > + else > + { > + return ipcSubcallList[subSyscallNumber]; > + } > + } > + } > +} > --- /dev/null 2006-09-01 16:42:34.468363500 +0800 > +++ frysk-core/frysk/proc/LinuxEMT64Syscall.java 2006-09-13 17:29:38.000000000 +0800 > @@ -0,0 +1,383 @@ > +// This file is part of the program FRYSK. > +// > +// Copyright 2005, 2006 Red Hat Inc. > +// > +// FRYSK is free software; you can redistribute it and/or modify it > +// under the terms of the GNU General Public License as published by > +// the Free Software Foundation; version 2 of the License. > +// > +// FRYSK is distributed in the hope that it will be useful, but > +// WITHOUT ANY WARRANTY; without even the implied warranty of > +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +// General Public License for more details. > +// > +// You should have received a copy of the GNU General Public License > +// along with FRYSK; if not, write to the Free Software Foundation, > +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. > +// > +// In addition, as a special exception, Red Hat, Inc. gives You the > +// additional right to link the code of FRYSK with code not covered > +// under the GNU General Public License ("Non-GPL Code") and to > +// distribute linked combinations including the two, subject to the > +// limitations in this paragraph. Non-GPL Code permitted under this > +// exception must only link to the code of FRYSK through those well > +// defined interfaces identified in the file named EXCEPTION found in > +// the source code files (the "Approved Interfaces"). The files of > +// Non-GPL Code may instantiate templates or use macros or inline > +// functions from the Approved Interfaces without causing the > +// resulting work to be covered by the GNU General Public > +// License. Only Red Hat, Inc. may make changes or additions to the > +// list of Approved Interfaces. You must obey the GNU General Public > +// License in all respects for all of the FRYSK code and other code > +// used in conjunction with FRYSK except the Non-GPL Code covered by > +// this exception. If you modify this file, you may extend this > +// exception to your version of the file, but you are not obligated to > +// do so. If you do not wish to provide this exception without > +// modification, you must delete this exception statement from your > +// version and license this file solely under the GPL without > +// exception. > + > +package frysk.proc; > + > +import java.util.HashMap; > + > +public class LinuxEMT64Syscall > +{ > + > + // This is used to keep track of syscalls whose number we do not > + // know. > + static HashMap unknownSyscalls; > + > + static class EMT64Syscall > + extends Syscall > + { > + EMT64Syscall (String name, int number, int numArgs, > + String argList, boolean noreturn) > + { > + super (name, number, numArgs, argList, noreturn); > + } > + EMT64Syscall (String name, int number, int numArgs, String argList) > + { > + super (name, number, numArgs, argList); > + } > + EMT64Syscall (String name, int number, int numArgs) > + { > + super (name, number, numArgs); > + } > + EMT64Syscall (String name, int number) > + { > + super (name, number); > + } > + EMT64Syscall (int number) > + { > + super (number); > + } > + public long getArguments (Task task, int n) > + { > + Isa isa; > + try > + { > + isa = task.getIsa(); > + } > + catch (Exception e) > + { > + throw new RuntimeException ("Could not get isa"); > + } > + > + switch (n) { > + case 0: > + return isa.getRegisterByName ("orig_rax").get(task); > + case 1: > + return isa.getRegisterByName("rdi").get(task); > + case 2: > + return isa.getRegisterByName("rsi").get (task); > + case 3: > + return isa.getRegisterByName("rdx").get (task); > + case 4: > + return isa.getRegisterByName("r10").get (task); > + case 5: > + return isa.getRegisterByName("r8").get (task); > + case 6: > + return isa.getRegisterByName("r9").get (task); > + default: > + throw new RuntimeException ("unknown syscall arg"); > + } > + } > + public long getReturnCode (Task task) > + { > + Isa isa; > + try > + { > + isa = task.getIsa(); > + } > + catch (Exception e) > + { > + throw new RuntimeException ("Could not get isa"); > + } > + return isa.getRegisterByName ("rax").get (task); > + } > + } > + static Syscall[] syscallList = { > + new EMT64Syscall ("read", 0, 3, "i:ibn "), > + new EMT64Syscall ("write", 1, 3, "i:ibn "), > + new EMT64Syscall ("open", 2, 3, "i:siv "), > + new EMT64Syscall ("close", 3, 1, "i:i "), > + new EMT64Syscall ("stat", 4, 2, "i:sp "), > + new EMT64Syscall ("fstat", 5, 2, "i:ip "), > + new EMT64Syscall ("lstat", 6, 2, "i:sp "), > + new EMT64Syscall ("poll", 7, 3, "i:pii "), > + new EMT64Syscall ("lseek", 8, 3, "i:iii "), > + new EMT64Syscall ("mmap", 9, 6, "b:aniiii "), > + new EMT64Syscall ("mprotect", 10, 3, "i:aii "), > + new EMT64Syscall ("munmap", 11, 2, "i:ai "), > + new EMT64Syscall ("brk", 12, 1, "i:p "), > + new EMT64Syscall ("rt_sigaction", 13), > + new EMT64Syscall ("rt_sigprocmask", 14), > + new EMT64Syscall ("rt_sigreturn", 15), > + new EMT64Syscall ("ioctl", 16, 3, "i:iiI "), > + new EMT64Syscall ("pread64", 17), > + new EMT64Syscall ("pwrite64", 18), > + new EMT64Syscall ("readv", 19, 3, "i:ipi "), > + new EMT64Syscall ("writev", 20, 3, "i:ipi "), > + new EMT64Syscall ("access", 21, 2, "i:si "), > + new EMT64Syscall ("pipe", 22, 1, "i:f "), > + new EMT64Syscall ("select", 23, 5, "i:iPPPP "), > + new EMT64Syscall ("sched_yield", 24, 0, "i: "), > + new EMT64Syscall ("mremap", 25, 4, "b:aini "), > + new EMT64Syscall ("msync", 26, 3, "i:aii "), > + new EMT64Syscall ("mincore", 27, 3, "i:anV "), > + new EMT64Syscall ("madvise", 28, 3, "i:pii "), > + new EMT64Syscall ("shmget", 29, 3, "i:iii "), > + new EMT64Syscall ("shmat", 30, 3, "p:ipi "), > + new EMT64Syscall ("shmctl", 31, 3, "i:iip "), > + new EMT64Syscall ("dup", 32, 1, "i:i "), > + new EMT64Syscall ("dup2", 33, 2, "i:ii "), > + new EMT64Syscall ("pause", 34, 0, "i: "), > + new EMT64Syscall ("nanosleep", 35, 2, "i:pp "), > + new EMT64Syscall ("getitimer", 36, 2, "i:ip "), > + new EMT64Syscall ("alarm", 37, 1, "i:i "), > + new EMT64Syscall ("setitimer", 38, 3, "i:ipp "), > + new EMT64Syscall ("getpid", 39, 0, "i: "), > + new EMT64Syscall ("sendfile", 40, 4, "i:iipi "), > + new EMT64Syscall ("socket", 41, 3, "i:iii "), > + new EMT64Syscall ("connect", 42), > + new EMT64Syscall ("accept", 43), > + new EMT64Syscall ("sendto", 44), > + new EMT64Syscall ("recvfrom", 45), > + new EMT64Syscall ("sendmsg", 46), > + new EMT64Syscall ("recvmsg", 47), > + new EMT64Syscall ("shutdown", 48), > + new EMT64Syscall ("bind", 49, 3, "i:ipi "), > + new EMT64Syscall ("listen", 50, 2, "i:ii "), > + new EMT64Syscall ("getsockname", 51, 3, "i:ipp "), > + new EMT64Syscall ("getpeername", 52, 4, "i:iiip "), > + new EMT64Syscall ("socketpair", 53, 4, "i:iiip "), > + new EMT64Syscall ("setsockopt", 54, 5, "i:iiipp "), > + new EMT64Syscall ("getsockopt", 55, 5, "i:iiipp "), > + new EMT64Syscall ("clone", 56, 2, "i:ip "), > + new EMT64Syscall (58), > + new EMT64Syscall ("fork", 57, 0, "i: "), > + new EMT64Syscall ("execve", 59, 3, "i:ppp "), > + new EMT64Syscall ("exit", 60, 1), > + new EMT64Syscall ("wait4", 61, 4, "i:iWiP "), > + new EMT64Syscall ("kill", 62, 2, "i:ii "), > + new EMT64Syscall ("uname", 63, 1, "i:p "), > + new EMT64Syscall ("semget", 64), > + new EMT64Syscall ("semop", 65), > + new EMT64Syscall ("semctl", 66), > + new EMT64Syscall ("shmdt", 67), > + new EMT64Syscall ("msgget", 68), > + new EMT64Syscall ("msgsnd", 69), > + new EMT64Syscall ("msgrcv", 70), > + new EMT64Syscall ("msgctl", 71), > + new EMT64Syscall ("fcntl", 72, 3, "i:iiF "), > + new EMT64Syscall ("flock", 73, 2, "i:ii "), > + new EMT64Syscall ("fsync", 74, 1, "i:i "), > + new EMT64Syscall ("fdatasync", 75, 1, "i:i "), > + new EMT64Syscall ("truncate", 76, 2, "i:si "), > + new EMT64Syscall ("ftruncate", 77, 2, "i:ii "), > + new EMT64Syscall ("getdents", 78), > + new EMT64Syscall ("getcwd", 79, 2, "i:bi "), > + new EMT64Syscall ("chdir", 80, 1, "i:s "), > + new EMT64Syscall ("fchdir", 81, 1, "i:i "), > + new EMT64Syscall ("rename", 82, 2, "i:ss "), > + new EMT64Syscall ("mkdir", 83, 2, "i:si "), > + new EMT64Syscall ("rmdir", 84, 1, "i:s "), > + new EMT64Syscall ("creat", 85, 2, "i:sv"), > + new EMT64Syscall ("link", 86, 2, "i:ss "), > + new EMT64Syscall ("unlink", 87, 1, "i:s "), > + new EMT64Syscall ("symlink", 88, 2, "i:ss "), > + new EMT64Syscall ("readlink", 89, 3, "i:spi "), > + new EMT64Syscall ("chmod", 90, 2, "i:si "), > + new EMT64Syscall ("fchmod", 91, 2, "i:ii "), > + new EMT64Syscall ("chown", 92, 3, "i:sii "), > + new EMT64Syscall ("fchown", 93, 3, "i:iii "), > + new EMT64Syscall ("lchown", 94, 3, "i:sii "), > + new EMT64Syscall ("umask", 95, 1, "i:i "), > + new EMT64Syscall ("gettimeofday", 96, 2, "i:PP "), > + new EMT64Syscall ("getrlimit", 97, 2, "i:ip "), > + new EMT64Syscall ("getrusage", 98, 2, "i:ip "), > + new EMT64Syscall ("sysinfo", 99, 1, "i:p "), > + new EMT64Syscall ("times", 100, 1, "i:p "), > + new EMT64Syscall ("ptrace", 101, 4, "i:iiii "), > + new EMT64Syscall ("getuid", 102, 0, "i: "), > + new EMT64Syscall ("syslog", 103), > + new EMT64Syscall ("getgid", 104, 0, "i: "), > + new EMT64Syscall ("setuid", 105, 1, "i:i "), > + new EMT64Syscall ("setgid", 106, 1, "i:i "), > + new EMT64Syscall ("geteuid", 107, 0, "i: "), > + new EMT64Syscall ("getegid", 108, 0, "i: "), > + new EMT64Syscall ("setpgid", 109, 2, "i:ii "), > + new EMT64Syscall ("getppid", 110, 0, "i: "), > + new EMT64Syscall ("getpgrp", 111, 0, "i: "), > + new EMT64Syscall ("setsid", 112, 0, "i: "), > + new EMT64Syscall ("setreuid", 113, 2, "i:ii "), > + new EMT64Syscall ("setregid", 114, 2, "i:ii "), > + new EMT64Syscall ("getgroups", 115, 2, "i:ip "), > + new EMT64Syscall ("setgroups", 116, 2, "i:ip "), > + new EMT64Syscall ("setresuid", 117, 3, "i:iii "), > + new EMT64Syscall ("getresuid", 118, 3, "i:ppp "), > + new EMT64Syscall ("setresgid", 119, 3, "i:iii "), > + new EMT64Syscall ("getresgid", 120, 3, "i:ppp "), > + new EMT64Syscall ("getpgid", 121, 1, "i:i "), > + new EMT64Syscall ("setfsuid", 122, 1, "i:i "), > + new EMT64Syscall ("setfsgid", 123, 1, "i:i "), > + new EMT64Syscall ("getsid", 124, 1, "i:i "), > + new EMT64Syscall ("capget", 125, 2, "i:pp "), > + new EMT64Syscall ("capset", 126, 2, "i:pp "), > + new EMT64Syscall ("rt_sigpending", 127, 2, "i:pi "), > + new EMT64Syscall ("rt_sigtimedwait", 128, 4, "i:pppi " ), > + new EMT64Syscall ("rt_sigqueueinfo", 129 ), > + new EMT64Syscall ("rt_sigsuspend", 130 ), > + new EMT64Syscall ("sigaltstack", 131, 2, "i:PP "), > + new EMT64Syscall ("utime", 132, 2, "i:sP "), > + new EMT64Syscall ("mknod", 133, 3, "i:sii "), > + new EMT64Syscall ("uselib", 134, 1, "i:s "), > + new EMT64Syscall ("personality", 135, 1, "i:i "), > + new EMT64Syscall ("ustat", 136, 2, "i:ip "), > + new EMT64Syscall ("statfs", 137, 2, "i:sp "), > + new EMT64Syscall ("fstatfs", 138, 2, "i:ip "), > + new EMT64Syscall ("sysfs", 139, 1, "i:i "), > + new EMT64Syscall ("getpriority", 140, 2, "i:ii "), > + new EMT64Syscall ("setpriority", 141, 3, "i:iii "), > + new EMT64Syscall ("sched_setparam", 142), > + new EMT64Syscall ("sched_getparam", 143), > + new EMT64Syscall ("sched_setscheduler", 144), > + new EMT64Syscall ("sched_getscheduler", 145), > + new EMT64Syscall ("sched_get_priority_max", 146), > + new EMT64Syscall ("sched_get_priority_min", 147), > + new EMT64Syscall ("sched_rr_get_interval", 148), > + new EMT64Syscall ("mlock", 149, 2, "i:bn "), > + new EMT64Syscall ("munlock", 150, 2, "i:ai "), > + new EMT64Syscall ("mlockall", 151, 1, "i:i "), > + new EMT64Syscall ("munlockall", 152, 0, "i: "), > + new EMT64Syscall ("vhangup", 153, 1, "i:i "), > + new EMT64Syscall ("modify_ldt", 154, 3, "i:ipi "), > + new EMT64Syscall ("pivot_root", 155, 2, "i:ss "), > + new EMT64Syscall ("_sysctl", 156), > + new EMT64Syscall ("prctl", 157, 5, "i:iiiii "), > + new EMT64Syscall ("arch_prctl", 158), > + new EMT64Syscall ("adjtimex", 159, 1, "i:p "), > + new EMT64Syscall ("setrlimit", 160, 2, "i:ip "), > + new EMT64Syscall ("chroot", 161, 1, "i:s "), > + new EMT64Syscall ("sync", 162, 0, "i: "), > + new EMT64Syscall ("acct", 163, 1, "i:S "), > + new EMT64Syscall ("settimeofday", 164, 2, "i:PP "), > + new EMT64Syscall ("mount", 165, 5, "i:sssip "), > + new EMT64Syscall ("umount2", 166, 2, "i:si "), > + new EMT64Syscall ("swapon", 167, 2, "i:si "), > + new EMT64Syscall ("swapoff", 168, 1, "i:s "), > + new EMT64Syscall ("reboot", 169, 1, "i:i "), > + new EMT64Syscall ("sethostname", 170, 2, "i:pi "), > + new EMT64Syscall ("setdomainname", 171), > + new EMT64Syscall ("iopl", 172, 1, "i:i "), > + new EMT64Syscall ("ioperm", 173, 3, "i:iii "), > + new EMT64Syscall ("create_module", 174, 3), > + new EMT64Syscall ("init_module", 175, 5), > + new EMT64Syscall ("delete_module", 176, 3), > + new EMT64Syscall ("get_kernel_syms", 177, 1, "i:p "), > + new EMT64Syscall ("query_module", 178, 5, "i:sipip "), > + new EMT64Syscall ("quotactl", 179, 4, "i:isip "), > + new EMT64Syscall ("nfsservctl", 180, 3, "i:ipp "), > + new EMT64Syscall ("getpmsg", 181), > + new EMT64Syscall ("putpmsg", 182), > + new EMT64Syscall ("afs_syscall", 183), > + new EMT64Syscall ("tuxcall", 184), > + new EMT64Syscall ("security", 185), > + new EMT64Syscall ("gettid", 186, 0), > + new EMT64Syscall ("readahead", 187, 4, "i:ihli "), > + new EMT64Syscall ("setxattr", 188), > + new EMT64Syscall ("lsetxattr", 189 ), > + new EMT64Syscall ("fsetxattr", 190 ), > + new EMT64Syscall ("getxattr", 191 ), > + new EMT64Syscall ("lgetxattr", 192 ), > + new EMT64Syscall ("fgetxattr", 193 ), > + new EMT64Syscall ("listxattr", 194 ), > + new EMT64Syscall ("llistxattr", 195 ), > + new EMT64Syscall ("flistxattr", 196 ), > + new EMT64Syscall ("removexattr", 197 ), > + new EMT64Syscall ("lremovexattr", 198 ), > + new EMT64Syscall ("fremovexattr", 199 ), > + new EMT64Syscall ("tkill", 200, 2, "i:ii "), > + new EMT64Syscall ("time", 201, 1, "i:P "), > + new EMT64Syscall ("futex", 202, 4, "i:piip "), > + new EMT64Syscall ("sched_setaffinity", 203 ), > + new EMT64Syscall ("sched_getaffinity", 204 ), > + new EMT64Syscall ("set_thread_area", 205, 1, "i:p "), > + new EMT64Syscall ("io_setup", 206, 2, "i:ip "), > + new EMT64Syscall ("io_destroy", 207, 1, "i:i "), > + new EMT64Syscall ("io_getevents", 208, 5, "i:iiipp "), > + new EMT64Syscall ("io_submit", 209, 3, "i:iip "), > + new EMT64Syscall ("io_cancel", 210, 3, "i:ipp "), > + new EMT64Syscall ("get_thread_area", 211, 1, "i:p "), > + new EMT64Syscall ("lookup_dcookie", 212), > + new EMT64Syscall ("epoll_create", 213), > + new EMT64Syscall ("epoll_ctl_old", 214), > + new EMT64Syscall ("epoll_wait_old", 215), > + new EMT64Syscall ("remap_file_pages", 216), > + new EMT64Syscall ("getdents64", 217, 3, "i:ipi "), > + new EMT64Syscall ("set_tid_address", 218), > + new EMT64Syscall ("restart_syscall", 219), > + new EMT64Syscall ("semtimedop", 220), > + new EMT64Syscall ("fadvise64", 221), > + new EMT64Syscall ("timer_create", 222), > + new EMT64Syscall ("timer_settime", 223), > + new EMT64Syscall (224), > + new EMT64Syscall (225), > + new EMT64Syscall ("timer_delete", 226), > + new EMT64Syscall ("clock_settime", 227), > + new EMT64Syscall ("clock_gettime", 228), > + new EMT64Syscall ("clock_getres", 229), > + new EMT64Syscall ("clock_nanosleep", 230), > + new EMT64Syscall ("exit_group", 231, 1, " :i "), > + new EMT64Syscall ("epoll_wait", 232), > + new EMT64Syscall ("epoll_ctl", 233), > + new EMT64Syscall ("tgkill", 234), > + new EMT64Syscall ("utimes", 235), > + new EMT64Syscall ("vserver", 236), > + new EMT64Syscall ("mbind", 237), > + new EMT64Syscall ("set_mempolicy", 238), > + new EMT64Syscall ("get_mempolicy", 239), > + new EMT64Syscall ("mq_open", 240), > + new EMT64Syscall ("mq_unlink", 241), > + new EMT64Syscall ("mq_timedsend", 242), > + new EMT64Syscall ("mq_timedreceive", 243), > + new EMT64Syscall ("mq_notify", 244), > + new EMT64Syscall ("mq_getsetattr", 245), > + new EMT64Syscall ("kexec_load", 246), > + new EMT64Syscall ("waitid", 247), > + new EMT64Syscall ("add_key", 248), > + new EMT64Syscall ("request_key", 249), > + new EMT64Syscall ("keyctl", 250), > + new EMT64Syscall ("ioprio_set", 251), > + new EMT64Syscall ("ioprio_get", 252), > + new EMT64Syscall ("inotify_init", 253), > + new EMT64Syscall ("inotify_add_watch", 254), > + new EMT64Syscall ("inotify_rm_watch", 255) > + }; > + > + public static Syscall syscallByNum (Task task, int number) > + { > + return Syscall.syscallByNum (number, task); > + } > +} > From cagney@redhat.com Wed Sep 13 18:02:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 13 Sep 2006 18:02:00 -0000 Subject: Two patches to add bi-arch test in frysk. In-Reply-To: <1158131338.3390.103.camel@YZ_X86_64> References: <1158131338.3390.103.camel@YZ_X86_64> Message-ID: <450847C0.3050900@redhat.com> Yong Zheng wrote: > hi, > > On PPC64, applications are compiled into 32-bit mode by default, which > means most applications running on PPC64 are in 32-bit mode. So it's > necessary for frysk to do bi-arch test on PPC64. On X86_64, although > applications are compiled into 64-bit mode by default, it's also needed > for us to do bi-arch test. We ever discussed this problem and got some > precious feedbacks. Read the following URL for details: > http://sourceware.org/ml/frysk/2006-q3/msg00278.html. > > Yong, I'll try to catch up tonight (my time) on irc to talk 'bout this - just a few questions. And I need to think a little :-) Andrew From cmoller@redhat.com Wed Sep 13 18:10:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Wed, 13 Sep 2006 18:10:00 -0000 Subject: fc6 frysk-core failures. In-Reply-To: <45083D27.1020108@redhat.com> References: <45077A9C.1000604@redhat.com> <45083D27.1020108@redhat.com> Message-ID: <45084997.5030804@redhat.com> BTW, forgot to mention the obvious: the proximate source of that error msg is in the brute-force kill 'em all code: try { Ptrace.detach (pid, Sig.KILL); logger.log (Level.FINE, "{0} detach -KILL {1,number,integer}\n", new Object[] { this, child }); } catch (Errno.Esrch e) { // Toss it. logger.log (Level.FINE, "{0} detach -KILL {1,number,integer} (failed)\n", new Object[] { this, child }); } presumably indicating that the process identified by the pid in a ptrace(PTRACE_DETACH, pid,....) has either already terminated or is no longer being traced, if it ever was. I was assuming that it can't be as simple as a busted PTRACE_DETACH, but on the other hand... cm Andrew Cagney mumbled something on 09/13/2006 01:17 PM: > Chris, > > This is good progress and the thing to be looking at. Unfortunatly, > it may, or may not be the source of the problems, hard to say right now. > > Broadly what is happening is that the test as successfully run (true? > was there an earlier message reporting fail?) and now the tearDown > code is going through and trying to destroy (using very brute force) > any processes created during the test's run. The brute force process, > put simply, throws everything and anything repeatedly at the processes > -- kill -9, kill -cont, detach, ... -- in the hope it can be made to > go away. A failure here could be due to kernel differences, but could > just as easily be a timing issue. > > In the log, going backwards from: > > testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) > >>>>>>>>>>>>>>>> start tearDown > > what are the last few interactions involving pid 14860? In particular > is there anything indicating the state of that pid/tid's object. > > Andrew > > > > Chris Moller wrote: >> Running ./frysk-core/TestRunner -c FINE frysk.proc.TestProcTasksObserver >> fails on fc6. The fc6 logs and the fc5 logs are, aside from minor >> variations in the order of things, are identical until they get to: >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> >>>>>>>>>>>>>>>> start tearDown >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> kill -KILL 14860 >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> kill -CONT 14860 >> >> 12-Sep-06 11:13:47 PM frysk.proc.TestLib tearDown >> FINE: >> testManyExistingThreadAttached(frysk.proc.TestProcTasksObserver) >> detach -KILL 14860 (failed) >> >> >> >> under fc5, and >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) >> >>>>>>>>>>>>>>>> start tearDown >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill >> -KILL 29450 >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) kill >> -CONT 29450 >> >> 12-Sep-06 11:20:26 PM frysk.proc.TestLib tearDown >> FINE: testDoCloneAttached(frysk.proc.TestProcTasksObserver) detach >> -KILL 29450 >> >> under fc6. I.e., prima facie, the detach -KILL seems shows a failure >> under fc6 and a pass under fc5. I'll poke at it some more tomorrow. >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From timoore@redhat.com Wed Sep 13 18:40:00 2006 From: timoore@redhat.com (Tim Moore) Date: Wed, 13 Sep 2006 18:40:00 -0000 Subject: [patch] System call for multi-architecture In-Reply-To: <450845B2.3010704@redhat.com> References: <20060913131050.GC17676@GreenHouse.cn.ibm.com> <450845B2.3010704@redhat.com> Message-ID: <4508506E.1090509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Cagney wrote: > Yao, this is good, and a great jump forward. Thanks! > One political nit, can you use the name x86_64, instead of em64t or > emt64 or amd64 for the 64-bit ISA that is an extension of ia32? > Andrew > I'll do the syscall list for 32bit IA32 on x86_64. I can also take on changing emt64 to something more palatable, given that I made the unfortunate choice in the first place :) Tim > > Yao Qi wrote: >> There were two threads in this maillist about this issue, and I >> modified this patch for several time per Mark and Tom's comments, and >> feedback from these two threads. >> >> This patch could provide, >> 1) draft system call list(for x86, x86_64, and powerpc). >> 2) ftrace could work on these three platforms. >> >> This patch could not provide, or could provide in the next step, >> 1) 64-bit ftrace trace 32-bit app. >> 2) accurate arguments for some system calls. >> >> Mark, Sami, >> the patch could give you syscallLists for different architecture. >> >> + new IpcSubSyscall ("semop", IPC_NUM), >> + new IpcSubSyscall("semget", IPC_NUM), >> + new IpcSubSyscall("semctl", IPC_NUM), >> + new IpcSubSyscall("semtimedop", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("msgsnd", IPC_NUM), >> + new IpcSubSyscall("msgrcv", IPC_NUM), >> + new IpcSubSyscall("msgget", IPC_NUM), >> + new IpcSubSyscall("msgctl", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("", IPC_NUM), >> + new IpcSubSyscall("shmat", IPC_NUM), >> + new IpcSubSyscall("shmdt", IPC_NUM), >> + new IpcSubSyscall("shmget", IPC_NUM), >> + new IpcSubSyscall("shmctl", IPC_NUM) >> + }; >> + >> + public static Syscall syscallByNum (Task task, int number) >> + { >> + if (number != SOCKET_NUM && number != IPC_NUM) >> + return Syscall.syscallByNum (number, task); >> + else >> + { >> + /** sub syscall number is in . */ >> + int subSyscallNumber = 0; >> + try >> + { >> + subSyscallNumber = (int) >> task.getIsa().getRegisterByName("orig_r3").get(task); >> + } >> + catch (Exception e) >> + { >> + throw new RuntimeException ("Could not get isa"); >> + } >> + >> + if (number == SOCKET_NUM) >> + { >> + return socketSubcallList[subSyscallNumber]; >> + } >> + else >> + { >> + return ipcSubcallList[subSyscallNumber]; >> + } >> + } >> + } >> +} >> --- /dev/null 2006-09-01 16:42:34.468363500 +0800 >> +++ frysk-core/frysk/proc/LinuxIa32Syscall.java 2006-09-13 >> 17:12:51.000000000 +0800 >> @@ -0,0 +1,531 @@ >> +// This file is part of the program FRYSK. >> +// >> +// Copyright 2006 Red Hat Inc. >> +// >> +// FRYSK is free software; you can redistribute it and/or modify it >> +// under the terms of the GNU General Public License as published by >> +// the Free Software Foundation; version 2 of the License. >> +// >> +// FRYSK is distributed in the hope that it will be useful, but >> +// WITHOUT ANY WARRANTY; without even the implied warranty of >> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> +// General Public License for more details. >> +// +// You should have received a copy of the GNU General Public License >> +// along with FRYSK; if not, write to the Free Software Foundation, >> +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. >> +// +// In addition, as a special exception, Red Hat, Inc. gives You the >> +// additional right to link the code of FRYSK with code not covered >> +// under the GNU General Public License ("Non-GPL Code") and to >> +// distribute linked combinations including the two, subject to the >> +// limitations in this paragraph. Non-GPL Code permitted under this >> +// exception must only link to the code of FRYSK through those well >> +// defined interfaces identified in the file named EXCEPTION found in >> +// the source code files (the "Approved Interfaces"). The files of >> +// Non-GPL Code may instantiate templates or use macros or inline >> +// functions from the Approved Interfaces without causing the >> +// resulting work to be covered by the GNU General Public >> +// License. Only Red Hat, Inc. may make changes or additions to the >> +// list of Approved Interfaces. You must obey the GNU General Public >> +// License in all respects for all of the FRYSK code and other code >> +// used in conjunction with FRYSK except the Non-GPL Code covered by >> +// this exception. If you modify this file, you may extend this >> +// exception to your version of the file, but you are not obligated to >> +// do so. If you do not wish to provide this exception without >> +// modification, you must delete this exception statement from your >> +// version and license this file solely under the GPL without >> +// exception. >> + >> +package frysk.proc; >> + >> +import java.util.HashMap; >> + >> +public class LinuxIa32Syscall >> +{ >> + static final int SOCKET_NUM = 102; >> + static final int IPC_NUM = 117; >> + >> + // This is used to keep track of syscalls whose number we do not >> + // know. >> + static HashMap unknownSyscalls; >> + >> + static class Ia32Syscall + extends Syscall >> + { >> + Ia32Syscall (String name, int number, int numArgs, + >> String argList, boolean noreturn) >> + { >> + super (name, number, numArgs, argList, noreturn); >> + } >> + Ia32Syscall (String name, int number, int numArgs, String argList) >> + { >> + super (name, number, numArgs, argList); >> + } >> + Ia32Syscall (String name, int number, int numArgs) >> + { >> + super (name, number, numArgs); >> + } >> + Ia32Syscall (String name, int number) >> + { >> + super (name, number); >> + } >> + Ia32Syscall (int number) >> + { >> + super (number); >> + } >> + >> + public long getArguments (Task task, int n) >> + { >> + Isa isa; >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (Exception e) >> + { >> + throw new RuntimeException ("Could not get isa"); >> + } >> + >> + switch (n) >> + { >> + case 0: >> + return isa.getRegisterByName ("orig_eax").get (task); >> + case 1: >> + return isa.getRegisterByName("ebx").get (task); >> + case 2: >> + return isa.getRegisterByName("ecx").get (task); >> + case 3: >> + return isa.getRegisterByName("edx").get (task); >> + case 4: >> + return isa.getRegisterByName("esi").get (task); >> + case 5: >> + return isa.getRegisterByName("edi").get (task); >> + case 6: >> + return isa.getRegisterByName("eax").get (task); >> + default: >> + throw new RuntimeException ("unknown syscall arg"); >> + } >> + } >> + public long getReturnCode (Task task) >> + { >> + Isa isa; >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (Exception e) >> + { >> + throw new RuntimeException ("Could not get isa"); >> + } >> + return isa.getRegisterByName ("eax").get (task); >> + } >> + } >> + + static Syscall[] syscallList = { >> + new Ia32Syscall (0), >> + new Ia32Syscall ("exit", 1, 1), >> + new Ia32Syscall ("fork", 2, 0, "i: "), >> + new Ia32Syscall ("read", 3, 3, "i:ibn "), >> + new Ia32Syscall ("write", 4, 3, "i:ibn "), >> + new Ia32Syscall ("open", 5, 3, "i:siv "), >> + new Ia32Syscall ("close", 6, 1, "i:i "), >> + new Ia32Syscall ("waitpid", 7, 3, "i:ipi "), >> + new Ia32Syscall ("creat", 8, 2, "i:sv"), >> + new Ia32Syscall ("link", 9, 2, "i:ss "), >> + new Ia32Syscall ("unlink", 10, 1, "i:s "), >> + new Ia32Syscall ("execve", 11, 3, "i:ppp "), >> + new Ia32Syscall ("chdir", 12, 1, "i:s "), >> + new Ia32Syscall ("time", 13, 1, "i:P "), >> + new Ia32Syscall ("sys_mknod", 14, 3, "i:sii "), >> + new Ia32Syscall ("chmod", 15, 2, "i:si "), >> + new Ia32Syscall ("lchown", 16, 3, "i:sii "), >> + new Ia32Syscall ("break", 17), >> + new Ia32Syscall ("old_stat", 18, 3, "i:pp "), >> + new Ia32Syscall ("lseek", 19, 3, "i:iii "), >> + new Ia32Syscall ("getpid", 20, 0, "i: "), >> + new Ia32Syscall ("mount", 21, 5, "i:sssip "), >> + new Ia32Syscall ("umount", 22, 1, "i:s "), >> + new Ia32Syscall ("setuid", 23, 1, "i:i "), >> + new Ia32Syscall ("getuid", 24, 0, "i: "), >> + new Ia32Syscall ("stime", 25, 1, "i:p "), >> + new Ia32Syscall ("ptrace", 26, 4, "i:iiii "), >> + new Ia32Syscall ("alarm", 27, 1, "i:i "), >> + new Ia32Syscall ("old_fstat", 28, 2, "i:ip "), >> + new Ia32Syscall ("pause", 29, 0, "i: "), >> + new Ia32Syscall ("utime", 30, 2, "i:sP "), >> + new Ia32Syscall ("stty", 31), >> + new Ia32Syscall ("gtty", 32), >> + new Ia32Syscall ("access", 33, 2, "i:si "), >> + new Ia32Syscall ("nice", 34, 1, "i:i "), >> + new Ia32Syscall ("ftime", 35, 1, "i:p "), >> + new Ia32Syscall ("sync", 36, 0, "i: "), >> + new Ia32Syscall ("kill", 37, 2, "i:ii "), >> + new Ia32Syscall ("rename", 38, 2, "i:ss "), >> + new Ia32Syscall ("mkdir", 39, 2, "i:si "), >> + new Ia32Syscall ("rmdir", 40, 1, "i:s "), >> + new Ia32Syscall ("dup", 41, 1, "i:i "), >> + new Ia32Syscall ("pipe", 42, 1, "i:f "), >> + new Ia32Syscall ("times", 43, 1, "i:p "), >> + new Ia32Syscall ("prof", 44), >> + new Ia32Syscall ("brk", 45, 1, "i:p "), >> + new Ia32Syscall ("setgid", 46, 1, "i:i "), >> + new Ia32Syscall ("getgid", 47, 0, "i: "), >> + new Ia32Syscall ("signal", 48, 2, "i:ii "), >> + new Ia32Syscall ("geteuid", 49, 0, "i: "), >> + new Ia32Syscall ("getegid", 50, 0, "i: "), >> + new Ia32Syscall ("acct", 51, 1, "i:S "), >> + new Ia32Syscall ("umount2", 52, 2, "i:si "), >> + new Ia32Syscall ("lock", 53), >> + new Ia32Syscall ("ioctl", 54, 3, "i:iiI "), >> + new Ia32Syscall ("fcntl", 55, 3, "i:iiF "), >> + new Ia32Syscall ("mpx", 56), >> + new Ia32Syscall ("setpgid", 57, 2, "i:ii "), >> + new Ia32Syscall ("ulimit", 58, 2, "i:ii "), >> + new Ia32Syscall ("oldolduname", 59), >> + new Ia32Syscall ("umask", 60, 1, "i:i "), >> + new Ia32Syscall ("chroot", 61, 1, "i:s "), >> + new Ia32Syscall ("ustat", 62, 2, "i:ip "), >> + new Ia32Syscall ("dup2", 63, 2, "i:ii "), >> + new Ia32Syscall ("getppid", 64, 0, "i: "), >> + new Ia32Syscall ("getpgrp", 65, 0, "i: "), >> + new Ia32Syscall ("setsid", 66, 0, "i: "), >> + new Ia32Syscall ("sigaction", 67, 3, "i:ipp "), >> + new Ia32Syscall ("sgetmask", 68), >> + new Ia32Syscall ("ssetmask", 69), >> + new Ia32Syscall ("setreuid", 70, 2, "i:ii "), >> + new Ia32Syscall ("setregid", 71, 2, "i:ii "), >> + new Ia32Syscall ("sigsuspend", 72, 1, "i:p "), >> + new Ia32Syscall ("sigpending", 73, 1, "i:p "), >> + new Ia32Syscall ("sethostname", 74, 2, "i:pi "), >> + new Ia32Syscall ("setrlimit", 75, 2, "i:ip "), >> + new Ia32Syscall ("getrlimit", 76, 2, "i:ip "), >> + new Ia32Syscall ("getrusage", 77, 2, "i:ip "), >> + new Ia32Syscall ("gettimeofday", 78, 2, "i:PP "), >> + new Ia32Syscall ("settimeofday", 79, 2, "i:PP "), >> + new Ia32Syscall ("getgroups", 80, 2, "i:ip "), >> + new Ia32Syscall ("setgroups", 81, 2, "i:ip "), >> + new Ia32Syscall ("select", 82, 5, "i:iPPPP "), >> + new Ia32Syscall ("symlink", 83, 2, "i:ss "), >> + new Ia32Syscall ("oldlstat", 84, 2, "i:pp "), >> + new Ia32Syscall ("readlink", 85, 3, "i:spi "), >> + new Ia32Syscall ("uselib", 86, 1, "i:s "), >> + new Ia32Syscall ("swapon", 87, 2, "i:si "), >> + new Ia32Syscall ("reboot", 88, 1, "i:i "), >> + new Ia32Syscall (89), >> + new Ia32Syscall ("mmap", 90, 6, "b:aniiii "), >> + new Ia32Syscall ("munmap", 91, 2, "i:ai "), >> + new Ia32Syscall ("truncate", 92, 2, "i:si "), >> + new Ia32Syscall ("ftruncate", 93, 2, "i:ii "), >> + new Ia32Syscall ("fchmod", 94, 2, "i:ii "), >> + new Ia32Syscall ("fchown", 95, 3, "i:iii "), >> + new Ia32Syscall ("getpriority", 96, 2, "i:ii "), >> + new Ia32Syscall ("setpriority", 97, 3, "i:iii "), >> + new Ia32Syscall ("profil", 98, 4, "i:piii "), >> + new Ia32Syscall ("statfs", 99, 2, "i:sp "), >> + new Ia32Syscall ("fstatfs", 100, 2, "i:ip "), >> + new Ia32Syscall ("ioperm", 101, 3, "i:iii "), >> + new Ia32Syscall ("socketcall", 102, 2, "i:ip "), >> + new Ia32Syscall ("klogctl", 103, 3, "i:isi "), >> + new Ia32Syscall ("setitimer", 104, 3, "i:ipp "), >> + new Ia32Syscall ("getitimer", 105, 2, "i:ip "), >> + new Ia32Syscall ("sys_stat", 106, 2, "i:sp "), >> + new Ia32Syscall ("sys_lstat", 107, 2, "i:sp "), >> + new Ia32Syscall ("sys_fstat", 108, 2, "i:ip "), >> + new Ia32Syscall ("old_uname", 109, 1, "i:p "), >> + new Ia32Syscall ("iopl", 110, 1, "i:i "), >> + new Ia32Syscall ("vhangup", 111, 1, "i:i "), >> + new Ia32Syscall ("idle", 112, 0, "i: "), >> + new Ia32Syscall (113), >> + new Ia32Syscall ("wait4", 114, 4, "i:iWiP "), >> + new Ia32Syscall ("swapoff", 115, 1, "i:s "), >> + new Ia32Syscall ("sysinfo", 116, 1, "i:p "), >> + new Ia32Syscall ("ipc", 117, 6, "i:iiiipi "), >> + new Ia32Syscall ("fsync", 118, 1, "i:i "), >> + new Ia32Syscall ("sigreturn", 119), >> + new Ia32Syscall ("clone", 120, 2, "i:ip "), >> + new Ia32Syscall ("setdomain", 121, 2, "i:si "), >> + new Ia32Syscall ("uname", 122, 1, "i:p "), >> + new Ia32Syscall ("modify_ldt", 123, 3, "i:ipi "), >> + new Ia32Syscall ("adjtimex", 124, 1, "i:p "), >> + new Ia32Syscall ("mprotect", 125, 3, "i:aii "), >> + new Ia32Syscall ("sigprocmask", 126, 3, "i:ipp "), >> + new Ia32Syscall ("create_module", 127, 3), >> + new Ia32Syscall ("init_module", 128, 5), >> + new Ia32Syscall ("delete_module", 129, 3), >> + new Ia32Syscall ("get_kernel_syms", 130, 1, "i:p "), >> + new Ia32Syscall ("quotactl", 131, 4, "i:isip "), >> + new Ia32Syscall ("getpgid", 132, 1, "i:i "), >> + new Ia32Syscall ("fchdir", 133, 1, "i:i "), >> + new Ia32Syscall ("bdflush", 134, 2, "i:ii "), >> + new Ia32Syscall ("sysfs", 135, 1, "i:i "), >> + new Ia32Syscall ("personality", 136, 1, "i:i "), >> + new Ia32Syscall ("afs_syscall", 137), >> + new Ia32Syscall ("setfsuid", 138, 1, "i:i "), >> + new Ia32Syscall ("setfsgid", 139, 1, "i:i "), >> + new Ia32Syscall ("llseek", 140, 5, "i:iuupi "), >> + new Ia32Syscall ("s_getdents", 141, 3, "i:ipi "), >> + new Ia32Syscall ("select", 142, 5, "i:iPPPP "), >> + new Ia32Syscall ("flock", 143, 2, "i:ii "), >> + new Ia32Syscall ("msync", 144, 3, "i:aii "), >> + new Ia32Syscall ("readv", 145, 3, "i:ipi "), >> + new Ia32Syscall ("writev", 146, 3, "i:ipi "), >> + new Ia32Syscall ("getsid", 147, 1, "i:i "), >> + new Ia32Syscall ("fdatasync", 148, 1, "i:i "), >> + new Ia32Syscall ("sysctl", 149, 1, "i:p "), >> + new Ia32Syscall ("mlock", 150, 2, "i:bn "), >> + new Ia32Syscall ("munlock", 151, 2, "i:ai "), >> + new Ia32Syscall ("mlockall", 152, 1, "i:i "), >> + new Ia32Syscall ("munlockall", 153, 0, "i: "), >> + new Ia32Syscall ("sched_setp", 154, 2, "i:ip "), >> + new Ia32Syscall ("sched_getp", 155, 2, "i:ip "), >> + new Ia32Syscall ("sched_sets", 156, 3, "i:iip "), >> + new Ia32Syscall ("sched_gets", 157, 1, "i:i "), >> + new Ia32Syscall ("sched_yield", 158, 0, "i: "), >> + new Ia32Syscall ("sched_primax", 159, 1, "i:i "), >> + new Ia32Syscall ("sched_primin", 160, 1, "i:i "), >> + new Ia32Syscall ("sched_rr_gi", 161, 2, "i:ip "), >> + new Ia32Syscall ("nanosleep", 162, 2, "i:pp "), >> + new Ia32Syscall ("mremap", 163, 4, "b:aini "), >> + new Ia32Syscall ("setresuid", 164, 3, "i:iii "), >> + new Ia32Syscall ("getresuid", 165, 3, "i:ppp "), >> + new Ia32Syscall ("vm86", 166, 1, "i:p "), >> + new Ia32Syscall ("query_module", 167, 5, "i:sipip "), >> + new Ia32Syscall ("poll", 168, 3, "i:pii "), >> + new Ia32Syscall ("nfsservctl", 169, 3, "i:ipp "), >> + new Ia32Syscall ("setresgid", 170, 3, "i:iii "), >> + new Ia32Syscall ("getresgid", 171, 3, "i:ppp "), >> + new Ia32Syscall ("prctl", 172, 5, "i:iiiii "), >> + new Ia32Syscall ("rt_sigreturn", 173), >> + new Ia32Syscall ("rt_sigaction", 174), >> + new Ia32Syscall ("rt_sigprocmask", 175), >> + new Ia32Syscall ("rt_sigpending", 176), >> + new Ia32Syscall ("rt_sigtimedwait", 177), >> + new Ia32Syscall ("rt_sigqueueinfo", 178), >> + new Ia32Syscall ("rt_sigsuspend", 179), >> + new Ia32Syscall ("pread64", 180), >> + new Ia32Syscall ("pwrite64", 181), >> + new Ia32Syscall ("chown", 182, 3, "i:sii "), >> + new Ia32Syscall ("getcwd", 183, 2, "i:bi "), >> + new Ia32Syscall ("capget", 184, 2, "i:pp "), >> + new Ia32Syscall ("capset", 185, 2, "i:pp "), >> + new Ia32Syscall ("sigaltstack", 186, 2, "i:PP "), >> + new Ia32Syscall ("sendfile", 187, 4, "i:iipi "), >> + new Ia32Syscall ("getpmsg", 188), >> + new Ia32Syscall ("putpmsg", 189), >> + new Ia32Syscall ("vfork", 190, 0, "i: "), >> + new Ia32Syscall ("ugetrlimit", 191), >> + new Ia32Syscall ("mmap", 192, 6, "b:aniiii "), >> + new Ia32Syscall ("truncate64", 193, 3, "i:shl "), >> + new Ia32Syscall ("ftruncate64", 194, 3, "i:ihl "), >> + new Ia32Syscall ("stat64", 195, 2, "i:sp "), >> + new Ia32Syscall ("lstat64", 196, 2, "i:sp "), >> + new Ia32Syscall ("fstat64", 197, 2, "i:ip "), >> + new Ia32Syscall ("lchown32", 198, 3, "i:sii "), >> + new Ia32Syscall ("getuid32", 199), >> + new Ia32Syscall ("getgid32", 200), >> + new Ia32Syscall ("geteuid32", 201), >> + new Ia32Syscall ("getegid32", 202), >> + new Ia32Syscall ("setreuid32", 203, 2, "i:ii "), >> + new Ia32Syscall ("setregid32", 204, 2, "i:ii "), >> + new Ia32Syscall ("getgroups32", 205, 2, "i:ip "), >> + new Ia32Syscall ("setgroups32", 206, 2, "i:ip "), >> + new Ia32Syscall ("fchown32", 207, 3, "i:iii "), >> + new Ia32Syscall ("setresuid32", 208, 3, "i:iii "), >> + new Ia32Syscall ("getresuid32", 209, 3, "i:ppp "), >> + new Ia32Syscall ("setresgid32", 210, 3, "i:iii "), >> + new Ia32Syscall ("getresgid32", 211, 3, "i:ppp "), >> + new Ia32Syscall ("chown32", 212, 3, "i:sii "), >> + new Ia32Syscall ("setuid32", 213, 1, "i:i "), >> + new Ia32Syscall ("setgid32", 214, 1, "i:i "), >> + new Ia32Syscall ("setfsuid32", 215, 1, "i:i "), >> + new Ia32Syscall ("setfsgid32", 216, 1, "i:i "), >> + new Ia32Syscall ("pivot_root", 217, 2, "i:ss "), >> + new Ia32Syscall ("mincore", 218, 3, "i:anV "), >> + new Ia32Syscall ("madvise", 219, 3, "i:pii "), >> + new Ia32Syscall ("getdents64", 220, 3, "i:ipi "), >> + new Ia32Syscall ("fcntl64", 221, 3, "i:iip "), >> + new Ia32Syscall (222), >> + new Ia32Syscall (223), >> + new Ia32Syscall ("gettid", 224, 0), >> + new Ia32Syscall ("readahead", 225, 4, "i:ihli "), >> + new Ia32Syscall ("setxattr", 226), >> + new Ia32Syscall ("lsetxattr", 227), >> + new Ia32Syscall ("fsetxattr", 228), >> + new Ia32Syscall ("getxattr", 229), >> + new Ia32Syscall ("lgetxattr", 230), >> + new Ia32Syscall ("fgetxattr", 231), >> + new Ia32Syscall ("listxattr", 232), >> + new Ia32Syscall ("llistxattr", 233), >> + new Ia32Syscall ("flistxattr", 234), >> + new Ia32Syscall ("removexattr", 235), >> + new Ia32Syscall ("lremovexattr", 236), >> + new Ia32Syscall ("fremovexattr", 237), >> + new Ia32Syscall ("tkill", 238, 2, "i:ii "), >> + new Ia32Syscall ("sendfile64", 239, 4, "i:iipi "), >> + new Ia32Syscall ("futex", 240, 4, "i:piip "), >> + new Ia32Syscall ("sched_setaffinity", 241), >> + new Ia32Syscall ("sched_getaffinity", 242), >> + new Ia32Syscall ("set_thread_area", 243, 1, "i:p "), >> + new Ia32Syscall ("get_thread_area", 244, 1, "i:p "), >> + new Ia32Syscall ("io_setup", 245, 2, "i:ip "), >> + new Ia32Syscall ("io_destroy", 246, 1, "i:i "), >> + new Ia32Syscall ("io_getevents", 247, 5, "i:iiipp "), >> + new Ia32Syscall ("io_submit", 248, 3, "i:iip "), >> + new Ia32Syscall ("io_cancel", 249, 3, "i:ipp "), >> + new Ia32Syscall ("fadvise64", 250), >> + new Ia32Syscall (251), >> + new Ia32Syscall ("exit_group", 252, 1, " :i ", true), >> + new Ia32Syscall ("lookup_dcookie", 253), >> + new Ia32Syscall ("epoll_create", 254), >> + new Ia32Syscall ("epoll_ctl", 255), >> + new Ia32Syscall ("epoll_wait", 256), >> + new Ia32Syscall ("remap_file_pages", 257), >> + new Ia32Syscall ("set_tid_address", 258), >> + new Ia32Syscall ("timer_create", 259), >> + new Ia32Syscall ("timer_settime", 260), >> + new Ia32Syscall ("timer_gettime", 261), >> + new Ia32Syscall ("timer_getoverrun", 262), >> + new Ia32Syscall ("timer_delete", 263), >> + new Ia32Syscall ("clock_settime", 264), >> + new Ia32Syscall ("clock_gettime", 265), >> + new Ia32Syscall ("clock_getres", 266), >> + new Ia32Syscall ("clock_nanosleep", 267), >> + new Ia32Syscall ("statfs64", 268), >> + new Ia32Syscall ("fstatfs64", 269), >> + new Ia32Syscall ("tgkill", 270), >> + new Ia32Syscall ("utimes", 271), >> + new Ia32Syscall ("fadvise64_64", 272) >> + }; >> + >> + >> + static class SocketSubSyscall >> + extends Ia32Syscall >> + { >> + SocketSubSyscall (String name, int number) >> + { >> + super (name, number); >> + } >> + SocketSubSyscall (String name, int number, int numArgs, String >> argList) >> + { >> + super (name, number, numArgs, argList); >> + } >> + >> + public long getArguments (Task task, int n) >> + { >> + /** Arguments in socket subcalls are dereferenced. */ >> + Isa isa; >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (Exception e) >> + { >> + throw new RuntimeException ("Could not get isa"); >> + } >> + long base = isa.getRegisterByName("ecx").get (task); >> + >> + //System.out.println(Long.toHexString(base) + " " + n); >> + return task.memory.getInt(base + (n-1) * isa.getWordSize()); >> + } >> + } >> + >> + static Syscall[] socketSubcallList = { >> + new SocketSubSyscall ("", SOCKET_NUM), >> + new SocketSubSyscall ("socket", SOCKET_NUM, 3, "i:iii"), >> + new SocketSubSyscall ("bind", SOCKET_NUM, 3, "i:ipi "), >> + new SocketSubSyscall ("connect", SOCKET_NUM, 3, "i:ipi "), >> + new SocketSubSyscall ("listen", SOCKET_NUM, 2, "i:ii "), >> + new SocketSubSyscall ("accept", SOCKET_NUM, 3, "i:ipp "), >> + new SocketSubSyscall ("getsockname",SOCKET_NUM, 3, "i:ipp "), >> + new SocketSubSyscall ("getpeername",SOCKET_NUM, 4, "i:iiip "), >> + new SocketSubSyscall ("socketpair", SOCKET_NUM, 4, "i:iiip "), >> + new SocketSubSyscall ("send", SOCKET_NUM, 4, "i:ipii "), >> + new SocketSubSyscall ("recv", SOCKET_NUM, 4, "i:ipii "), >> + new SocketSubSyscall ("sendto", SOCKET_NUM, 6, "i:ipiipi"), >> + new SocketSubSyscall ("recvfrom", SOCKET_NUM, 6, "i:ipiipp "), >> + new SocketSubSyscall ("shutdown", SOCKET_NUM, 2, "i:ii "), >> + new SocketSubSyscall ("setsockopt", SOCKET_NUM, 5, "i:iiipp "), >> + new SocketSubSyscall ("getsockopt", SOCKET_NUM, 5, "i:iiipp "), >> + new SocketSubSyscall ("sendmsg", SOCKET_NUM, 5, "i:iiipp "), >> + new SocketSubSyscall ("recvmsg", SOCKET_NUM, 5, "i:iiipp ") >> + }; >> + >> + >> + static class IpcSubSyscall >> + extends Ia32Syscall >> + { >> + IpcSubSyscall (String name, int number) >> + { >> + super (name, number); >> + } >> + IpcSubSyscall (String name, int number, int numArgs, String argList) >> + { >> + super (name, number, numArgs, argList); >> + } >> + public long getArguments (Task task, int n) >> + { >> + if (n == 0) >> + return super.getArguments (task, 0); >> + else >> + // these arguements are shifted by one. >> + return super.getArguments (task, n+1); >> + } >> + + } >> + /**FIXME: No argument list here.*/ >> + static Syscall[] ipcSubcallList = { >> + new IpcSubSyscall ("semop", IPC_NUM), >> + new IpcSubSyscall ("semget", IPC_NUM), >> + new IpcSubSyscall ("semctl", IPC_NUM), >> + new IpcSubSyscall ("semtimedop", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("msgsnd", IPC_NUM), >> + new IpcSubSyscall ("msgrcv", IPC_NUM), >> + new IpcSubSyscall ("msgget", IPC_NUM), >> + new IpcSubSyscall ("msgctl", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("", IPC_NUM), >> + new IpcSubSyscall ("shmat", IPC_NUM), >> + new IpcSubSyscall ("shmdt", IPC_NUM), >> + new IpcSubSyscall ("shmget", IPC_NUM), >> + new IpcSubSyscall ("shmctl", IPC_NUM) >> + }; >> + >> + public static Syscall syscallByNum (Task task, int number) >> + { >> + if (number != SOCKET_NUM && number != IPC_NUM) >> + return Syscall.syscallByNum (number, task); >> + else >> + { >> + /** sub syscall number is in %ebx. */ >> + int subSyscallNumber = 0; >> + try >> + { >> + subSyscallNumber = (int) >> task.getIsa().getRegisterByName("ebx").get (task); >> + } >> + catch (Exception e) >> + { >> + throw new RuntimeException ("Could not get isa"); >> + } >> + >> + if (number == SOCKET_NUM) >> + { >> + return socketSubcallList[subSyscallNumber]; >> + } >> + else >> + { >> + return ipcSubcallList[subSyscallNumber]; >> + } >> + } >> + } >> +} >> --- /dev/null 2006-09-01 16:42:34.468363500 +0800 >> +++ frysk-core/frysk/proc/LinuxEMT64Syscall.java 2006-09-13 >> 17:29:38.000000000 +0800 >> @@ -0,0 +1,383 @@ >> +// This file is part of the program FRYSK. >> +// >> +// Copyright 2005, 2006 Red Hat Inc. >> +// >> +// FRYSK is free software; you can redistribute it and/or modify it >> +// under the terms of the GNU General Public License as published by >> +// the Free Software Foundation; version 2 of the License. >> +// >> +// FRYSK is distributed in the hope that it will be useful, but >> +// WITHOUT ANY WARRANTY; without even the implied warranty of >> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> +// General Public License for more details. >> +// +// You should have received a copy of the GNU General Public License >> +// along with FRYSK; if not, write to the Free Software Foundation, >> +// Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. >> +// +// In addition, as a special exception, Red Hat, Inc. gives You the >> +// additional right to link the code of FRYSK with code not covered >> +// under the GNU General Public License ("Non-GPL Code") and to >> +// distribute linked combinations including the two, subject to the >> +// limitations in this paragraph. Non-GPL Code permitted under this >> +// exception must only link to the code of FRYSK through those well >> +// defined interfaces identified in the file named EXCEPTION found in >> +// the source code files (the "Approved Interfaces"). The files of >> +// Non-GPL Code may instantiate templates or use macros or inline >> +// functions from the Approved Interfaces without causing the >> +// resulting work to be covered by the GNU General Public >> +// License. Only Red Hat, Inc. may make changes or additions to the >> +// list of Approved Interfaces. You must obey the GNU General Public >> +// License in all respects for all of the FRYSK code and other code >> +// used in conjunction with FRYSK except the Non-GPL Code covered by >> +// this exception. If you modify this file, you may extend this >> +// exception to your version of the file, but you are not obligated to >> +// do so. If you do not wish to provide this exception without >> +// modification, you must delete this exception statement from your >> +// version and license this file solely under the GPL without >> +// exception. >> + >> +package frysk.proc; >> + >> +import java.util.HashMap; >> + >> +public class LinuxEMT64Syscall >> +{ >> + >> + // This is used to keep track of syscalls whose number we do not >> + // know. >> + static HashMap unknownSyscalls; >> + >> + static class EMT64Syscall + extends Syscall >> + { >> + EMT64Syscall (String name, int number, int numArgs, + >> String argList, boolean noreturn) >> + { >> + super (name, number, numArgs, argList, noreturn); >> + } >> + EMT64Syscall (String name, int number, int numArgs, String argList) >> + { >> + super (name, number, numArgs, argList); >> + } + EMT64Syscall (String name, int number, int numArgs) >> + { >> + super (name, number, numArgs); >> + } >> + EMT64Syscall (String name, int number) >> + { >> + super (name, number); >> + } >> + EMT64Syscall (int number) >> + { >> + super (number); >> + } >> + public long getArguments (Task task, int n) >> + { >> + Isa isa; >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (Exception e) >> + { >> + throw new RuntimeException ("Could not get isa"); >> + } >> + >> + switch (n) { >> + case 0: >> + return isa.getRegisterByName ("orig_rax").get(task); >> + case 1: >> + return isa.getRegisterByName("rdi").get(task); >> + case 2: >> + return isa.getRegisterByName("rsi").get (task); >> + case 3: >> + return isa.getRegisterByName("rdx").get (task); >> + case 4: >> + return isa.getRegisterByName("r10").get (task); >> + case 5: >> + return isa.getRegisterByName("r8").get (task); >> + case 6: >> + return isa.getRegisterByName("r9").get (task); >> + default: >> + throw new RuntimeException ("unknown syscall arg"); >> + } >> + } >> + public long getReturnCode (Task task) >> + { >> + Isa isa; >> + try >> + { >> + isa = task.getIsa(); >> + } >> + catch (Exception e) >> + { >> + throw new RuntimeException ("Could not get isa"); >> + } >> + return isa.getRegisterByName ("rax").get (task); >> + } >> + } >> + static Syscall[] syscallList = { >> + new EMT64Syscall ("read", 0, 3, "i:ibn "), >> + new EMT64Syscall ("write", 1, 3, "i:ibn "), >> + new EMT64Syscall ("open", 2, 3, "i:siv "), >> + new EMT64Syscall ("close", 3, 1, "i:i "), >> + new EMT64Syscall ("stat", 4, 2, "i:sp "), >> + new EMT64Syscall ("fstat", 5, 2, "i:ip "), >> + new EMT64Syscall ("lstat", 6, 2, "i:sp "), >> + new EMT64Syscall ("poll", 7, 3, "i:pii "), >> + new EMT64Syscall ("lseek", 8, 3, "i:iii "), >> + new EMT64Syscall ("mmap", 9, 6, "b:aniiii "), >> + new EMT64Syscall ("mprotect", 10, 3, "i:aii "), >> + new EMT64Syscall ("munmap", 11, 2, "i:ai "), >> + new EMT64Syscall ("brk", 12, 1, "i:p "), >> + new EMT64Syscall ("rt_sigaction", 13), >> + new EMT64Syscall ("rt_sigprocmask", 14), >> + new EMT64Syscall ("rt_sigreturn", 15), >> + new EMT64Syscall ("ioctl", 16, 3, "i:iiI "), >> + new EMT64Syscall ("pread64", 17), >> + new EMT64Syscall ("pwrite64", 18), >> + new EMT64Syscall ("readv", 19, 3, "i:ipi "), >> + new EMT64Syscall ("writev", 20, 3, "i:ipi "), >> + new EMT64Syscall ("access", 21, 2, "i:si "), >> + new EMT64Syscall ("pipe", 22, 1, "i:f "), >> + new EMT64Syscall ("select", 23, 5, "i:iPPPP "), >> + new EMT64Syscall ("sched_yield", 24, 0, "i: "), >> + new EMT64Syscall ("mremap", 25, 4, "b:aini "), >> + new EMT64Syscall ("msync", 26, 3, "i:aii "), >> + new EMT64Syscall ("mincore", 27, 3, "i:anV "), >> + new EMT64Syscall ("madvise", 28, 3, "i:pii "), >> + new EMT64Syscall ("shmget", 29, 3, "i:iii "), >> + new EMT64Syscall ("shmat", 30, 3, "p:ipi "), >> + new EMT64Syscall ("shmctl", 31, 3, "i:iip "), >> + new EMT64Syscall ("dup", 32, 1, "i:i "), >> + new EMT64Syscall ("dup2", 33, 2, "i:ii "), >> + new EMT64Syscall ("pause", 34, 0, "i: "), >> + new EMT64Syscall ("nanosleep", 35, 2, "i:pp "), >> + new EMT64Syscall ("getitimer", 36, 2, "i:ip "), >> + new EMT64Syscall ("alarm", 37, 1, "i:i "), >> + new EMT64Syscall ("setitimer", 38, 3, "i:ipp "), >> + new EMT64Syscall ("getpid", 39, 0, "i: "), >> + new EMT64Syscall ("sendfile", 40, 4, "i:iipi "), >> + new EMT64Syscall ("socket", 41, 3, "i:iii "), >> + new EMT64Syscall ("connect", 42), >> + new EMT64Syscall ("accept", 43), >> + new EMT64Syscall ("sendto", 44), >> + new EMT64Syscall ("recvfrom", 45), >> + new EMT64Syscall ("sendmsg", 46), >> + new EMT64Syscall ("recvmsg", 47), >> + new EMT64Syscall ("shutdown", 48), >> + new EMT64Syscall ("bind", 49, 3, "i:ipi "), >> + new EMT64Syscall ("listen", 50, 2, "i:ii "), >> + new EMT64Syscall ("getsockname", 51, 3, "i:ipp "), >> + new EMT64Syscall ("getpeername", 52, 4, "i:iiip "), >> + new EMT64Syscall ("socketpair", 53, 4, "i:iiip "), >> + new EMT64Syscall ("setsockopt", 54, 5, "i:iiipp "), >> + new EMT64Syscall ("getsockopt", 55, 5, "i:iiipp "), >> + new EMT64Syscall ("clone", 56, 2, "i:ip "), >> + new EMT64Syscall (58), >> + new EMT64Syscall ("fork", 57, 0, "i: "), >> + new EMT64Syscall ("execve", 59, 3, "i:ppp "), >> + new EMT64Syscall ("exit", 60, 1), >> + new EMT64Syscall ("wait4", 61, 4, "i:iWiP "), >> + new EMT64Syscall ("kill", 62, 2, "i:ii "), >> + new EMT64Syscall ("uname", 63, 1, "i:p "), >> + new EMT64Syscall ("semget", 64), >> + new EMT64Syscall ("semop", 65), >> + new EMT64Syscall ("semctl", 66), >> + new EMT64Syscall ("shmdt", 67), >> + new EMT64Syscall ("msgget", 68), >> + new EMT64Syscall ("msgsnd", 69), >> + new EMT64Syscall ("msgrcv", 70), >> + new EMT64Syscall ("msgctl", 71), >> + new EMT64Syscall ("fcntl", 72, 3, "i:iiF "), >> + new EMT64Syscall ("flock", 73, 2, "i:ii "), >> + new EMT64Syscall ("fsync", 74, 1, "i:i "), >> + new EMT64Syscall ("fdatasync", 75, 1, "i:i "), >> + new EMT64Syscall ("truncate", 76, 2, "i:si "), >> + new EMT64Syscall ("ftruncate", 77, 2, "i:ii "), >> + new EMT64Syscall ("getdents", 78), >> + new EMT64Syscall ("getcwd", 79, 2, "i:bi "), >> + new EMT64Syscall ("chdir", 80, 1, "i:s "), >> + new EMT64Syscall ("fchdir", 81, 1, "i:i "), >> + new EMT64Syscall ("rename", 82, 2, "i:ss "), >> + new EMT64Syscall ("mkdir", 83, 2, "i:si "), >> + new EMT64Syscall ("rmdir", 84, 1, "i:s "), >> + new EMT64Syscall ("creat", 85, 2, "i:sv"), >> + new EMT64Syscall ("link", 86, 2, "i:ss "), >> + new EMT64Syscall ("unlink", 87, 1, "i:s "), >> + new EMT64Syscall ("symlink", 88, 2, "i:ss "), >> + new EMT64Syscall ("readlink", 89, 3, "i:spi "), >> + new EMT64Syscall ("chmod", 90, 2, "i:si "), >> + new EMT64Syscall ("fchmod", 91, 2, "i:ii "), >> + new EMT64Syscall ("chown", 92, 3, "i:sii "), >> + new EMT64Syscall ("fchown", 93, 3, "i:iii "), >> + new EMT64Syscall ("lchown", 94, 3, "i:sii "), >> + new EMT64Syscall ("umask", 95, 1, "i:i "), >> + new EMT64Syscall ("gettimeofday", 96, 2, "i:PP "), >> + new EMT64Syscall ("getrlimit", 97, 2, "i:ip "), >> + new EMT64Syscall ("getrusage", 98, 2, "i:ip "), >> + new EMT64Syscall ("sysinfo", 99, 1, "i:p "), >> + new EMT64Syscall ("times", 100, 1, "i:p "), >> + new EMT64Syscall ("ptrace", 101, 4, "i:iiii "), >> + new EMT64Syscall ("getuid", 102, 0, "i: "), >> + new EMT64Syscall ("syslog", 103), >> + new EMT64Syscall ("getgid", 104, 0, "i: "), >> + new EMT64Syscall ("setuid", 105, 1, "i:i "), >> + new EMT64Syscall ("setgid", 106, 1, "i:i "), >> + new EMT64Syscall ("geteuid", 107, 0, "i: "), >> + new EMT64Syscall ("getegid", 108, 0, "i: "), >> + new EMT64Syscall ("setpgid", 109, 2, "i:ii "), >> + new EMT64Syscall ("getppid", 110, 0, "i: "), >> + new EMT64Syscall ("getpgrp", 111, 0, "i: "), >> + new EMT64Syscall ("setsid", 112, 0, "i: "), >> + new EMT64Syscall ("setreuid", 113, 2, "i:ii "), >> + new EMT64Syscall ("setregid", 114, 2, "i:ii "), >> + new EMT64Syscall ("getgroups", 115, 2, "i:ip "), >> + new EMT64Syscall ("setgroups", 116, 2, "i:ip "), >> + new EMT64Syscall ("setresuid", 117, 3, "i:iii "), >> + new EMT64Syscall ("getresuid", 118, 3, "i:ppp "), >> + new EMT64Syscall ("setresgid", 119, 3, "i:iii "), >> + new EMT64Syscall ("getresgid", 120, 3, "i:ppp "), >> + new EMT64Syscall ("getpgid", 121, 1, "i:i "), >> + new EMT64Syscall ("setfsuid", 122, 1, "i:i "), >> + new EMT64Syscall ("setfsgid", 123, 1, "i:i "), >> + new EMT64Syscall ("getsid", 124, 1, "i:i "), >> + new EMT64Syscall ("capget", 125, 2, "i:pp "), >> + new EMT64Syscall ("capset", 126, 2, "i:pp "), >> + new EMT64Syscall ("rt_sigpending", 127, 2, "i:pi "), >> + new EMT64Syscall ("rt_sigtimedwait", 128, 4, "i:pppi " ), >> + new EMT64Syscall ("rt_sigqueueinfo", 129 ), >> + new EMT64Syscall ("rt_sigsuspend", 130 ), >> + new EMT64Syscall ("sigaltstack", 131, 2, "i:PP "), >> + new EMT64Syscall ("utime", 132, 2, "i:sP "), >> + new EMT64Syscall ("mknod", 133, 3, "i:sii "), >> + new EMT64Syscall ("uselib", 134, 1, "i:s "), >> + new EMT64Syscall ("personality", 135, 1, "i:i "), >> + new EMT64Syscall ("ustat", 136, 2, "i:ip "), >> + new EMT64Syscall ("statfs", 137, 2, "i:sp "), >> + new EMT64Syscall ("fstatfs", 138, 2, "i:ip "), >> + new EMT64Syscall ("sysfs", 139, 1, "i:i "), >> + new EMT64Syscall ("getpriority", 140, 2, "i:ii "), >> + new EMT64Syscall ("setpriority", 141, 3, "i:iii "), >> + new EMT64Syscall ("sched_setparam", 142), >> + new EMT64Syscall ("sched_getparam", 143), >> + new EMT64Syscall ("sched_setscheduler", 144), >> + new EMT64Syscall ("sched_getscheduler", 145), >> + new EMT64Syscall ("sched_get_priority_max", 146), >> + new EMT64Syscall ("sched_get_priority_min", 147), >> + new EMT64Syscall ("sched_rr_get_interval", 148), >> + new EMT64Syscall ("mlock", 149, 2, "i:bn "), >> + new EMT64Syscall ("munlock", 150, 2, "i:ai "), >> + new EMT64Syscall ("mlockall", 151, 1, "i:i "), >> + new EMT64Syscall ("munlockall", 152, 0, "i: "), >> + new EMT64Syscall ("vhangup", 153, 1, "i:i "), >> + new EMT64Syscall ("modify_ldt", 154, 3, "i:ipi "), >> + new EMT64Syscall ("pivot_root", 155, 2, "i:ss "), >> + new EMT64Syscall ("_sysctl", 156), >> + new EMT64Syscall ("prctl", 157, 5, "i:iiiii "), >> + new EMT64Syscall ("arch_prctl", 158), >> + new EMT64Syscall ("adjtimex", 159, 1, "i:p "), >> + new EMT64Syscall ("setrlimit", 160, 2, "i:ip "), >> + new EMT64Syscall ("chroot", 161, 1, "i:s "), >> + new EMT64Syscall ("sync", 162, 0, "i: "), >> + new EMT64Syscall ("acct", 163, 1, "i:S "), >> + new EMT64Syscall ("settimeofday", 164, 2, "i:PP "), >> + new EMT64Syscall ("mount", 165, 5, "i:sssip "), >> + new EMT64Syscall ("umount2", 166, 2, "i:si "), >> + new EMT64Syscall ("swapon", 167, 2, "i:si "), >> + new EMT64Syscall ("swapoff", 168, 1, "i:s "), >> + new EMT64Syscall ("reboot", 169, 1, "i:i "), >> + new EMT64Syscall ("sethostname", 170, 2, "i:pi "), >> + new EMT64Syscall ("setdomainname", 171), >> + new EMT64Syscall ("iopl", 172, 1, "i:i "), >> + new EMT64Syscall ("ioperm", 173, 3, "i:iii "), >> + new EMT64Syscall ("create_module", 174, 3), >> + new EMT64Syscall ("init_module", 175, 5), >> + new EMT64Syscall ("delete_module", 176, 3), >> + new EMT64Syscall ("get_kernel_syms", 177, 1, "i:p "), >> + new EMT64Syscall ("query_module", 178, 5, "i:sipip "), >> + new EMT64Syscall ("quotactl", 179, 4, "i:isip "), >> + new EMT64Syscall ("nfsservctl", 180, 3, "i:ipp "), >> + new EMT64Syscall ("getpmsg", 181), >> + new EMT64Syscall ("putpmsg", 182), >> + new EMT64Syscall ("afs_syscall", 183), >> + new EMT64Syscall ("tuxcall", 184), >> + new EMT64Syscall ("security", 185), >> + new EMT64Syscall ("gettid", 186, 0), >> + new EMT64Syscall ("readahead", 187, 4, "i:ihli "), >> + new EMT64Syscall ("setxattr", 188), >> + new EMT64Syscall ("lsetxattr", 189 ), >> + new EMT64Syscall ("fsetxattr", 190 ), >> + new EMT64Syscall ("getxattr", 191 ), >> + new EMT64Syscall ("lgetxattr", 192 ), >> + new EMT64Syscall ("fgetxattr", 193 ), >> + new EMT64Syscall ("listxattr", 194 ), >> + new EMT64Syscall ("llistxattr", 195 ), >> + new EMT64Syscall ("flistxattr", 196 ), >> + new EMT64Syscall ("removexattr", 197 ), >> + new EMT64Syscall ("lremovexattr", 198 ), >> + new EMT64Syscall ("fremovexattr", 199 ), >> + new EMT64Syscall ("tkill", 200, 2, "i:ii "), >> + new EMT64Syscall ("time", 201, 1, "i:P "), >> + new EMT64Syscall ("futex", 202, 4, "i:piip "), >> + new EMT64Syscall ("sched_setaffinity", 203 ), >> + new EMT64Syscall ("sched_getaffinity", 204 ), >> + new EMT64Syscall ("set_thread_area", 205, 1, "i:p "), >> + new EMT64Syscall ("io_setup", 206, 2, "i:ip "), >> + new EMT64Syscall ("io_destroy", 207, 1, "i:i "), >> + new EMT64Syscall ("io_getevents", 208, 5, "i:iiipp "), >> + new EMT64Syscall ("io_submit", 209, 3, "i:iip "), >> + new EMT64Syscall ("io_cancel", 210, 3, "i:ipp "), >> + new EMT64Syscall ("get_thread_area", 211, 1, "i:p "), >> + new EMT64Syscall ("lookup_dcookie", 212), >> + new EMT64Syscall ("epoll_create", 213), >> + new EMT64Syscall ("epoll_ctl_old", 214), >> + new EMT64Syscall ("epoll_wait_old", 215), >> + new EMT64Syscall ("remap_file_pages", 216), >> + new EMT64Syscall ("getdents64", 217, 3, "i:ipi "), >> + new EMT64Syscall ("set_tid_address", 218), >> + new EMT64Syscall ("restart_syscall", 219), >> + new EMT64Syscall ("semtimedop", 220), >> + new EMT64Syscall ("fadvise64", 221), >> + new EMT64Syscall ("timer_create", 222), >> + new EMT64Syscall ("timer_settime", 223), >> + new EMT64Syscall (224), >> + new EMT64Syscall (225), >> + new EMT64Syscall ("timer_delete", 226), >> + new EMT64Syscall ("clock_settime", 227), >> + new EMT64Syscall ("clock_gettime", 228), >> + new EMT64Syscall ("clock_getres", 229), >> + new EMT64Syscall ("clock_nanosleep", 230), >> + new EMT64Syscall ("exit_group", 231, 1, " :i "), >> + new EMT64Syscall ("epoll_wait", 232), >> + new EMT64Syscall ("epoll_ctl", 233), >> + new EMT64Syscall ("tgkill", 234), >> + new EMT64Syscall ("utimes", 235), >> + new EMT64Syscall ("vserver", 236), >> + new EMT64Syscall ("mbind", 237), >> + new EMT64Syscall ("set_mempolicy", 238), >> + new EMT64Syscall ("get_mempolicy", 239), >> + new EMT64Syscall ("mq_open", 240), >> + new EMT64Syscall ("mq_unlink", 241), >> + new EMT64Syscall ("mq_timedsend", 242), >> + new EMT64Syscall ("mq_timedreceive", 243), >> + new EMT64Syscall ("mq_notify", 244), >> + new EMT64Syscall ("mq_getsetattr", 245), >> + new EMT64Syscall ("kexec_load", 246), >> + new EMT64Syscall ("waitid", 247), >> + new EMT64Syscall ("add_key", 248), >> + new EMT64Syscall ("request_key", 249), >> + new EMT64Syscall ("keyctl", 250), >> + new EMT64Syscall ("ioprio_set", 251), >> + new EMT64Syscall ("ioprio_get", 252), >> + new EMT64Syscall ("inotify_init", 253), >> + new EMT64Syscall ("inotify_add_watch", 254), >> + new EMT64Syscall ("inotify_rm_watch", 255) >> + }; >> + >> + public static Syscall syscallByNum (Task task, int number) >> + { >> + return Syscall.syscallByNum (number, task); >> + } >> +} >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFCFBueDhWHdXrDRURAlkRAJkBfKyPKsszRqjemBisOJIS86bPggCg2O+H 33ebrYmOKELiAfEyF7EGZVE= =Yctf -----END PGP SIGNATURE----- From cmoller@redhat.com Wed Sep 13 21:59:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Wed, 13 Sep 2006 21:59:00 -0000 Subject: fc6 frysk-core failures. In-Reply-To: <45083D27.1020108@redhat.com> References: <45077A9C.1000604@redhat.com> <45083D27.1020108@redhat.com> Message-ID: <45087F33.3000401@redhat.com> Andrew, The reason the test hangs is because the various Signal.kill (pid, Sig.KILL); Signal.kill (pid, Sig.CONT); and Ptrace.detach (pid, Sig.KILL); aren't actually managing to kill, detach, or otherwise make all the processes go away. I wired up the following "while (!children.isEmpty()) {}" code to see what's actually happening in the waitAll() and all it's getting is "stopped()"--disappeared() never happens. Since disappeared() never happens, children.remove(new Integer(pid)); never happens so (!children.isEmpty()) never goes false so after everything there is to wait for has happened a final waitAll() never returns. I've got a queue of kids outside my office demanding dinner, so I'll poke at this some more later. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From qiyaoltc@cn.ibm.com Thu Sep 14 07:16:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 14 Sep 2006 07:16:00 -0000 Subject: [patch] System call for multi-architecture In-Reply-To: <4508506E.1090509@redhat.com> References: <20060913131050.GC17676@GreenHouse.cn.ibm.com> <450845B2.3010704@redhat.com> <4508506E.1090509@redhat.com> Message-ID: <20060914071544.GE17676@GreenHouse.cn.ibm.com> On Wed, Sep 13, 2006 at 08:39:42PM +0200, Tim Moore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Cagney wrote: > > Yao, this is good, and a great jump forward. Thanks! > > One political nit, can you use the name x86_64, instead of em64t or > > emt64 or amd64 for the 64-bit ISA that is an extension of ia32? > > Andrew > > > I'll do the syscall list for 32bit IA32 on x86_64. I can also take on > changing emt64 to something more palatable, given that I made the > unfortunate choice in the first place :) Hi, Tim, I start to consider something about 32bit on 64bit platforms. Could you explain "do the syscall list for 32bit IA32 on x86_64"? Do you mean set up a *new* syscall list for 32bit IA32 on x86_64? ppc32 has the same syscall list as ppc64, so I add LinuxPowerPCSysca.java for both, and it is easier to do bi-arch on PowerPC w.r.t Syscall. As this patch has been checked in, the syscallList(target specific) could be returned via isa type of that task, when a 32-bit(ia32) program running on x86_64, syscallList for Ia32 could be indexed by its syscall number. > > Tim > -- Yao Qi From cmoller@redhat.com Thu Sep 14 07:45:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 14 Sep 2006 07:45:00 -0000 Subject: fc6 frysk-core failures. In-Reply-To: <45083D27.1020108@redhat.com> References: <45077A9C.1000604@redhat.com> <45083D27.1020108@redhat.com> Message-ID: <45090875.7040007@redhat.com> [Sorry you keep getting multiple copies of my notes--I keep forgetting to send them as text-only rather than text/html and frysk@ bounces them.] Andrew, Did a bit more tinkering in TestLib.java:tearDown() (see the attached Java) that looks like it conforms a bit better to how the new ptrace works, but it still doesn't work properly. In the final drain loop, neither disappeared() nor terminated() ever get called, so the loop never terminates--the best the preceding kill 'em all loop can do is get all the processes into a "stopped" state. (See the log tail in the attached p2.txt.) The Ptrace.cont (pid, 0); in the kill loop is an attempt to force stopped processes to continue, but I don't thing it's happening. (Passing a sig of zero to the new ptrace, BTW, effectively bypasses the signal injection step and goes straight to whatever ptrace request you're doing. If you pass a non-zero sig, and the signal injection fails, the ptrace req never happens. I'm not sure if this is a bug or a feature.) A question just occurred to me: I think, in this test, all of the various pids shown in the log are threads rather than forks. (Is that right?) If so, /do/ pthreads terminate? Or do they just hang around waiting to be joined or exited? At the end of the test, ps -el shows: 0 S 500 2537 29592 2 78 0 - 15029 wait pts/8 00:00:00 TestRunner 0 T 500 2540 2537 0 81 0 - 8131 utrace ? 00:00:00 funit-child And so, to bed, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: TestLib-teardown.java Type: text/x-java Size: 7514 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p2.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From qiyaoltc@cn.ibm.com Thu Sep 14 08:14:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 14 Sep 2006 08:14:00 -0000 Subject: Test result of cvs head (09/14)on rawhide ppc64 [frysk-core] Message-ID: <20060914081410.GF17676@GreenHouse.cn.ibm.com> Update rawhide to the latest kernel and gcj. [qiyao@localhost ~/build-frysk/frysk-core]$ uname -a Linux localhost.localdomain 2.6.17-1.2630.fc6 #1 SMP Wed Sep 6 17:17:26 EDT 2006 ppc64 ppc64 ppc64 GNU/Linux [qiyao@localhost ~/build-frysk/frysk-core]$ gcj -v Using built-in specs. Reading specs from /usr/lib/gcc/ppc64-redhat-linux/4.1.1/libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-secureplt --with-long-double-128 --host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.1.1 20060828 (Red Hat 4.1.1-20) Here is the test result, There were 2 errors: 1) testSyscallInterrupt(frysk.proc.TestTaskSyscallObserver)java.lang.RuntimeException: Read exit before enter at frysk.proc.TestTaskSyscallObserver$TestSyscallInterruptInternals$SyscallInterruptObserver.updateSyscallExit(TestRunner) at frysk.proc.Task.notifySyscallExit(TestRunner) at frysk.proc.TaskState$Running.handleSyscalledEvent(TestRunner) at frysk.proc.Task.processSyscalledEvent(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld$2.syscallEvent(TestRunner) at frysk.sys.Wait.waitAllNoHang(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld.execute(TestRunner) at frysk.event.EventLoop.runEventLoop(TestRunner) at frysk.event.EventLoop.runPolling(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestTaskSyscallObserver.testSyscallInterrupt(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 2) testSyscallInterruptRestart(frysk.proc.TestTaskSyscallObserver)java.lang.RuntimeException: Read exit before enter at frysk.proc.TestTaskSyscallObserver$TestSyscallInterruptInternals$SyscallInterruptObserver.updateSyscallExit(TestRunner) at frysk.proc.Task.notifySyscallExit(TestRunner) at frysk.proc.TaskState$Running.handleSyscalledEvent(TestRunner) at frysk.proc.Task.processSyscalledEvent(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld$2.syscallEvent(TestRunner) at frysk.sys.Wait.waitAllNoHang(TestRunner) at frysk.proc.LinuxHost$PollWaitOnSigChld.execute(TestRunner) at frysk.event.EventLoop.runEventLoop(TestRunner) at frysk.event.EventLoop.runPolling(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestTaskSyscallObserver.testSyscallInterruptRestart(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) There were 9 failures: 1) testAttachedMultipleParentExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib$AckHandler.assertAwait(TestRunner) at frysk.proc.TestLib$AckHandler.await(TestRunner) at frysk.proc.TestLib$AckProcess.spawn(TestRunner) at frysk.proc.TestLib$AckProcess.assertSendAddCloneWaitForAcks(TestRunner) at frysk.proc.TestExec.testAttachedMultipleParentExec(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 2) testAttachedMultipleChildExec(frysk.proc.TestExec)junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib$AckHandler.assertAwait(TestRunner) at frysk.proc.TestLib$AckHandler.await(TestRunner) at frysk.proc.TestLib$AckProcess.spawn(TestRunner) at frysk.proc.TestLib$AckProcess.assertSendAddCloneWaitForAcks(TestRunner) at frysk.proc.TestExec.testAttachedMultipleChildExec(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 3) testRefreshZombie(frysk.proc.TestRefresh)junit.framework.AssertionFailedError: Zombie child task count expected:<0> but was:<1> at frysk.proc.TestRefresh.testRefreshZombie(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 4) testIt(frysk.proc.TestSyscallSignal)junit.framework.AssertionFailedError: expected:<84> but was:<85> at frysk.proc.TestSyscallSignal.testIt(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 5) testTaskCloneObserver(frysk.proc.TestTaskClonedObserver)junit.framework.AssertionFailedError: number of clones expected:<176> but was:<0> at frysk.proc.TestTaskClonedObserver.testTaskCloneObserver(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 6) testCloneSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: event loop run explictly stopped (assertSendAddCloneWaitForAcks (Sig_USR1,Sig_USR2)) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib$AckHandler.assertAwait(TestRunner) at frysk.proc.TestLib$AckHandler.await(TestRunner) at frysk.proc.TestLib$AckProcess.spawn(TestRunner) at frysk.proc.TestLib$AckProcess.assertSendAddCloneWaitForAcks(TestRunner) at frysk.proc.TestTaskSyscallObserver.testCloneSyscall(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 7) testTerminateExit47(frysk.proc.TestTaskTerminateObserver)junit.framework.AssertionFailedError: terminated value expected:<47> but was:<-47> at frysk.proc.TestTaskTerminateObserver.check(TestRunner) at frysk.proc.TestTaskTerminateObserver.terminate(TestRunner) at frysk.proc.TestTaskTerminateObserver.testTerminateExit47(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 8) testTerminatedExit47(frysk.proc.TestTaskTerminateObserver)junit.framework.AssertionFailedError: terminated value expected:<47> but was:<-47> at frysk.proc.TestTaskTerminateObserver.check(TestRunner) at frysk.proc.TestTaskTerminateObserver.terminated(TestRunner) at frysk.proc.TestTaskTerminateObserver.testTerminatedExit47(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 9) testTerm(frysk.proc.TestTaskTerminateObserver)junit.framework.AssertionFailedError: event loop run explictly stopped (startChild (Sig_HUP)) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib.assertRunUntilStop(TestRunner) at frysk.proc.TestLib$AckHandler.assertAwait(TestRunner) at frysk.proc.TestLib$AckHandler.await(TestRunner) at frysk.proc.TestLib$Child.(TestRunner) at frysk.proc.TestLib$AckProcess.(TestRunner) at frysk.proc.TestLib$DetachedAckProcess.(TestRunner) at frysk.proc.TestTaskTerminateObserver.testTerm(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 114, Failures: 9, Errors: 2 These two errors are within our expectation, and we could start to fix these two errors soon. -- Yao Qi From qiyaoltc@cn.ibm.com Thu Sep 14 08:16:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 14 Sep 2006 08:16:00 -0000 Subject: Test result of cvs head (09/14)on rawhide ppc64 [frysk-core] In-Reply-To: <20060914081410.GF17676@GreenHouse.cn.ibm.com> References: <20060914081410.GF17676@GreenHouse.cn.ibm.com> Message-ID: <20060914081636.GG17676@GreenHouse.cn.ibm.com> All test cases in frysk-imports, frysk-gui, and frysk-sys are PASS. -- Yao Qi From qiyaoltc@cn.ibm.com Thu Sep 14 08:22:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 14 Sep 2006 08:22:00 -0000 Subject: Test result of cvs head (09/14)on rawhide ppc64 [frysk-core] In-Reply-To: <20060914081410.GF17676@GreenHouse.cn.ibm.com> References: <20060914081410.GF17676@GreenHouse.cn.ibm.com> Message-ID: <20060914082201.GH17676@GreenHouse.cn.ibm.com> > FAILURES!!! > Tests run: 114, Failures: 9, Errors: 2 > Forget to mention that testTaskForkedObserver and testBlockingFibonacciFork hang the kernel completely, and only thing I could do is reboot, so I remove TestTaskClonedObserver.class and TestTaskObserverBlocked.class from frysk-core/frysk/core/JUnitTests.java in order to run all other cases. I filed a bug for this problem, http://sourceware.org/bugzilla/show_bug.cgi?id=3201 -- Yao Qi From aoliva@redhat.com Thu Sep 14 08:52:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Thu, 14 Sep 2006 08:52:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <1158155019.2031.109.camel@towel.toronto.redhat.com> (Mike Cvet's message of "Wed, 13 Sep 2006 09:43:39 -0400") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> <1158155019.2031.109.camel@towel.toronto.redhat.com> Message-ID: On Sep 13, 2006, Mike Cvet wrote: > On Wed, 2006-09-13 at 06:43 -0300, Alexandre Oliva wrote: >> It still fails to print line numbers for main and for kernel vdso >> syscalls and their callers, but other than that, it's much better than >> before. >> The patch is not quite ready for public consumption (still missing a >> ChangeLog, for one), but I thought I'd post it for people who'd like >> to use it as is. I've added ChangeLog entries and some comments, but couldn't get any further on debugging the (unrelated) problems mentioned above. I had other fires to put out tonight, unfortunately. Ok to install this patch, and get to fix the other problems that were already present before in a separate patch? > According to upstream, all the dyn_list_* stuff is to handle > dynamically-generated code only. So, probably shouldn't have an effect > on what we're doing currently anyway. I see. Thanks for the info, I'll leave that alone then. -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-proc-info.patch Type: text/x-patch Size: 26815 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Thu Sep 14 08:56:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Thu, 14 Sep 2006 08:56:00 -0000 Subject: is UNW_REMOTE_ONLY in-dispensable fro Frysk In-Reply-To: <45056609.7090007@redhat.com> (Andrew Cagney's message of "Mon, 11 Sep 2006 09:35:05 -0400") References: <4504E379.1010400@cn.ibm.com> <45056609.7090007@redhat.com> Message-ID: On Sep 11, 2006, Andrew Cagney wrote: > Wu Zhou wrote: >> UNW_REMOTE_ONLY is causing some trouble for us to work on ppc64 >> porting of libunwind. I am thinking over if it is in-dispensable >> for Frysk. > I don't think it is in-dispensable, however, it is correct on > principle - this code has no need to do native unwinding - and it lets > us avoid a number of ongoing issues where the native-unwind defined > symbols that clashed with libgcj. Actually, we absolutely must do away with it. A number of libunwind internal routines mmap or otherwise copy stuff from the target process and then decode it locally, for which it needs functional local_address_space callbacks. One might try to qualify that as a bug, but unless we're willing to fix that by rewriting a lot of code, we'll be better off simply removing this local hack. That's what the patch I just posted (in the thread remote dwarf info using libunwind) does, and this is the reason for the change, that I think I failed to explain there. > Perhaps something to discuss on the libunwind list? Probably not, given that it's a local change. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From cagney@redhat.com Thu Sep 14 14:31:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 14 Sep 2006 14:31:00 -0000 Subject: fc6 frysk-core failures. In-Reply-To: <45090875.7040007@redhat.com> References: <45077A9C.1000604@redhat.com> <45083D27.1020108@redhat.com> <45090875.7040007@redhat.com> Message-ID: <450967B4.80100@redhat.com> Chris Moller wrote: > [Sorry you keep getting multiple copies of my notes--I keep forgetting > to send them as text-only rather than text/html and frysk@ bounces them.] > > Andrew, > > Did a bit more tinkering in TestLib.java:tearDown() (see the attached > Java) that looks like it conforms a bit better to how the new ptrace > works, but it still doesn't work properly. In the final drain loop, > neither disappeared() nor terminated() ever get called, so the loop > never terminates--the best the preceding kill 'em all loop can do is get > all the processes into a "stopped" state. (See the log tail in the > attached p2.txt.) The Ptrace.cont (pid, 0); in the kill loop is an > attempt to force stopped processes to continue, but I don't thing it's > happening. (Passing a sig of zero to the new ptrace, BTW, effectively > bypasses the signal injection step and goes straight to whatever ptrace > request you're doing. If you pass a non-zero sig, and the signal > injection fails, the ptrace req never happens. I'm not sure if this is > a bug or a feature.) > > I'm wondering how the signal injection during ptrace continue can "fail". As you point out, two things are going on: - an external program is delivering signals to the process (the kill calls) - the controlling program is doing a continue-with-signal the latter should always work whether or not the former has occurred. If something goes wrong with the ptrace (for instance, a second signal arrives and has to be delivered) then the controlling program would be notified via a waitpid status, and not a ptrace error code. Can you create a bug in both bugzilla.redhat.com, and sourceware.org (cross referenced) and then see if a simple test case is possible. That can then be added to frysk-imports/tests/fryskNNNN Andrew > A question just occurred to me: I think, in this test, all of the > various pids shown in the log are threads rather than forks. (Is that > right?) If so, /do/ pthreads terminate? Or do they just hang around > waiting to be joined or exited? > Yes, they are threads, but it is using kill and not tkill and so is directing the signal at the process as a whole. From cagney@redhat.com Thu Sep 14 14:53:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 14 Sep 2006 14:53:00 -0000 Subject: is UNW_REMOTE_ONLY in-dispensable fro Frysk In-Reply-To: References: <4504E379.1010400@cn.ibm.com> <45056609.7090007@redhat.com> Message-ID: <45096CF3.1030302@redhat.com> Alexandre Oliva wrote: > On Sep 11, 2006, Andrew Cagney wrote: > > >> Wu Zhou wrote: >> >>> UNW_REMOTE_ONLY is causing some trouble for us to work on ppc64 >>> porting of libunwind. I am thinking over if it is in-dispensable >>> for Frysk. >>> >> I don't think it is in-dispensable, however, it is correct on >> principle - this code has no need to do native unwinding - and it lets >> us avoid a number of ongoing issues where the native-unwind defined >> symbols that clashed with libgcj. >> > > Alex, what I've said stands. If this isn't fixed, it isn't possible to do an unwind of a remote process. Those internal routines need to be fixed. Can the upstream list's attention be drawn to this? > Actually, we absolutely must do away with it. A number of libunwind > internal routines mmap or otherwise copy stuff from the target process > and then decode it locally, for which it needs functional > local_address_space callbacks. One might try to qualify that as a > bug, but unless we're willing to fix that by rewriting a lot of code, > we'll be better off simply removing this local hack. That's what the > patch I just posted (in the thread remote dwarf info using libunwind) > does, and this is the reason for the change, that I think I failed to > explain there. > > >> Perhaps something to discuss on the libunwind list? >> > > Probably not, given that it's a local change. > Since the long term objective is to carry no local patches for these libraries this stuff all needs to be discussed and pushed up-stream. Is there a technical reason for not doing this? Andrew From cmoller@redhat.com Thu Sep 14 15:05:00 2006 From: cmoller@redhat.com (Chris Moller) Date: Thu, 14 Sep 2006 15:05:00 -0000 Subject: fc6 frysk-core failures. In-Reply-To: <450967B4.80100@redhat.com> References: <45077A9C.1000604@redhat.com> <45083D27.1020108@redhat.com> <45090875.7040007@redhat.com> <450967B4.80100@redhat.com> Message-ID: <45096FC1.9090307@redhat.com> Okay, but I'll write the testcase first just to make sure the bug is simply reproducible--I've been burned too much lately by irreproducible bugs and it looks like Roland may be out for a while anyway with that broken wrist. Chris Andrew Cagney mumbled something on 09/14/2006 10:31 AM: > > Can you create a bug in both bugzilla.redhat.com, and sourceware.org > (cross referenced) and then see if a simple test case is possible. > That can then be added to frysk-imports/tests/fryskNNNN > > Andrew > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From aoliva@redhat.com Thu Sep 14 17:27:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Thu, 14 Sep 2006 17:27:00 -0000 Subject: is UNW_REMOTE_ONLY in-dispensable fro Frysk In-Reply-To: <45096CF3.1030302@redhat.com> (Andrew Cagney's message of "Thu, 14 Sep 2006 10:53:39 -0400") References: <4504E379.1010400@cn.ibm.com> <45056609.7090007@redhat.com> <45096CF3.1030302@redhat.com> Message-ID: On Sep 14, 2006, Andrew Cagney wrote: > Alexandre Oliva wrote: >> On Sep 11, 2006, Andrew Cagney wrote: >> >> >>> Wu Zhou wrote: >>> >>>> UNW_REMOTE_ONLY is causing some trouble for us to work on ppc64 >>>> porting of libunwind. I am thinking over if it is in-dispensable >>>> for Frysk. >>>> >>> I don't think it is in-dispensable, however, it is correct on >>> principle - this code has no need to do native unwinding - and it lets >>> us avoid a number of ongoing issues where the native-unwind defined >>> symbols that clashed with libgcj. > Alex, what I've said stands. If this isn't fixed, it isn't possible > to do an unwind of a remote process. > Those internal routines need to be fixed. Can the upstream list's > attention be drawn to this? No, I think I wasn't clear in my explanation, which led you to incorrect conclusions. I was not talking about the routines we tried to use before and failed because they were *not* meant to be used for remote unwinding. I'm talking about other routines used internally that extract unwind information from files or from copying data from the remote process to the local process, and then extract the info accessing the then-local memory. >> Actually, we absolutely must do away with it. A number of libunwind >> internal routines mmap or otherwise copy stuff from the target process >> and then decode it locally, for which it needs functional >> local_address_space callbacks. One might try to qualify that as a >> bug, but unless we're willing to fix that by rewriting a lot of code, >> we'll be better off simply removing this local hack. That's what the >> patch I just posted (in the thread remote dwarf info using libunwind) >> does, and this is the reason for the change, that I think I failed to >> explain there. >>> Perhaps something to discuss on the libunwind list? >> Probably not, given that it's a local change. > Since the long term objective is to carry no local patches for these > libraries this stuff all needs to be discussed and pushed up-stream. > Is there a technical reason for not doing this? No, quite the contrary. Reverting this local change fixes bugs and I don't see a reason for this change other than a misguided attempt to reduce code size of compilation time or some such. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From qiyaoltc@cn.ibm.com Fri Sep 15 00:31:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 15 Sep 2006 00:31:00 -0000 Subject: frysk-gui lib/opcodes/Disassembler.java lib/op ... In-Reply-To: <20060914203119.9912.qmail@sourceware.org> References: <20060914203119.9912.qmail@sourceware.org> Message-ID: <20060915003055.GA14319@GreenHouse.cn.ibm.com> On Thu, Sep 14, 2006 at 08:31:19PM -0000, mcvet@sourceware.org wrote: > > Log message: > frysk-imports/lib/opcodes: > 2006-09-14 Mike Cvet > > * Disassembler.java (appendCurrentInstruction): Changed from > setCurrentInstruction to prevent overwriting the given > instruction with the parameters. Now properly appends > parameters to instructions. > * cni/Disassembler.cxx (disassemble): Changed the > i386 and x86_64 instruction flavours to att. > (read_from_byte_buffer): Fixed up formatting. > (print_addr): Changed from an empty function to one that > updates the Disassembler object with the instruction > address parameter. > (save_instruction): Fixed up formatting. Hi, Mike, I think I submitted a patch to do similar thing, support ppc64 additionally, on Sep. 3rd, http://sources.redhat.com/ml/frysk/2006-q3/msg00371.html Maybe, I should declare loudly in maillist to avoid duplicate work, :) I could start to add ppc64 support on your code. -- Yao Qi From pmuldoon@redhat.com Fri Sep 15 01:31:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 15 Sep 2006 01:31:00 -0000 Subject: Core Exception Throwing and Handling Message-ID: <450A027C.8080109@redhat.com> I thought I'd start this conversation going. It's been an action item for awhile. Right now the core throws a lot of RuntimeExceptions. As all java programmers know, a method is not required to declare RuntimeExceptions or any of its sub-classes in a throws clause. This makes exception handing on the method caller optional. It also does not give a heads-up to the method caller that it can expect an exception. With libraries and programs the size of frysk, there are dozens of interfaces into the core. Also RuntimeExceptions are pretty generic. They usually have a message and a trace and not much else. Here is the problem: the clients of the core have been given an exception. How does that client handle and continue, or handle and quit in an orderly manner? Should all exceptions be explicitly declared so that they can be explicitly handled? Here is an example: If ftrace or the UI gets a negative syscall runtime exception should it quit? Like lots of other exceptions it's wrapped in a Runtime exception and thrown. How can it test if the syscall exception is harmless and can move on? How can it differentiate between say a double state transition, or and unhanded state to above? This probably leads in a little to the Checked Exceptions discussion that was happening a few weeks ago. Regards Phil From qiyaoltc@cn.ibm.com Fri Sep 15 02:54:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 15 Sep 2006 02:54:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <450A027C.8080109@redhat.com> References: <450A027C.8080109@redhat.com> Message-ID: <20060915025425.GB14319@GreenHouse.cn.ibm.com> On Thu, Sep 14, 2006 at 08:31:40PM -0500, Phil Muldoon wrote: > I thought I'd start this conversation going. It's been an action item > for awhile. > > Right now the core throws a lot of RuntimeExceptions. As all java > programmers know, a method is not required to declare RuntimeExceptions > or any of its sub-classes in a throws clause. This makes exception > handing on the method caller optional. It also does not give a heads-up > to the method caller that it can expect an exception. With libraries and > programs the size of frysk, there are dozens of interfaces into the > core. Also RuntimeExceptions are pretty generic. They usually have a > message and a trace and not much else. > > Here is the problem: the clients of the core have been given an > exception. How does that client handle and continue, or handle and quit > in an orderly manner? Should all exceptions be explicitly declared so > that they can be explicitly handled? > > Here is an example: > > If ftrace or the UI gets a negative syscall runtime exception should it > quit? Like lots of other exceptions it's wrapped in a Runtime exception > and thrown. we could set up a new class SyscallException to handle this, and replace RuntimeException with SyscallException. IMO, ftrace or the UI could *not* quit when they get negative syscall runtime exception, could skip this negative syscall, report or log something, and continue. B.T.W, If we cache the system call number in SyscallEvenInfo when enter this system call, and return the cache value when exit this system call, the negative system call number could be avoided. I will post something about this in details in @frysk. > > How can it test if the syscall exception is harmless and can move on? It is hard to say to what extent syscall exception is harmful, and there is no such a general rule to determine which syscall exception is bad, and which syscall exception is worse. However, in every specific place that could cause a syscall exception, we could choose different actions against these syscall exceptions, according to where it is now. > > How can it differentiate between say a double state transition, or and > unhanded state to above? > > This probably leads in a little to the Checked Exceptions discussion > that was happening a few weeks ago. It was discussed here, http://sources.redhat.com/ml/frysk/2006-q3/msg00090.html > > Regards > > > Phil > -- Yao Qi From pmuldoon@redhat.com Fri Sep 15 03:15:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 15 Sep 2006 03:15:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <450A027C.8080109@redhat.com> References: <450A027C.8080109@redhat.com> Message-ID: <450A1AC8.2020101@redhat.com> And here is my own reply. Phil Muldoon wrote: > I thought I'd start this conversation going. It's been an action item > for awhile. > > Right now the core throws a lot of RuntimeExceptions. As all java > programmers know, a method is not required to declare > RuntimeExceptions or any of its sub-classes in a throws clause. This > makes exception handing on the method caller optional. It also does > not give a heads-up to the method caller that it can expect an > exception. With libraries and programs the size of frysk, there are > dozens of interfaces into the core. Also RuntimeExceptions are pretty > generic. They usually have a message and a trace and not much else. These exceptions are unchecked. There are various arguments out there for checked and unchecked exceptions. I sit on the fence in this regard. It is true that only Java has ever implemented both checked and unchecked exceptions (through technically all exceptions in Java are checked, as Exception is checked) and subsequent languages after (Ruby/C#) have not. There is a lot to learn from that. However from a purely client point of view, the client still has to figure out: 1) Is the exception bad? Will data corruption possibly occur if I continue; 2) Ah oh well, could not get that information, but it is ok to move on. The buck stops with the client implementing the core. With small low-setup utilities like ftrace it might be ok just to print out the stack trace and quit. It took 20 second to set it up, and very little loss. With a large scale monitoring ui, that can be running for hours, watching many 100s of processes for many observable events, it has to be more robust. 16 hours into a monitoring session we would not want to quit because some lookup failed. This leads me to think of four scenarios: 1) Do what we do now. Show the exception in a window, and ask if the user wants to continue or quit 2) Log the exception and continue 3) Have a high exception throwing threshold. Only "bad" exceptions are thrown. 4) Quit the UI, print the stacktrace, wait for bugzillas From the examples above: 1) Puts the position on the user. And expects the user to know what to do when the programmers didn't. It also brings the event loop to a halt while the user decides. 2) Would be okay if errors were recoverable. Some are .. and some send the core off into the weeds. From that point on it is somewhat braindead 3) Seems a cop-out. Might work if there was intelligence in the core to "thrown an exception" or return null (function failed). 4) Angry (quite rightfully) users. It's tempting to think of this as a core issue or a ui issue, but it is really much more complex than that. Regards Phil From pmuldoon@redhat.com Fri Sep 15 03:17:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 15 Sep 2006 03:17:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <20060915025425.GB14319@GreenHouse.cn.ibm.com> References: <450A027C.8080109@redhat.com> <20060915025425.GB14319@GreenHouse.cn.ibm.com> Message-ID: <450A1B5C.8090709@redhat.com> Yao Qi wrote: >> >> If ftrace or the UI gets a negative syscall runtime exception should it >> quit? Like lots of other exceptions it's wrapped in a Runtime exception >> and thrown. >> > > we could set up a new class SyscallException to handle this, and > replace RuntimeException with SyscallException. > > IMO, ftrace or the UI could *not* quit when they get negative syscall > runtime exception, could skip this negative syscall, report or log > something, and continue. > Would that be a checked exception? > It was discussed here, > http://sources.redhat.com/ml/frysk/2006-q3/msg00090.html > > Right but not really resolved. It's been a long term issue about how the ui should handle core oops. As we have more core clients it becomes more important and harder to backport changes if required. Regards Phil From zhengyo@cn.ibm.com Fri Sep 15 04:13:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Fri, 15 Sep 2006 04:13:00 -0000 Subject: why not generate rules for assembly programs in common/Makefile.gen.sh? Message-ID: <1158293709.2684.39.camel@YZ_X86_64> hi, In frysk-core/frysk/pkglibexecdir, there are some assembly programs(with the development going on, more assembly programs may be added). But the rules for making them are not generated by Makefile.gen.sh. If one assembly program will be added, the rules must be added in frysk-core/Makefile.am too! This is not so good because adding rules in Makefile.am by hand is not only one boring task but also this will make Makefile.am larger! So we do some modifications on common/Makefile.gen.sh and automatically generate all rules for assembly programs. About the details, see the attached patch. 2006-09-15 Yong Zheng * common/Makefile.gen.sh: Add instructions to generate rules for assembly programs. * frysk-core/Makefile.am: Remove rules for assembly programs. please review. If it ok, we will check them in. Thanks. Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk_common_assembly.patch Type: text/x-patch Size: 2218 bytes Desc: not available URL: From qiyaoltc@cn.ibm.com Fri Sep 15 07:05:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Fri, 15 Sep 2006 07:05:00 -0000 Subject: System call number cached with help from SyscallObserver Message-ID: <20060915070503.GD14319@GreenHouse.cn.ibm.com> It is not *always* right to get system call number from a certain register when exit from a system call, such as rt_sigreturn. This problem has been discussed in this thread, http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html Andrew explained that *all* the registers have been flushed to restore the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or "gpr0"(ppc) does not contain the value of system call number any more. And I could also find that there is a problem caused by this in IRC log, pmuldoon, I'm getting some issues with bash and syscalls npremji: I'm building now, but what issues? a bunch of negative syscall number java runtime exceptions java.lang.RuntimeException: Negative Syscall Number:-1 at frysk.proc.Syscall.syscallByNum(FryskGui) at frysk.proc.LinuxIa32Syscall.syscallByNum(FryskGui) at frysk.proc.LinuxIa32$1.getSyscall(FryskGui) at frysk.gui.monitor.observers.SysCallUtilyInfo.getReturnInfoFromSyscall(FryskGui) at frysk.gui.monitor.observers.TaskSyscallObserver.exitBottomHalf(FryskGui) at frysk.gui.monitor.observers.TaskSyscallObserver$2.run(FryskGui) at org.gnu.glib.CustomEvents.runEvents(libgtkjava-2.8.so) at org.gnu.gtk.Gtk.gtk_main(libgtkjava-2.8.so) npremji: probably from the Sycall checkin last night at org.gnu.gtk.Gtk.main(libgtkjava-2.8.so) at frysk.gui.Gui.gui(FryskGui) at frysk.gui.FryskGui.main(FryskGui) It is not the fault for Syscall to check the range of system call number, but the wrong value when we want to get the system call number from a register. The only thing I could figure out to fix this problem is to add a SyscallObserver to update system call number cached in SyscallEventInfo, or some where else, when enter in a system call, and return system call numbers to other objects that want to know system call information. (Any other solutions, free to tell me) However, some requirements are needed here, 1) This SyscallObserver should be notified first when a syscall come in to update system call number, and other observers will get system call number from the cached value later. How to make this SyscallObserver to be the first? 2) This SyscallObserver could not be added if no other "clients" add SyscallObserver for themselves. If no one add SyscallObserver, we do not need add SyscallObserver to update system call number also. That is to say, this SyscallObserver for system call number update should be added firstly if other "clients", such as ftrace or UI, want to add their SyscallObservers. Any comments? Thanks in advance! -- Yao Qi From aoliva@redhat.com Fri Sep 15 09:48:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Fri, 15 Sep 2006 09:48:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Alexandre Oliva's message of "Wed, 13 Sep 2006 06:43:02 -0300") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 13, 2006, Alexandre Oliva wrote: > there's still something broken in the way compute addresses for > stack traces. > The internal computations are carried out correctly, but when > frysk::rt::StackFrame::initialize() calls unw_get_proc_info(), it > often gets back a fake procedure spec because we can't find unwind > info for it (apparently because of the lack for dyn_list_addr or some > such), so it returns proc_info with a one-byte range covering only the > given IP, but when it calls unw_get_proc_name(), it uses a difference > piece of code that succeeds in locating information about the > procedure, and then it sets offset according to that base address, so > we end up adding the offset to the wrong base address and get wrong > info printed out. > It still fails to print line numbers for main and for kernel vdso > syscalls and their callers, but other than that, it's much better than > before. Here's the patch that fixes line numbers for main() and addresses printed in backtraces for PCs in modules that don't have unwind info. I wonder if I should set an upper limit on the symbol name size instead of keeping retrying until memory is really exhausted or so. Thoughts? Fixing vdso will take new code in libunwind to fetch the vdso ELF image from the target process memory. It doesn't look hard, I'll take a stab at it in my next hacking session. Meanwhile, ok to install in the frysk tree? -------------- next part -------------- A non-text attachment was scrubbed... Name: unwind-fix-offsets.patch Type: text/x-patch Size: 3771 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mark@klomp.org Fri Sep 15 11:48:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 15 Sep 2006 11:48:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <20060915070503.GD14319@GreenHouse.cn.ibm.com> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> Message-ID: <1158320877.3009.41.camel@dijkstra.wildebeest.org> Hi Yao, On Fri, 2006-09-15 at 15:05 +0800, Yao Qi wrote: > It is not *always* right to get system call number from a certain > register when exit from a system call, such as rt_sigreturn. This > problem has been discussed in this thread, > > http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html > > Andrew explained that *all* the registers have been flushed to restore > the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or > "gpr0"(ppc) does not contain the value of system call number any more. > > [...] > > The only thing I could figure out to fix this problem is to add a > SyscallObserver to update system call number cached in > SyscallEventInfo, or some where else, when enter in a system call, and > return system call numbers to other objects that want to know system > call information. (Any other solutions, free to tell me) SyscallObservers are all "equal", you cannot currently add one that has preference over any of the others. But the Task or TaskState could hold this info if needed. What is precisely the use case? When does a SyscallObserver want to get at the syscall number (or arguments) on exit? Can we assume that a SyscallObserver will record Enter/Exit pairs themselves? If so then a SyscallObserver should probably have saved the syscall number and any arguments it is interested in on updateSyscallEnter() so it can use them in updateSyscallExit(). Then when updateSyscallExit() is called the only "valid" thing to query is the return value. If the above is accurate then I think we can/should provide some support inside the TaskState machinery. The TaskState should have an acurate view of whether the Task is inside or outside a system call. What we could add is a way for the TaskObserver.Syscall.updateSyscallEnter() to indicate whether or not it is actually interested in updateSyscallExit() being called. For example by letting it return a Action CONTINUE_INTERESTED or BLOCKED_INTERESTED. If any other Action is returned the observer will not be called when the syscall exits. That way we can make sure that updateSyscallExit() is only called for any syscall that the observer is actually interested in. And if it is interested then we can assume it will have saved the syscall number and any arguments it is interested in itself and that the only thing that it might want to query on exit is the return value. Cheers, Mark From mark@klomp.org Fri Sep 15 12:19:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 15 Sep 2006 12:19:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <450A027C.8080109@redhat.com> References: <450A027C.8080109@redhat.com> Message-ID: <1158322769.3009.52.camel@dijkstra.wildebeest.org> On Thu, 2006-09-14 at 20:31 -0500, Phil Muldoon wrote: > Here is the problem: the clients of the core have been given an > exception. How does that client handle and continue, or handle and quit > in an orderly manner? Should all exceptions be explicitly declared so > that they can be explicitly handled? I would say it depends on the documentation of the class/method you are using. > Here is an example: > > If ftrace or the UI gets a negative syscall runtime exception should it > quit? Like lots of other exceptions it's wrapped in a Runtime exception > and thrown. This seems like a bad state, system kaput, no recovery possible situation. If the method you are calling doesn't document this issue/exception I think you should regard it as a non-recoverable error which leaves the underlying system in an unknown, most likely completely broken state. Don't handle exceptions thrown, but don't documented to occur. It is like a NullPointerException or NegativeArraySizeException. If you weren't the person to provide the reference, array or index that could have caused it (and the documentation should say so), then you have no way of knowing how to handle it, or whether it is a bug (most likely) in the thing you are using. So you should quit as if the system is in a broken/buggy/unrecoverable state. > How can it test if the syscall exception is harmless and can move on? The documentation should say so. If it doesn't then there is no way to know whether or not it is harmless and/or recoverable. So assume it isn't. > How can it differentiate between say a double state transition, or and > unhanded state to above? Both a double state transition or an unhandled event for a state (which I assume you mean) are bugs in the task state machinery and should be interpreted as the core having died and gone to the great bit bucket in /dev/null. Cheers, Mark From mark@klomp.org Fri Sep 15 12:29:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 15 Sep 2006 12:29:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <450A1AC8.2020101@redhat.com> References: <450A027C.8080109@redhat.com> <450A1AC8.2020101@redhat.com> Message-ID: <1158323346.3009.59.camel@dijkstra.wildebeest.org> On Thu, 2006-09-14 at 22:15 -0500, Phil Muldoon wrote: > However from a > purely client point of view, the client still has to figure out: > > 1) Is the exception bad? Will data corruption possibly occur if I continue; > 2) Ah oh well, could not get that information, but it is ok to move on. These are documentation issues. If it isn't documented what a return value or exception thrown means then complain! And the default assumption with exceptions thrown but not documented is that it is really bad. > This leads me to think of four scenarios: > > 1) Do what we do now. Show the exception in a window, and ask if the > user wants to continue or quit > 2) Log the exception and continue > 3) Have a high exception throwing threshold. Only "bad" exceptions are > thrown. > 4) Quit the UI, print the stacktrace, wait for bugzillas 3 is the only real option. And if you don't know what the exception is for then assume it is bad. It is probably a bug and leaves the system in an unknown state. You cannot make the user happy in that case. Cheers, Mark From mark@klomp.org Fri Sep 15 12:34:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 15 Sep 2006 12:34:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <450A1B5C.8090709@redhat.com> References: <450A027C.8080109@redhat.com> <20060915025425.GB14319@GreenHouse.cn.ibm.com> <450A1B5C.8090709@redhat.com> Message-ID: <1158323657.3009.65.camel@dijkstra.wildebeest.org> On Thu, 2006-09-14 at 22:17 -0500, Phil Muldoon wrote: > Would that be a checked exception? > > > It was discussed here, > > http://sources.redhat.com/ml/frysk/2006-q3/msg00090.html > > > > > Right but not really resolved. It's been a long term issue about how the > ui should handle core oops. As we have more core clients it becomes more > important and harder to backport changes if required. I think it was resolved. Just not in a way we would like. I would like to think that if you have checked exceptions then the user has to handle them, so they will make sure to demand documentation for those exceptions that a method declares. And that they take appropriate action since they are forced to either handle the issue or pass it on to their users. But what seemed to happen in practise (almost immediately when checked exceptions were introduced) was that those exceptions are just thrown away unhandled in empty catch blocks as if nothing happened. If that is the case, then it is better to have unchecked exceptions which have as default action to let someone else care about it. Cheers, Mark From mcvet@redhat.com Fri Sep 15 14:12:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 15 Sep 2006 14:12:00 -0000 Subject: frysk-gui lib/opcodes/Disassembler.java lib/op ... In-Reply-To: <20060915003055.GA14319@GreenHouse.cn.ibm.com> References: <20060914203119.9912.qmail@sourceware.org> <20060915003055.GA14319@GreenHouse.cn.ibm.com> Message-ID: <1158329558.2031.114.camel@towel.toronto.redhat.com> On Fri, 2006-09-15 at 08:30 +0800, Yao Qi wrote: > On Thu, Sep 14, 2006 at 08:31:19PM -0000, mcvet@sourceware.org wrote: > > > > Log message: > > frysk-imports/lib/opcodes: > > 2006-09-14 Mike Cvet > > > > * Disassembler.java (appendCurrentInstruction): Changed from > > setCurrentInstruction to prevent overwriting the given > > instruction with the parameters. Now properly appends > > parameters to instructions. > > * cni/Disassembler.cxx (disassemble): Changed the > > i386 and x86_64 instruction flavours to att. > > (read_from_byte_buffer): Fixed up formatting. > > (print_addr): Changed from an empty function to one that > > updates the Disassembler object with the instruction > > address parameter. > > (save_instruction): Fixed up formatting. > Hi, Mike, > I think I submitted a patch to do similar thing, support ppc64 > additionally, on Sep. 3rd, > http://sources.redhat.com/ml/frysk/2006-q3/msg00371.html > > Maybe, I should declare loudly in maillist to avoid duplicate work, :) > I could start to add ppc64 support on your code. > Yao - you're absolutely right. I didn't think to check previous mailing list patches because you now have commit access. My bad. Yes, please go ahead and do any PPC/64 work you need on that file =) - Mike From cagney@redhat.com Fri Sep 15 14:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 15 Sep 2006 14:38:00 -0000 Subject: why not generate rules for assembly programs in common/Makefile.gen.sh? In-Reply-To: <1158293709.2684.39.camel@YZ_X86_64> References: <1158293709.2684.39.camel@YZ_X86_64> Message-ID: <450ABAE5.7080609@redhat.com> Yong, Good idea; ok. Delete this line also though :-) # XXX: This needs to be make less-architecture independant. Andrew Yong Zheng wrote: > hi, > > In frysk-core/frysk/pkglibexecdir, there are some assembly programs(with > the development going on, more assembly programs may be added). But the > rules for making them are not generated by Makefile.gen.sh. If one > assembly program will be added, the rules must be added in > frysk-core/Makefile.am too! This is not so good because adding rules in > Makefile.am by hand is not only one boring task but also this will make > Makefile.am larger! So we do some modifications on > common/Makefile.gen.sh and automatically generate all rules for assembly > programs. About the details, see the attached patch. > > 2006-09-15 Yong Zheng > > * common/Makefile.gen.sh: Add instructions to generate rules for > assembly programs. > * frysk-core/Makefile.am: Remove rules for assembly programs. > > please review. If it ok, we will check them in. Thanks. > > Best regards > Yong Zheng > > ------------------------------------------------------------------------ > > Index: common/Makefile.gen.sh > =================================================================== > RCS file: /cvs/frysk/frysk-common/Makefile.gen.sh,v > retrieving revision 1.109 > diff -u -r1.109 Makefile.gen.sh > --- common/Makefile.gen.sh 29 Aug 2006 21:40:12 -0000 1.109 > +++ common/Makefile.gen.sh 15 Sep 2006 03:53:48 -0000 > @@ -400,6 +400,23 @@ > done > done > > +# > +# Generate rules for .S/.s assembly files > +# > +for suffix in .s .S ; do > + print_header "... ${suffix}" > + find ${dirs} \ > + -name "[A-Za-z]*${suffix}" -print \ > + | sort -f | while read file ; do > + d=`dirname ${file}` > + b=`basename ${file} ${suffix}` > + name=${d}/${b} > + name_=`echo ${name} | sed -e 'y,/-,__,'` > + > + echo "${name_}_SOURCES = ${file}" > + echo_PROGRAMS ${name} > + done > +done > > # Grep the cni/*.cxx files forming a list of included files. Assume > # these are all generated from .class files. The list can be pruned a > Index: frysk-core/Makefile.am > =================================================================== > RCS file: /cvs/frysk/frysk-core/Makefile.am,v > retrieving revision 1.66 > diff -u -r1.66 Makefile.am > --- frysk-core/Makefile.am 12 Sep 2006 17:28:57 -0000 1.66 > +++ frysk-core/Makefile.am 15 Sep 2006 03:55:42 -0000 > @@ -94,18 +94,6 @@ > > # XXX: This needs to be make less-architecture independant. > > -frysk_pkglibexecdir_funit_ia32_regs_SOURCES = frysk/pkglibexecdir/funit-ia32-regs.S > -pkglibexec_PROGRAMS += frysk/pkglibexecdir/funit-ia32-regs > -frysk_pkglibexecdir_funit_ia32_modify_SOURCES = frysk/pkglibexecdir/funit-ia32-modify.S > -pkglibexec_PROGRAMS += frysk/pkglibexecdir/funit-ia32-modify > -frysk_pkglibexecdir_funit_x8664_regs_SOURCES = frysk/pkglibexecdir/funit-x8664-regs.S > -pkglibexec_PROGRAMS += frysk/pkglibexecdir/funit-x8664-regs > -frysk_pkglibexecdir_funit_x8664_modify_SOURCES = frysk/pkglibexecdir/funit-x8664-modify.S > -pkglibexec_PROGRAMS += frysk/pkglibexecdir/funit-x8664-modify > - > -frysk_pkglibexecdir_funit_ppc64_regs_SOURCES = frysk/pkglibexecdir/funit-ppc64-regs.S > -pkglibexec_PROGRAMS += frysk/pkglibexecdir/funit-ppc64-regs > - > # For TestExec.java > pkglibexec_PROGRAMS += frysk/pkglibexecdir/funit-child-alias > frysk_pkglibexecdir_funit_child_alias_SOURCES = > From cagney@redhat.com Fri Sep 15 15:07:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 15 Sep 2006 15:07:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <450A027C.8080109@redhat.com> References: <450A027C.8080109@redhat.com> Message-ID: <450AC1B4.1020004@redhat.com> Phil Muldoon wrote: > I thought I'd start this conversation going. It's been an action item > for awhile. There are two issues here, and I think it is important to consider each separately: 1) the first is a core panic, which from the UI point-of-view is asynchronous and fatal The only technical point worth debating here is how to get the core to cleanly extract itself from the tasks it;s controlling; and perhaps should the core be started a-new. 2) a failure during a synchronous I/O operation (such as fetch a register) which could either be a table-lookup failure or (rarely) kernel spontaneously disappeared a task I gather it is the second one that is of concern here. While more meaningful exceptions would be useful here, for the specific case at hand I think, as Yao pointed out, that the correct thing is to _not_ throw an exception. A target program having a bogus syscall num should not lead to any exception being thrown - from frysk's point-of-view a bogus syscall num is just as valid as a correct num. Andrew From cagney@redhat.com Fri Sep 15 15:17:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 15 Sep 2006 15:17:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <1158320877.3009.41.camel@dijkstra.wildebeest.org> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> Message-ID: <450AC3E9.9010800@redhat.com> Mark Wielaard wrote: > For example by letting it return a Action CONTINUE_INTERESTED or > BLOCKED_INTERESTED. If any other Action is returned the observer will > not be called when the syscall exits. > > The sole purpose of of Action is to provide a mechanism that facilitates the implementation of both in-band and out-of-band handling of notifications. Andrew From mark@klomp.org Fri Sep 15 15:28:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 15 Sep 2006 15:28:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <450AC3E9.9010800@redhat.com> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <450AC3E9.9010800@redhat.com> Message-ID: <1158334069.3009.75.camel@dijkstra.wildebeest.org> Hi Andrew, On Fri, 2006-09-15 at 11:16 -0400, Andrew Cagney wrote: > The sole purpose of of Action is to provide a mechanism that facilitates > the implementation of both in-band and out-of-band handling of > notifications. What does that mean? And what alternative do you suggest? Cheers, Mark From cagney@redhat.com Fri Sep 15 15:29:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 15 Sep 2006 15:29:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <1158320877.3009.41.camel@dijkstra.wildebeest.org> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> Message-ID: <450AC6C0.6070301@redhat.com> Mark Wielaard wrote: > Hi Yao, > > On Fri, 2006-09-15 at 15:05 +0800, Yao Qi wrote: > >> It is not *always* right to get system call number from a certain >> register when exit from a system call, such as rt_sigreturn. This >> problem has been discussed in this thread, >> >> http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html >> >> Andrew explained that *all* the registers have been flushed to restore >> the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or >> "gpr0"(ppc) does not contain the value of system call number any more. >> >> [...] >> >> The only thing I could figure out to fix this problem is to add a >> SyscallObserver to update system call number cached in >> SyscallEventInfo, or some where else, when enter in a system call, and >> return system call numbers to other objects that want to know system >> call information. (Any other solutions, free to tell me) >> > > SyscallObservers are all "equal", you cannot currently add one that has > preference over any of the others. But the Task or TaskState could hold > this info if needed. > > What is precisely the use case? When does a SyscallObserver want to get > at the syscall number (or arguments) on exit? Can we assume that a > SyscallObserver will record Enter/Exit pairs themselves? If so then a > SyscallObserver should probably have saved the syscall number and any > arguments it is interested in on updateSyscallEnter() so it can use them > in updateSyscallExit(). Then when updateSyscallExit() is called the only > "valid" thing to query is the return value. > > Yes. If there's one system call that modifies the syscall num, then I'm sure there'll be others. I'd for the moment just have the client cache the number locally. When there proves to be sufficient demand, having the core cache that value becomes an option. Andrew From cagney@redhat.com Fri Sep 15 15:37:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 15 Sep 2006 15:37:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <1158334069.3009.75.camel@dijkstra.wildebeest.org> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <450AC3E9.9010800@redhat.com> <1158334069.3009.75.camel@dijkstra.wildebeest.org> Message-ID: <450AC8B5.10906@redhat.com> Mark Wielaard wrote: > Hi Andrew, > > On Fri, 2006-09-15 at 11:16 -0400, Andrew Cagney wrote: > >> The sole purpose of of Action is to provide a mechanism that facilitates >> the implementation of both in-band and out-of-band handling of >> notifications. >> > > What does that mean? > > in-band == handle within the core's event-loop thread - don't block this obviously implies that during processing the core event-loop is stalled; while simple, it is also an architectural compromise out-of-band == handle by some other thread - block then unblock since the event-loop is never stalled more parallelism is possible Andrew From pmuldoon@redhat.com Fri Sep 15 15:55:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Fri, 15 Sep 2006 15:55:00 -0000 Subject: Core Exception Throwing and Handling In-Reply-To: <450AC1B4.1020004@redhat.com> References: <450A027C.8080109@redhat.com> <450AC1B4.1020004@redhat.com> Message-ID: <450ACCF9.4010009@redhat.com> Andrew Cagney wrote: > Phil Muldoon wrote: >> I thought I'd start this conversation going. It's been an action item >> for awhile. > There are two issues here, and I think it is important to consider > each separately: > > 1) the first is a core panic, which from the UI point-of-view is > asynchronous and fatal > The only technical point worth debating here is how to get the core to > cleanly extract itself from the tasks it;s controlling; and perhaps > should the core be started a-new. Actually I wanted to bring this out too, and debate the mechanism for this. Right now all core exceptions are noted in the same way (RuntimeExceptions). Is the way forward to only have Runtime exceptions for above? > > 2) a failure during a synchronous I/O operation (such as fetch a > register) which could either be a table-lookup failure or (rarely) > kernel spontaneously disappeared a task > > I gather it is the second one that is of concern here. While more > meaningful exceptions would be useful here, for the specific case at > hand I think, as Yao pointed out, that the correct thing is to _not_ > throw an exception. A target program having a bogus syscall num > should not lead to any exception being thrown - from frysk's > point-of-view a bogus syscall num is just as valid as a correct num. I might be splitting hairs here, buy Yao did not make that suggestion. Yao mentioned that: "we could set up a new class SyscallException to handle this, and replace RuntimeException with SyscallException. IMO, ftrace or the UI could *not* quit when they get negative syscall runtime exception, could skip this negative syscall, report or log something, and continue." Which I fully agree with. We should not quit on a "negative syscall runtime exception." And it is not the specific case, but all cases in general. I counted roughly 83 different locations in the core that Runtime Exceptions are thrown. I'm fully bought on the idea that checked exceptions are not the best thing since slice bread ;) I'm just musing in a solution that the absence of them leaves behind. So... I guess what I am interpreting here is, reduce the number of thrown exceptions, only throw them for point 1) and for all of 2) let the core handle them internally (either with null return calls, or something else?) Regards Phil > > Andrew > > > From tromey@redhat.com Fri Sep 15 16:29:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Fri, 15 Sep 2006 16:29:00 -0000 Subject: Patch: StackFrame.toString() In-Reply-To: <20060911051051.GC19394@GreenHouse.cn.ibm.com> References: <20060911051051.GC19394@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: >> I'm happy to document these accessors if someone would confirm that >> this is the intended interpretation. Yao> This patch is fine to me. Thanks. I'll write up javadoc for StackFrame sometime soon. >> + public String toString () >> + { >> + StringBuffer builder = new StringBuffer("at 0x"); >> + builder.append(Long.toHexString(getAddress())); >> + String mn = getMethodName(); >> + if (mn != null && ! "".equals(mn)) Yao> Just one question for my curiosity, Yao> Is there any difference between ""equals(mn) and mn.equals("")? It is a fairly common java style to write it as "".equals(mn), because this will avoid a NullPointerException if mn==null. In this case it doesn't matter as we're explicitly checking for null. Tom From npremji@redhat.com Fri Sep 15 17:31:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Fri, 15 Sep 2006 17:31:00 -0000 Subject: New requirement for FC6: binutils-devel Message-ID: <1158341501.31762.0.camel@tow.toronto.redhat.com> As of this morning, the binutils-devel package is required to build frysk on FC6. From tromey@redhat.com Fri Sep 15 18:03:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Fri, 15 Sep 2006 18:03:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <1158057896.3087.36.camel@dijkstra.wildebeest.org> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> <1158057896.3087.36.camel@dijkstra.wildebeest.org> Message-ID: >>>>> "Mark" == Mark Wielaard writes: >> On Fri, 2006-09-08 at 17:51 -0600, Tom Tromey wrote: >> This makes the strace '-e' argument look a little weird now too. If >> the user 'ftrace's all 'open' calls, should it be every open call from >> every ISA? I suppose we could try to enumerate every ISA supported by >> the host platform... Mark> Well a Task knows which Isa it belongs to, so whenever ftrace starts Mark> tracing a new Task (or rather Proc) it should just reinterpret the '-e' Mark> argument for that process. Yeah, I completely forgot the Task->Isa connection. Thanks. I made a note to update ftrace to do this. Tom From mcvet@redhat.com Fri Sep 15 19:34:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Fri, 15 Sep 2006 19:34:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: <1158348836.2331.1.camel@towel.toronto.redhat.com> On Fri, 2006-09-15 at 06:48 -0300, Alexandre Oliva wrote: > On Sep 13, 2006, Alexandre Oliva wrote: > > > there's still something broken in the way compute addresses for > > stack traces. > > > The internal computations are carried out correctly, but when > > frysk::rt::StackFrame::initialize() calls unw_get_proc_info(), it > > often gets back a fake procedure spec because we can't find unwind > > info for it (apparently because of the lack for dyn_list_addr or some > > such), so it returns proc_info with a one-byte range covering only the > > given IP, but when it calls unw_get_proc_name(), it uses a difference > > piece of code that succeeds in locating information about the > > procedure, and then it sets offset according to that base address, so > > we end up adding the offset to the wrong base address and get wrong > > info printed out. > > > It still fails to print line numbers for main and for kernel vdso > > syscalls and their callers, but other than that, it's much better than > > before. > > Here's the patch that fixes line numbers for main() and addresses > printed in backtraces for PCs in modules that don't have unwind info. > I wonder if I should set an upper limit on the symbol name size > instead of keeping retrying until memory is really exhausted or so. > Thoughts? > > > Fixing vdso will take new code in libunwind to fetch the vdso ELF > image from the target process memory. It doesn't look hard, I'll take > a stab at it in my next hacking session. > > > Meanwhile, ok to install in the frysk tree? > I tested out the new changes and everything looks better than before. Looks good to commit, thanks! - Mike From aoliva@redhat.com Sat Sep 16 07:34:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Sat, 16 Sep 2006 07:34:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <1158348836.2331.1.camel@towel.toronto.redhat.com> (Mike Cvet's message of "Fri, 15 Sep 2006 15:33:56 -0400") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> <1158348836.2331.1.camel@towel.toronto.redhat.com> Message-ID: On Sep 15, 2006, Mike Cvet wrote: >> Meanwhile, ok to install in the frysk tree? > I tested out the new changes and everything looks better than before. > Looks good to commit, thanks! Thanks, here are exact patches I checked in. -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-not-remote-only.patch Type: text/x-patch Size: 1554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unwind-inter-callbacks.patch Type: text/x-patch Size: 25031 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-fix-offsets.patch Type: text/x-patch Size: 3771 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Sat Sep 16 07:43:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Sat, 16 Sep 2006 07:43:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Alexandre Oliva's message of "Fri, 15 Sep 2006 06:48:10 -0300") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 15, 2006, Alexandre Oliva wrote: > Fixing vdso will take new code in libunwind to fetch the vdso ELF > image from the target process memory. It doesn't look hard, I'll take > a stab at it in my next hacking session. Here it is. Ok to install in frysk? We get perfect stack traces for Tom's fdtrace with this patch, even when running 32-bit processes on the FC6T3 x86_64 kernel, that leaves the path portion empty in /proc/PID/maps in the last line, corresponding to the VDSO. -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-vdso.patch Type: text/x-patch Size: 16748 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Sun Sep 17 06:16:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Sun, 17 Sep 2006 06:16:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Alexandre Oliva's message of "Fri, 15 Sep 2006 06:48:10 -0300") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 15, 2006, Alexandre Oliva wrote: > Here's the patch that fixes line numbers for main() and addresses > printed in backtraces for PCs in modules that don't have unwind info. > I wonder if I should set an upper limit on the symbol name size > instead of keeping retrying until memory is really exhausted or so. > Thoughts? Here's another approach I thought of, that involves a change in the interface of the get_proc_name callback, requiring it to cope with a NULL buf and zero buf_len. We could do away with the latter, and pass in ~(size_t)0 for essentially the same effect, but since it hardly makes any difference, I thought I'd go for both. Is this ok for frysk? It should reduce the stack size requirements when unwinding through ridiculously long symbol names. Ok for frysk? -------------- next part -------------- A non-text attachment was scrubbed... Name: libunwind-get-proc-info-no-buf.patch Type: text/x-patch Size: 9379 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Sun Sep 17 07:45:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Sun, 17 Sep 2006 07:45:00 -0000 Subject: implement backtraces for AMD64 Message-ID: This patch adds the missing bits to enable libunwind-based backtraces on AMD64/EM64T. A few notes: - The existing IsaEMT64 is misnamed: the correct spelling is EM64T, not EMT64. We should probably prefer the more neutral X86_64 name (as in the ELF data structure), or favor AMD64, like I did in the new RegisterAMD64 class (just trying to set balance ;-) - I'm not entirely happy with adding libunwind-specific information to Isa, but Isa doesn't currently provide enough information to enable some alternate implementation that would keep everything entirely separate. If we had a method to return the Isa name or the ELF machine type or some such, then it would be possible to turn that into a reworked Register* factory/singleton pattern similar to that used for Isa, all within lib/unwind. It certainly doesn't help that lib/unwind is in frysk-imports, so it can't use anything in frysk-core; frysk-core/rt would have to have the glue. Comments? Any architectural guidance? Or is this ok to install? -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-unwind-amd64.patch Type: text/x-patch Size: 10245 bytes Desc: not available URL: -------------- next part -------------- -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From ajocksch@redhat.com Sun Sep 17 19:16:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Sun, 17 Sep 2006 19:16:00 -0000 Subject: patches to frysk-imports/lib/dw Message-ID: <450D9EFF.2090905@redhat.com> I've wrapped the necessary functionality needed to find inlined function calls in the libdw wrapper (see attached patch). I'm not 100% certain where this code should be called from though. Ideally while libunwind is unwinding (i.e. in one of the callbacks so we open as few Dwfl objects as possible), but for a first implementation maybe it would be worth doing it after libunwind has created the stack trace. Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: Dwarf_DIE_is_inlined.patch Type: text/x-patch Size: 1537 bytes Desc: not available URL: From qiyaoltc@cn.ibm.com Mon Sep 18 03:38:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 18 Sep 2006 03:38:00 -0000 Subject: implement backtraces for AMD64 In-Reply-To: References: Message-ID: <20060918033736.GA2378@GreenHouse.cn.ibm.com> On Sun, Sep 17, 2006 at 04:45:00AM -0300, Alexandre Oliva wrote: > This patch adds the missing bits to enable libunwind-based backtraces > on AMD64/EM64T. A few notes: > > - The existing IsaEMT64 is misnamed: the correct spelling is EM64T, > not EMT64. We should probably prefer the more neutral X86_64 name (as > in the ELF data structure), or favor AMD64, like I did in the new > RegisterAMD64 class (just trying to set balance ;-) X86_64 is a neutral one, and emt64/em64t/amd64 should be replaced by x86_64 or x8664 later. > > - I'm not entirely happy with adding libunwind-specific information to > Isa, but Isa doesn't currently provide enough information to enable > some alternate implementation that would keep everything entirely > separate. If we had a method to return the Isa name or the ELF > machine type or some such, then it would be possible to turn that into > a reworked Register* factory/singleton pattern similar to that used > for Isa, all within lib/unwind. It certainly doesn't help that > lib/unwind is in frysk-imports, so it can't use anything in > frysk-core; frysk-core/rt would have to have the glue. I have added a method toString() in Isa to return Isa name, but I did not check it in. If you think it is needed, I will code a patch for it. Personally, I think Isa.toString is useful. There has been a factory for Isa, frysk-core/frysk/proc/IsaFacotry.java, and this factory gets machine type from ELF file, /proc//exe. It is fine to me to add a register factory for libunwind. > > Comments? Any architectural guidance? Or is this ok to install? > -- Yao Qi From qiyaoltc@cn.ibm.com Mon Sep 18 08:52:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 18 Sep 2006 08:52:00 -0000 Subject: frysk-gui lib/opcodes/Disassembler.java lib/op ... In-Reply-To: <1158329558.2031.114.camel@towel.toronto.redhat.com> References: <20060914203119.9912.qmail@sourceware.org> <20060915003055.GA14319@GreenHouse.cn.ibm.com> <1158329558.2031.114.camel@towel.toronto.redhat.com> Message-ID: <20060918085209.GB2378@GreenHouse.cn.ibm.com> > > Yao - you're absolutely right. I didn't think to check previous mailing > list patches because you now have commit access. My bad. > > Yes, please go ahead and do any PPC/64 work you need on that file =) This patch is about disassembly support for ppc64. 2006-09-18 Yao Qi * Instruction.java (length): New member. * Disassembler.java (setCurrentInstructionLength): New method. * cni/Disassembler.cxx (disassemble): Fill in instruction length. * tests/TestOpcodes.java: Add test case for powerpc. * tests/DummyByteBuffer.java (DummyByteBuffer): Write dummy byte buffer for powerpc. (peek): Modify the condition as 0 is the first index. (poke): Likewise. Test it on x86/x86_64/ppc64, and checked it in. Mike, here is a question, DisassemblyWindow is "disabled" on PPC64 and X86_64, and if I remove the first several lines of toggleDisassemblyWindow(), an exception will be thrown out when I open Disassembly Window. Is there any bug filed in sourceware about this problem? I think you have realized this problem, otherwise you will not disable it on 64-bit platform. -- Yao Qi From mark@klomp.org Mon Sep 18 10:43:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 18 Sep 2006 10:43:00 -0000 Subject: Test and fix for syscall observer adding (bug #3147) In-Reply-To: <1157373132.2965.85.camel@dijkstra.wildebeest.org> References: <1157114157.3062.16.camel@dijkstra.wildebeest.org> <1157117181.6659.4.camel@hermans.wildebeest.org> <1157144484.6659.18.camel@hermans.wildebeest.org> <1157373132.2965.85.camel@dijkstra.wildebeest.org> Message-ID: <1158576184.27921.7.camel@dijkstra.wildebeest.org> Hi, On Mon, 2006-09-04 at 14:32 +0200, Mark Wielaard wrote: > On Fri, 2006-09-01 at 23:01 +0200, Mark Wielaard wrote: > > For the testcase I can of course do some tricks and see if accept() is a > > syscall or, if not, whether socketcall() is available and then select > > based on the first argument of the syscall to see if it really is accept > > (#5). But this seems 1) fragile and 2) looks like a general problem > > people will have when using Syscall Observers. > > I worked around it for the test case by just using the SYSread call for > now: > > 2006-09-04 Mark Wielaard > > * funit-syscall-running.c: Accept socket and read() for it. > > 2006-09-04 Mark Wielaard > > * TestSyscallRunning.java: Added back, use SYSread and write to > Socket. > > For the testcase this is OK since it just tests something low-level. But > I think in general we have to look how people will want to use the > syscalls and whether or not to provide something more portable and > higher level. This test still failed sometimes as pointed out by http://sourceware.org/bugzilla/show_bug.cgi?id=3193 It was actually a bug in the test case. I rewrote the testcase to test for accept again (which is possible now cross-architecture thanks to Yao) and the observer now explicitly keeps track of whether or not it is inside the correct syscall. 2006-09-18 Mark Wielaard Fixes bug #3193 * TestSyscallRunning (SyscallObserver): Take syscall name and whether the syscall is in an entered state. Use Syscall.getByName() for accept. 2006-09-18 Mark Wielaard * funit-syscall-running.c: Don't read, just accept socket. Tested on both x86 and x86_64. This test does show that trying to keep track of syscalls in an observer is a little fragile since the observer alone cannot know whether the task is running in a syscall already. Since the Task(State) does know it does make sense to expose this info to the observers. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: syscall-running-accept.patch Type: text/x-patch Size: 4183 bytes Desc: not available URL: From cagney@redhat.com Mon Sep 18 14:06:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 18 Sep 2006 14:06:00 -0000 Subject: patches to frysk-imports/lib/dw In-Reply-To: <450D9EFF.2090905@redhat.com> References: <450D9EFF.2090905@redhat.com> Message-ID: <450EA7DD.7080005@redhat.com> Adam Jocksch wrote: > I've wrapped the necessary functionality needed to find inlined > function calls in the libdw wrapper (see attached patch). I'm not 100% > certain where this code should be called from though. Ideally while > libunwind is unwinding (i.e. in one of the callbacks so we open as few > Dwfl objects as possible), but for a first implementation maybe it > would be worth doing it after libunwind has created the stack trace. > Yes. Even long term. They are separate operations. libunwind provides a list of ABI frame instances; given an ABI frame instance, libdw can return a list of inlined functions. Further, in general, the code needs to head in the direction of being on-demand. While the initial cut of libunwind, for instance, can generate a full backtrace up front, it will longer term need to act more on demand - only performing an unwind an actually required. For instance: - when single stepping, the code will need to do a single frame unwind to determine if/where a step-into or step-out-of function occured - no other frames are needed and typically the test is immediatly followed by an unblock (i.e., continue) - as a performance tweak, when backtracing, the current backtrace can be spliced onto a previous cached backtrace - avoiding unwind overhead. Andrew From cagney@redhat.com Mon Sep 18 14:10:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 18 Sep 2006 14:10:00 -0000 Subject: frysk-gui lib/opcodes/Disassembler.java lib/op ... In-Reply-To: <20060918085209.GB2378@GreenHouse.cn.ibm.com> References: <20060914203119.9912.qmail@sourceware.org> <20060915003055.GA14319@GreenHouse.cn.ibm.com> <1158329558.2031.114.camel@towel.toronto.redhat.com> <20060918085209.GB2378@GreenHouse.cn.ibm.com> Message-ID: <450EA8E2.9030501@redhat.com> > . > > Test it on x86/x86_64/ppc64, and checked it in. > > Mike, here is a question, > DisassemblyWindow is "disabled" on PPC64 and X86_64, and if I remove > the first several lines of toggleDisassemblyWindow(), an exception > will be thrown out when I open Disassembly Window. Is there any bug > filed in sourceware about this problem? > > Yes, now where is it .... http://sourceware.org/bugzilla/show_bug.cgi?id=1537 gives the wrong solution to the right bug. I think it should be using BigInteger so that it is 128-bit future proof. Andrew > I think you have realized this problem, otherwise you will not disable > it on 64-bit platform. > > From tromey@redhat.com Mon Sep 18 14:53:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 18 Sep 2006 14:53:00 -0000 Subject: Patch: fix up Syscall a bit Message-ID: This patch fixes a few bugs in the new Syscall code: * The unknownSyscalls hash maps were not created properly, so unknown syscall objects would not be properly cached. I fixed this in the simplest way, by initializing the fields in Linux*.java; it could also be done a bit more lazily in the accessors, if desired. * I made iterateSyscallByName be package-private. There's no reason for this to be public, it is just a random utility method. * I changed a couple places to catch TaskException instead of Exception -- over-catching exceptions is mildly ugly. I changed these same places to do exception chaining; chaining is a best practice that enables better debugging in the field. * I changed a couple places to avoid a redundant Integer.toString when using the String "+" operator. There were no test suite regressions on x86 FC5... there was one failure but I backed out my patch and I observed it with an unmodified tree. Ok? Tom Index: ChangeLog from Tom Tromey * LinuxX8664Syscall.java (unknownSyscalls): Initialize. * LinuxPPC.java (unknownSyscalls): Initialize. * LinuxPPC64.java (unknownSyscalls): Initialize. * LinuxPowerPCSyscall.java (unknownSyscalls): Initialize. * LinuxIa32Syscall.java (unknownSyscalls): Initialize. * LinuxEMT64.java (unknownSyscalls): Initialize. * Syscall.java (syscallByName): Chain exceptions. Don't "over catch". (iterateSyscallByName): Now package-private. (syscallByNum): Removed redundant toString. Chain exceptions. Removed dead code. Synchronize on hash map. Index: LinuxEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxEMT64.java,v retrieving revision 1.3 diff -u -r1.3 LinuxEMT64.java --- LinuxEMT64.java 14 Sep 2006 05:58:58 -0000 1.3 +++ LinuxEMT64.java 16 Sep 2006 23:44:49 -0000 @@ -54,7 +54,7 @@ // This is used to keep track of syscalls whose number we do not // know. - static HashMap unknownSyscalls; + static HashMap unknownSyscalls = new HashMap(); private SyscallEventInfo info; Index: LinuxIa32Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxIa32Syscall.java,v retrieving revision 1.1 diff -u -r1.1 LinuxIa32Syscall.java --- LinuxIa32Syscall.java 14 Sep 2006 05:58:58 -0000 1.1 +++ LinuxIa32Syscall.java 16 Sep 2006 23:44:49 -0000 @@ -48,7 +48,7 @@ // This is used to keep track of syscalls whose number we do not // know. - static HashMap unknownSyscalls; + static HashMap unknownSyscalls = new HashMap(); static class Ia32Syscall extends Syscall Index: LinuxPPC.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC.java,v retrieving revision 1.5 diff -u -r1.5 LinuxPPC.java --- LinuxPPC.java 14 Sep 2006 05:58:58 -0000 1.5 +++ LinuxPPC.java 16 Sep 2006 23:44:49 -0000 @@ -22,7 +22,7 @@ // This is used to keep track of syscalls whose number we do not // know. - static HashMap unknownSyscalls; + static HashMap unknownSyscalls = new HashMap(); private SyscallEventInfo info; Index: LinuxPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC64.java,v retrieving revision 1.5 diff -u -r1.5 LinuxPPC64.java --- LinuxPPC64.java 14 Sep 2006 05:58:58 -0000 1.5 +++ LinuxPPC64.java 16 Sep 2006 23:44:49 -0000 @@ -21,7 +21,7 @@ // This is used to keep track of syscalls whose number we do not // know. - static HashMap unknownSyscalls; + static HashMap unknownSyscalls = new HashMap(); private SyscallEventInfo info; public SyscallEventInfo getSyscallEventInfo () Index: LinuxPowerPCSyscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPowerPCSyscall.java,v retrieving revision 1.1 diff -u -r1.1 LinuxPowerPCSyscall.java --- LinuxPowerPCSyscall.java 14 Sep 2006 05:58:58 -0000 1.1 +++ LinuxPowerPCSyscall.java 16 Sep 2006 23:44:50 -0000 @@ -48,7 +48,7 @@ // This is used to keep track of syscalls whose number we do not // know. - static HashMap unknownSyscalls; + static HashMap unknownSyscalls = new HashMap(); static class PowerPCSyscall extends Syscall Index: LinuxX8664Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxX8664Syscall.java,v retrieving revision 1.1 diff -u -r1.1 LinuxX8664Syscall.java --- LinuxX8664Syscall.java 14 Sep 2006 05:58:58 -0000 1.1 +++ LinuxX8664Syscall.java 16 Sep 2006 23:44:50 -0000 @@ -46,7 +46,7 @@ // This is used to keep track of syscalls whose number we do not // know. - static HashMap unknownSyscalls; + static HashMap unknownSyscalls = new HashMap(); static class X8664Syscall extends Syscall Index: Syscall.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/Syscall.java,v retrieving revision 1.13 diff -u -r1.13 Syscall.java --- Syscall.java 14 Sep 2006 05:58:58 -0000 1.13 +++ Syscall.java 16 Sep 2006 23:44:50 -0000 @@ -63,6 +63,7 @@ this.argList = argList; this.noreturn = noreturn; } + Syscall (String name, int number, int numArgs, String argList) { this.name = name; @@ -230,7 +231,7 @@ * @param syscallList system calls list * @return the Syscall object, or null */ - public static Syscall iterateSyscallByName (String name, Syscall[] syscallList) + static Syscall iterateSyscallByName (String name, Syscall[] syscallList) { for (int i = 0; i < syscallList.length; ++i) if (name.equals(syscallList[i].name)) @@ -243,8 +244,8 @@ * Syscall object. Note that system call numbers are platform * dependent. This will return a Syscall object in all cases; if * there is no predefined system call with the given number, a unique - * "unknown" system call with the indicated number will be saved in - * unknownSyscalls. + * "unknown" system call with the indicated number will be created. + * * @param num the number of the system call * @param task the current task * @return the Syscall object @@ -259,24 +260,21 @@ syscallList = task.getIsa().getSyscallList (); unknownSyscalls = task.getIsa().getUnknownSyscalls (); } - catch (Exception e) + catch (TaskException e) { - throw new RuntimeException ("Could not get the isa"); + throw new RuntimeException ("Could not get the isa", e); } if (num < 0) { - throw new RuntimeException ("Negative Syscall Number:" + - Integer.toString(num)); + throw new RuntimeException ("Negative syscall number: " + num); } else if (num >= syscallList.length) { - synchronized (Syscall.class) + synchronized (unknownSyscalls) { Integer key = new Integer(num); - if (unknownSyscalls == null) - unknownSyscalls = new HashMap(); - else if (unknownSyscalls.containsKey(key)) + if (unknownSyscalls.containsKey(key)) return (Syscall) unknownSyscalls.get(key); class UnknownSyscall @@ -296,8 +294,7 @@ return 0; } } - Syscall result = new UnknownSyscall("UNKNOWN SYSCALL " - + Integer.toString(num), num); + Syscall result = new UnknownSyscall("UNKNOWN SYSCALL " + num, num); unknownSyscalls.put(key, result); @@ -327,9 +324,9 @@ { syscall = task.getIsa().syscallByName(name); } - catch (Exception e) + catch (TaskException e) { - throw new RuntimeException ("Could not get the name of isa"); + throw new RuntimeException ("Could not get the name of isa", e); } return syscall; From pmuldoon@redhat.com Mon Sep 18 16:27:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 18 Sep 2006 16:27:00 -0000 Subject: Patch: fix up Syscall a bit In-Reply-To: References: Message-ID: <450EC8E3.2040607@redhat.com> My only general concern is the over-use of throwing exceptions in syscall look-ups. (I realize, Tom., that you just changed the Exception and did not put the original Exception in there). I thought this would be a good place to ask the question as it is in the patch. In the location: > @@ -259,24 +260,21 @@ > syscallList = task.getIsa().getSyscallList (); > unknownSyscalls = task.getIsa().getUnknownSyscalls (); > } > - catch (Exception e) > + catch (TaskException e) > { > - throw new RuntimeException ("Could not get the isa"); > + throw new RuntimeException ("Could not get the isa", e); > } > > if (num < 0) > { > - throw new RuntimeException ("Negative Syscall Number:" + > - Integer.toString(num)); > + throw new RuntimeException ("Negative syscall number: " + num); > } > else if (num >= syscallList.length) > { > - synchronized (Syscall.class) > + synchronized (unknownSyscalls) > { > Integer key = new Integer(num); > - if (unknownSyscalls == null) > - unknownSyscalls = new HashMap(); > - else if (unknownSyscalls.containsKey(key)) > + if (unknownSyscalls.containsKey(key)) > return (Syscall) unknownSyscalls.get(key); > > class UnknownSyscall And here: > > @@ -327,9 +324,9 @@ > { > syscall = task.getIsa().syscallByName(name); > } > - catch (Exception e) > + catch (TaskException e) > { > - throw new RuntimeException ("Could not get the name of isa"); > + throw new RuntimeException ("Could not get the name of isa", e); > } > > return syscall; > This exception will stop the event loop for implementing clients (and as the exception is unchecked, very hard to check on the severity). Would it be better to return null in these places instead of completely aborting with a throw? Regards Phil From tromey@redhat.com Mon Sep 18 16:28:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 18 Sep 2006 16:28:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <1158320877.3009.41.camel@dijkstra.wildebeest.org> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> Message-ID: >>>>> "Mark" == Mark Wielaard writes: Mark> What is precisely the use case? When does a SyscallObserver want to get Mark> at the syscall number (or arguments) on exit? Here's one example: http://sourceware.org/bugzilla/show_bug.cgi?id=3185 Mark> Can we assume that a Mark> SyscallObserver will record Enter/Exit pairs themselves? If so then a Mark> SyscallObserver should probably have saved the syscall number and any Mark> arguments it is interested in on updateSyscallEnter() so it can use them Mark> in updateSyscallExit(). Then when updateSyscallExit() is called the only Mark> "valid" thing to query is the return value. Speaking as a user of this API... I'm definitely surprised to find out that this wouldn't work on syscall exit. Of course, this isn't so bad if the restrictions are documented, and preferably enforced in the implementation. E.g., it wouldn't be too bad to have to call cacheArgumentData() and then have getArguments() fail if the syscall exited and this was not called. (BTW, getArguments is wrongly named afaics, since it actually fetches a single argument...) Having the user store the data by hand is certainly possible. However, there are a few ugly bits. For instance, currently there's no public info about the number and types of syscall arguments. Also in my hacked ftrace I was able to get the appended exception. >From what I can tell I can't even fetch the Syscall object in the updateSyscallExit callback. I got this by tracing bash and running 'ls'; when ls exits I get the exception. Also once I get this exception the traced process seems to be in a weird state... I tried tracing this bash again, and the bash becomes non-responsive (as if the ptrace attach succeeded), but the new ftrace instance prints nothing. To see this I think you'd need my ftrace with '-p' support. Tom 29084.29084 sigreturn ()Exception in thread "Thread-1" java.lang.RuntimeException: Negative syscall number: -1 at frysk.proc.Syscall.syscallByNum(Syscall.java:268) at frysk.proc.LinuxIa32Syscall.syscallByNum(LinuxIa32Syscall.java:507) at frysk.proc.LinuxIa32$1.getSyscall(LinuxIa32.java:66) at frysk.ftrace.Ftrace$SyscallObserver.updateSyscallExit(Ftrace.java:357) at frysk.proc.Task.notifySyscallExit(Task.java:834) at frysk.proc.TaskState$Running.handleSyscalledEvent(TaskState.java:1083) at frysk.proc.Task.processSyscalledEvent(Task.java:412) at frysk.proc.LinuxHost$PollWaitOnSigChld$2.syscallEvent(LinuxHost.java:376) at frysk.sys.Wait.waitAllNoHang(Wait.cxx:230) at frysk.proc.LinuxHost$PollWaitOnSigChld.execute(LinuxHost.java:419) at frysk.event.EventLoop.runEventLoop(EventLoop.java:309) at frysk.event.EventLoop.run(EventLoop.java:415) From tromey@redhat.com Mon Sep 18 16:49:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 18 Sep 2006 16:49:00 -0000 Subject: Patch: fix up Syscall a bit In-Reply-To: <450EC8E3.2040607@redhat.com> References: <450EC8E3.2040607@redhat.com> Message-ID: >> { >> syscall = task.getIsa().syscallByName(name); >> } >> - catch (Exception e) >> + catch (TaskException e) >> { >> - throw new RuntimeException ("Could not get the name of isa"); >> + throw new RuntimeException ("Could not get the name of isa", e); >> } >> return syscall; >> Phil> This exception will stop the event loop for implementing clients (and Phil> as the exception is unchecked, very hard to check on the Phil> severity). Would it be better to return null in these places instead Phil> of completely aborting with a throw? >From what I can tell this only occurs if Task.getIsa() fails. But if that fails I think something pretty bad is going on here... since it means the code is watching a Task, sees a system call, and then the Task fails to return its ISA. To me that sounds like an internal error of some kind, but I don't actually know for certain. Is there a "normal" situation in which this might happen? Tom From pmuldoon@redhat.com Mon Sep 18 17:01:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 18 Sep 2006 17:01:00 -0000 Subject: Patch: fix up Syscall a bit In-Reply-To: References: <450EC8E3.2040607@redhat.com> Message-ID: <450ED0C3.10907@redhat.com> Tom Tromey wrote: >>> { >>> syscall = task.getIsa().syscallByName(name); >>> } >>> - catch (Exception e) >>> + catch (TaskException e) >>> { >>> - throw new RuntimeException ("Could not get the name of isa"); >>> + throw new RuntimeException ("Could not get the name of isa", e); >>> } >>> return syscall; >>> >>> > > Phil> This exception will stop the event loop for implementing clients (and > Phil> as the exception is unchecked, very hard to check on the > Phil> severity). Would it be better to return null in these places instead > Phil> of completely aborting with a throw? > > From what I can tell this only occurs if Task.getIsa() fails. > But if that fails I think something pretty bad is going on > here... since it means the code is watching a Task, sees a system > call, and then the Task fails to return its ISA. To me that sounds > like an internal error of some kind, but I don't actually know for > certain. Is there a "normal" situation in which this might happen? > > Oops point taken on that one. I think with the discussion on unchecked versus checked over the last several weeks, maybe moving to some kind of strategy of the core managing its own minor glitches and notifying the client of "really bad things". What is the criteria for that, you raise a good point. Actually the main argument was regarding the negative syscall lookup. I guess the second point is, should a syscall lookup on a single Task throw an exception that stops the event loop (maybe the task disappeared, and the refresh had not caught up with that fact yet?). This touches on the frysk modeling the whole system, versus modeling a single Proc. A dodgy task should not, imo, scuttle the whole affair. Anyway, I did not want to derail your patch submission into another error/exception thread ;) Other than the worrying about exceptions it looks really good. Regards Phil From cagney@redhat.com Mon Sep 18 18:50:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Mon, 18 Sep 2006 18:50:00 -0000 Subject: ftrace In-Reply-To: <4501D2CA.7060206@redhat.com> References: <4500807A.8070706@redhat.com> <4501D2CA.7060206@redhat.com> Message-ID: <450EEA91.3090302@redhat.com> Andrew Cagney wrote: > Tom Tromey wrote: >> Andrew> The main issues with adopting another getopt alternative are: >> that it >> Andrew> be sane; that we only have one (we're not in the business of >> Andrew> babysitting multiple redundant packages - which would mean >> eliminating >> Andrew> jargs); and its license be workable. >> >> * Sane... well, I think so :-) >> * Eliminating jargs... at your discretion of course >> * License... GPL+E like the rest of Classpath >> >> Tom >> > In that case "done" :-) Tom, I just noticed some jargs code still luring (frysk.junit.Runner), was that on the delete list or was there a problem? Andrew From tromey@redhat.com Mon Sep 18 18:54:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 18 Sep 2006 18:54:00 -0000 Subject: ftrace In-Reply-To: <450EEA91.3090302@redhat.com> References: <4500807A.8070706@redhat.com> <4501D2CA.7060206@redhat.com> <450EEA91.3090302@redhat.com> Message-ID: >>>>> "Andrew" == Andrew Cagney writes: Andrew> Tom, I just noticed some jargs code still luring (frysk.junit.Runner), Andrew> was that on the delete list or was there a problem? I haven't even looked at this stuff yet. My hacked ftrace isn't in the tree at all. Tom From pmuldoon@redhat.com Mon Sep 18 20:12:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Mon, 18 Sep 2006 20:12:00 -0000 Subject: draft patch to add signaled observers to the ui Message-ID: <450EFD8A.7090306@redhat.com> I've added task signaled observer to the UI. When the relevant observer event happens, two default actions take place. A log action, and a plot to the eventviewer widget of that task, if it has a widget. Regards Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signaled.patch Type: text/x-patch Size: 7576 bytes Desc: not available URL: From ajocksch@redhat.com Mon Sep 18 22:44:00 2006 From: ajocksch@redhat.com (Adam Jocksch) Date: Mon, 18 Sep 2006 22:44:00 -0000 Subject: checked in DwarfDie.isInlinedFunction Message-ID: <450F215D.9040202@redhat.com> I've checked in my previous patch to DwarfDie.java. I also added a line to TestDwfl.java, but I have left it commented out for now as I'm not sure of how wise it would be to include code that relies on whether or not a function is inlined. Adam 2006-09-18 Adam Jocksch * DwarfDie.java (isInlinedFunction): New. (is_inline_func): New. * cni/DwarfDie.cxx (is_inline_func): New. * tests/TestDwfl.java (testGetDie): Added commented out line to test isInlinedFunction, do not want to enable this right now until we are sure it does not break the build. From tromey@redhat.com Tue Sep 19 00:33:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 19 Sep 2006 00:33:00 -0000 Subject: Patch: StackFrame.toString() In-Reply-To: <20060911051051.GC19394@GreenHouse.cn.ibm.com> References: <20060911051051.GC19394@GreenHouse.cn.ibm.com> Message-ID: Tom> I thought it would be handy if StackFrame had a toString method that Tom> did something sensible. Patch appended. I've updated this patch to add javadoc for the accessors I use. However in doing so I noticed that some of the things I thought were valid, no longer are. In particular getSourceFile() will never return null now -- instead sourceFile is set to "" in the constructor. I think the previous behavior is preferable -- now there is no good way to tell whether the stack frame's source file is known. I didn't see anything depending on this, so I changed it back. Also I noticed a typo in the API, the updated patch fixes this everywhere. Before I check this in (assuming it blessed of course) I wanted to ask about all the new accessors in StackFrame. Any word on what their boundary values are? Will startLine == lineNum always be true? (And if so, how about we get rid of one of them entirely?) What are the startOffset and endOffset fields for? I tried to run this through 'make check' on x86 FC5 but it hung in the breakpoint tests; I assume this isn't caused by this patch but I haven't checked yet. In any case this isn't quite ready since I'd like to document the other accessors first. Tom Index: frysk-core/frysk/rt/ChangeLog from Tom Tromey * StackFrame.java (toString): New method. (StackFrame): Don't initialize sourceFile if file is not known. (startOffset): Renamed. (getStartOffset): Likewise. Index: frysk-core/frysk/rt/StackFrame.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/rt/StackFrame.java,v retrieving revision 1.5 diff -u -r1.5 StackFrame.java --- frysk-core/frysk/rt/StackFrame.java 18 Sep 2006 15:52:09 -0000 1.5 +++ frysk-core/frysk/rt/StackFrame.java 19 Sep 2006 00:25:53 -0000 @@ -61,7 +61,7 @@ private int endLine; - private int startOffsset; + private int startOffset; private int endOffset; @@ -96,16 +96,12 @@ this.lineNum = line.getLineNum(); this.startLine = this.lineNum; this.endLine = this.lineNum; - this.startOffsset = 0; + this.startOffset = 0; this.endOffset = -1; this.sourceFile = line.getSourceFile(); this.column = line.getColumn(); } } - else - { - this.sourceFile = ""; - } } public void setFunction(DOMFunction f) @@ -132,16 +128,29 @@ return this.data; } + /** + * Return the name of the function associated with this stack frame. + * This will return null if the function's name is not known. + */ public String getMethodName () { return methodName; } + /** + * Return the name of the source file associated with this stack + * frame. If the source file is not known, this will return null. + */ public String getSourceFile () { return sourceFile; } + /** + * Return the line number of the source code associated with this + * stack frame. Line numbers begin at 1. If the source line number + * is not known, this will return 0. + */ public int getLineNumber () { return lineNum; @@ -178,13 +187,46 @@ { return outer; } + + /** + * Return a string representation of this stack frame. + * The returned string is suitable for display to the user. + */ + public String toString () + { + StringBuffer builder = new StringBuffer("0x"); + builder.append(Long.toHexString(getAddress())); + String mn = getMethodName(); + if (mn != null && ! "".equals(mn)) + { + builder.append(" in function: "); + builder.append(getMethodName()); + } + String sf = getSourceFile(); + int line = getLineNumber(); + if (sf != null || line != 0) + { + builder.append(" ("); + if (sf != null) + builder.append(sf); + else + builder.append("Unknown source"); + if (line != 0) + { + builder.append(":"); + builder.append(line); + } + builder.append(")"); + } + return builder.toString(); + } public int getEndLine () { return endLine; } - public void setEndLine (int i ) + public void setEndLine (int i) { this.endLine = i; } @@ -204,8 +246,8 @@ this.startLine = i; } - public int getStartOffsset () + public int getStartOffset () { - return startOffsset; + return startOffset; } } Index: frysk-gui/frysk/gui/srcwin/ChangeLog from Tom Tromey * CurrentLineSection.java (startOffset): Renamed. (CurrentLineSection): Updated. (getStartOffset): Renamed. (setStartOffset): Likewise. * SourceBuffer.java (setCurrentLine): Use renamed getStartOffset. Index: frysk-gui/frysk/gui/srcwin/CurrentLineSection.java =================================================================== RCS file: /cvs/frysk/frysk-gui/frysk/gui/srcwin/CurrentLineSection.java,v retrieving revision 1.3 diff -u -r1.3 CurrentLineSection.java --- frysk-gui/frysk/gui/srcwin/CurrentLineSection.java 8 Sep 2006 18:19:36 -0000 1.3 +++ frysk-gui/frysk/gui/srcwin/CurrentLineSection.java 19 Sep 2006 00:25:55 -0000 @@ -46,7 +46,7 @@ private int endLine; - private int startOffsset; + private int startOffset; private int endOffset; @@ -59,7 +59,7 @@ { startLine = lineStart; endLine = lineEnd; - startOffsset = colStart; + startOffset = colStart; endOffset = colEnd; } @@ -113,13 +113,13 @@ this.startLine = startLine; } - public int getStartOffsset () + public int getStartOffset () { - return startOffsset; + return startOffset; } - public void setStartOffsset (int startOffsset) + public void setStartOffset (int startOffset) { - this.startOffsset = startOffsset; + this.startOffset = startOffset; } } Index: frysk-gui/frysk/gui/srcwin/SourceBuffer.java =================================================================== RCS file: /cvs/frysk/frysk-gui/frysk/gui/srcwin/SourceBuffer.java,v retrieving revision 1.69 diff -u -r1.69 SourceBuffer.java --- frysk-gui/frysk/gui/srcwin/SourceBuffer.java 18 Sep 2006 15:52:09 -0000 1.69 +++ frysk-gui/frysk/gui/srcwin/SourceBuffer.java 19 Sep 2006 00:25:55 -0000 @@ -267,7 +267,7 @@ { int startLine = frame.getStartLine(); - int startCol = frame.getStartOffsset(); + int startCol = frame.getStartOffset(); int endLine = frame.getEndLine(); int endCol = frame.getEndOffset(); From tromey@redhat.com Tue Sep 19 00:42:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 19 Sep 2006 00:42:00 -0000 Subject: Sign extend 32-bit register values and Bug #3055 In-Reply-To: <45056BDD.4080706@redhat.com> References: <20060906040250.GE13314@GreenHouse.cn.ibm.com> <45056BDD.4080706@redhat.com> Message-ID: >> Yao Qi wrote: >> long in java is 64-bit, and 32-bit register value should be sign >> extended. We override Register.get() in Isa to do sign extension for >> Ia32 and PPC(32-bit platforms). Andrew> The underlying issue here, though, is that a << Register has-a Type >> Andrew> and the type is what determines the characteristics of the register's Andrew> value. For instance, a program counter might have an unsigned type, Andrew> while general purpose registers have signed types. (This would Andrew> address TomT's question). Yeah... in my situation I want something pretty simple: I want to know if a given close() system call failed. It seems to me that in this case "something" between my code and the raw registers ought to realize that close() returns a C 'int' and that this ought to be sign extended into a java 'long' so that my code sees the correct value in a platform-neutral way. I don't really care where this happens; doing it in Syscall.getReturnCode would suit me fine, and would avoid pushing type information down to the register interface. And this would handily avoid the problem of whether the ISA has signed or unsigned addresses. Tom From tromey@redhat.com Tue Sep 19 00:55:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 19 Sep 2006 00:55:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <20060913121843.GB17676@GreenHouse.cn.ibm.com> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> <1158057582.3087.29.camel@dijkstra.wildebeest.org> <20060913121843.GB17676@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: Mark> Nice output! Mark> BTW, it should output the port it is listening on to stdin. Then you can Mark> connect to that port from some other terminal and see it continue. Yao> How could I *connect* to that port in other terminal? telnet localhost $port Tom From tromey@redhat.com Tue Sep 19 00:56:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 19 Sep 2006 00:56:00 -0000 Subject: [patch review] Syscall for multi-arch support In-Reply-To: <1158057582.3087.29.camel@dijkstra.wildebeest.org> References: <20060908125442.GA1364@GreenHouse.cn.ibm.com> <1158057582.3087.29.camel@dijkstra.wildebeest.org> Message-ID: >>>>> "Mark" == Mark Wielaard writes: Mark> Would it make sense to extend Syscall with a getArguments() that returns Mark> the number of arguments of the syscall? Yes, definitely. Mark> And maybe a way to access the Mark> arguments with their correct type? Also yes. Tom From qiyaoltc@cn.ibm.com Tue Sep 19 01:07:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 19 Sep 2006 01:07:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <1158320877.3009.41.camel@dijkstra.wildebeest.org> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> Message-ID: <20060919010634.GC2378@GreenHouse.cn.ibm.com> On Fri, Sep 15, 2006 at 01:47:57PM +0200, Mark Wielaard wrote: > Hi Yao, > > On Fri, 2006-09-15 at 15:05 +0800, Yao Qi wrote: > > It is not *always* right to get system call number from a certain > > register when exit from a system call, such as rt_sigreturn. This > > problem has been discussed in this thread, > > > > http://sources.redhat.com/ml/frysk/2006-q3/msg00305.html > > > > Andrew explained that *all* the registers have been flushed to restore > > the state of that thread, so "orig_eax"(ia32), "orig_rax"(x86_64) or > > "gpr0"(ppc) does not contain the value of system call number any more. > > > > [...] > > > > The only thing I could figure out to fix this problem is to add a > > SyscallObserver to update system call number cached in > > SyscallEventInfo, or some where else, when enter in a system call, and > > return system call numbers to other objects that want to know system > > call information. (Any other solutions, free to tell me) > > What is precisely the use case? When does a SyscallObserver want to get > at the syscall number (or arguments) on exit? Can we assume that a Here is an example, class SyscallObserver implements TaskObserver.Syscall { ...... public Action updateSyscallExit(Task task) { SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task); int syscallNum = syscallEventInfo.number (task); if (syscallNum == SyscallNum.SYSopen || syscallNum == SyscallNum.SYSclose) { exited++; } return Action.CONTINUE; } ...... } System call number is needed in updateSyscall{Enter|Exit}. The problem is that system call number is needed in updateSyscall{Enter|Exit}, but the method to get system call number, when enter and exit syscall, should be different.(get number from a register when enter, and get number from a cached value when exit), but SyscallEventInfo.number does not know it is called in updateSyscallEnter or updateSyscallExit. > SyscallObserver will record Enter/Exit pairs themselves? If so then a > SyscallObserver should probably have saved the syscall number and any > arguments it is interested in on updateSyscallEnter() so it can use them > in updateSyscallExit(). Then when updateSyscallExit() is called the only > "valid" thing to query is the return value. There are two methods for interface TaskObserver.Syscall, updateSyscallEnter and updateSyscallExit, and they are invoked when enter and exit a system call. Yes, SyscallObserver *should* have saved the syscall number in updateSyscallEnter(), but updateSyscallEnter() does not save syscall number now. If syscall number is saved in updateSyscallEnter() in SyscallObserver, all the classes that implement updateSyscallEnter() should be aware of this details, and save the syscall number by themselves. It is not good, since every time, when we implement updateSyscallEnter(), we should save the syscall number by ourselves.(Correct me if I am wrong) IMO, SyscallEventInfo is the good place to cache system call number, and provides a method number(Task task, Boolean enterSyscall), which return the system call number and cache it when enterSyscall is true, while return the cached syscall number when enterSyscall is false. The current number(Task) return system call number *always* from a certain register. -- Yao Qi From qiyaoltc@cn.ibm.com Tue Sep 19 03:48:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 19 Sep 2006 03:48:00 -0000 Subject: Enable testGetLine except X86_64 Message-ID: <20060919034729.GD2378@GreenHouse.cn.ibm.com> In bug #2965, Tim reported that this case failed on X8664, but this case works on x86 and ppc64. I code a patch to run this case except on X86_64. 2006-09-19 Yao Qi * TestCase.java (brokenX8664XXX): New method. 2006-09-19 Yao Qi * tests/TestDwfl.java (testGetLine): Skip it when build on X86_64. Change the line number result for powerpc64. Checked it in. -- Yao Qi -------------- next part -------------- Index: frysk-imports/frysk/junit/TestCase.java =================================================================== RCS file: /cvs/frysk/frysk-imports/frysk/junit/TestCase.java,v retrieving revision 1.1 diff -u -r1.1 TestCase.java --- frysk-imports/frysk/junit/TestCase.java 28 Aug 2006 17:36:37 -0000 1.1 +++ frysk-imports/frysk/junit/TestCase.java 19 Sep 2006 02:22:01 -0000 @@ -78,4 +78,16 @@ return false; } + /** + * A method that returns true, and prints skip, when the build + * architecture is X86_64. + */ + protected static boolean brokenX8664XXX (int bug) + { + if (Build.BUILD_ARCH.indexOf ("_64") != - 1) { + return brokenXXX (bug); + } + return false; + } + } Index: frysk-imports/lib/dw/tests/TestDwfl.java =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/dw/tests/TestDwfl.java,v retrieving revision 1.14 diff -u -r1.14 TestDwfl.java --- frysk-imports/lib/dw/tests/TestDwfl.java 18 Sep 2006 22:25:01 -0000 1.14 +++ frysk-imports/lib/dw/tests/TestDwfl.java 19 Sep 2006 02:22:01 -0000 @@ -53,8 +53,9 @@ { public void testGetLine () { - if (brokenXXX(2965)) + if (brokenX8664XXX(2965)) return; + Dwfl dwfl = new Dwfl(TestLib.getPid()); assertNotNull(dwfl); DwflLine line = dwfl.getSourceLine(TestLib.getFuncAddr()); @@ -65,8 +66,8 @@ if(Build.BUILD_ARCH.indexOf("x86_64") != -1) assertEquals(55, line.getLineNum()); - else if (Build.BUILD_ARCH.indexOf("powerpc") != -1) - assertEquals(53, line.getLineNum()); + else if (Build.BUILD_ARCH.indexOf("powerpc64") != -1) + assertEquals(51, line.getLineNum()); else assertEquals(51, line.getLineNum()); From woodzltc@cn.ibm.com Tue Sep 19 11:13:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Tue, 19 Sep 2006 11:13:00 -0000 Subject: remote unwinding of libunwind Message-ID: <450FD0D2.5000703@cn.ibm.com> Noticing there are quite some stack-unwind code checked into CVS, I spared some time to play around. The test results seem to be quite satisfactory. It can now get the function name in the dynamically-loaded library, and extract the source and line information if available. And it also start to support multi-thread unwinding now. But I also noticed some little problems. The first one is while I am playing with Kyle's code. It can step / unwind both threads now, but it seems the unwinder swallows some frames for itself own consumption. :-) Looking into the below unwind session, you will notice that there are four level fames in both threads. But in fact, there are six frames in each. You can see this from the pstack output. $ ./unwinddebug Enter the PID of the main therad: 8297 Assuming second thread is pid 8298 Tracing main thread! Frames of pid 8297: found frame 0 0000000000bfb402 (sp=00000000bfe87ba4) found frame 1 0000000008048893 main+0x10e (sp=00000000bfe87d70) found frame 2 0000000000c2e724 __libc_start_main+0xdc (sp=00000000bfe87dd0) found frame 3 0000000008048521 _start+0x21 (sp=00000000bfe87e40) Trace Depth = 4 Tracing second thread! Frames of pid 8298: found frame 0 0000000000bfb402 +0x21 (sp=00000000b7eef264) found frame 1 00000000080486b6 thread1+0x77 (sp=00000000b7eef430) found frame 2 0000000000db440b start_thread+0xa9 (sp=00000000b7eef460) found frame 3 0000000000ce1b7e __clone+0x5e (sp=00000000b7eef4d0) Trace Depth = 4 $ pstack 8297 Thread 2 (Thread -1209074784 (LWP 8298)): #0 0x00bfb402 in __kernel_vsyscall () #1 0x00ca3f16 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x00ca3d3b in sleep () from /lib/libc.so.6 #3 0x080486b6 in thread1 () #4 0x00db440b in start_thread () from /lib/libpthread.so.0 #5 0x00ce1b7e in clone () from /lib/libc.so.6 Thread 1 (Thread -1209071296 (LWP 8297)): #0 0x00bfb402 in __kernel_vsyscall () #1 0x00ca3f16 in __nanosleep_nocancel () from /lib/libc.so.6 #2 0x00ca3d3b in sleep () from /lib/libc.so.6 #3 0x08048893 in main () The second one is found while I am playing with Tromey's fdtrace: # ./frysk/bindir/fdtrace /home/woodzltc/fdtrace/Closer2 bad close() call at: val = 0; in function: null ( at line 0) val = 134513583; in function: doit2 (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 9) val = 134513607; in function: main (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 13) val = 12773156; in function: __libc_start_main (Unknown file at line 0) val = 134513409; in function: _start (Unknown file at line 0) bad close() call at: val = 0; in function: null ( at line 0) val = 134513583; in function: doit2 (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 9) val = 134513607; in function: main (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 13) val = 12773156; in function: __libc_start_main (Unknown file at line 0) val = 134513409; in function: _start (Unknown file at line 0) The address of the first frame seems to be 0, and "doit()" and "close()" was swallowed as well. Anyone noticed these problems before? Is there any work to make improvement on this? BTW, I also have one observation that libunwind has only two test cases for remote unwinding. That is far from enough, IMO. Stack unwind has quite some different scenarios, especially in remote unwind. We will have no way to be sure how it works in these scenario, if we have not test them. So I predict there are yet some other problems some where we didn't noticed. My two cents is we need to write much more cases to evaluate how libunwind works in various scenarios: single thread and multi-threads, normal operation and abnormal operation (signal frame or exception handler or non-local jump)... It is better if we can also extract the backtrace information from the core dumped out. Regards - Wu Zhou From zhengyo@cn.ibm.com Tue Sep 19 12:06:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Tue, 19 Sep 2006 12:06:00 -0000 Subject: Two patches to add bi-arch test in frysk. In-Reply-To: <450847C0.3050900@redhat.com> References: <1158131338.3390.103.camel@YZ_X86_64> <450847C0.3050900@redhat.com> Message-ID: <1158667632.2684.46.camel@YZ_X86_64> On Wed, 2006-09-13 at 14:02 -0400, Andrew Cagney wrote: > Yong Zheng wrote: > > hi, > > Yong, I'll try to catch up tonight (my time) on irc to talk 'bout this - > just a few questions. And I need to think a little :-) > > Andrew > The patches to add bi-arch test in frysk is blocking by some problems found in PPC64. After we do some modifications on the patches, we will post them out again. Sorry for that! Best regards Yong Zheng From mark@klomp.org Tue Sep 19 12:08:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 19 Sep 2006 12:08:00 -0000 Subject: Enable testGetLine except X86_64 In-Reply-To: <20060919034729.GD2378@GreenHouse.cn.ibm.com> References: <20060919034729.GD2378@GreenHouse.cn.ibm.com> Message-ID: <1158667656.3033.7.camel@dijkstra.wildebeest.org> Hi, On Tue, 2006-09-19 at 11:47 +0800, Yao Qi wrote: > In bug #2965, Tim reported that this case failed on X8664, but this > case works on x86 and ppc64. I code a patch to run this case > except on X86_64. The test case does work for me on x86_64. I don't know why it is failing for Tim, maybe a different compiler that puts a different line number in the debug info? I simplified the testcase a little so all architectures should report the same line number as follows: 2006-09-19 Mark Wielaard * tests/cni/TestLib.cxx (getFuncAddr): Extract define out of function and put whole definition on one line. * tests/TestDwfl.java (testGetLine): Use same line number for all architectures. This way the compiler has no choice but to say the function definition is on line 58. Committed. Please let me know if it still fails somewhere. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: TestDwfl-line.patch Type: text/x-patch Size: 1219 bytes Desc: not available URL: From mark@klomp.org Tue Sep 19 12:20:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 19 Sep 2006 12:20:00 -0000 Subject: Patch: StackFrame.toString() In-Reply-To: References: <20060911051051.GC19394@GreenHouse.cn.ibm.com> Message-ID: <1158668411.3033.12.camel@dijkstra.wildebeest.org> Hi Tom, On Mon, 2006-09-18 at 18:26 -0600, Tom Tromey wrote: > I tried to run this through 'make check' on x86 FC5 but it hung in the > breakpoint tests; I assume this isn't caused by this patch but I > haven't checked yet. That is bad. I cannot see how such a thing would be caused by this patch. Unfortunately I don't have an x86 fc5 box anymore. But on x86_64/fc5 all tests pass. Could you provide some more info on what you are seeing. Or maybe just report a bug with the output of: ./TestRunner -c FINE frysk.proc.TestBreakpoints Thanks, Mark From mark@klomp.org Tue Sep 19 12:22:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 19 Sep 2006 12:22:00 -0000 Subject: Enable testGetLine except X86_64 In-Reply-To: <1158667656.3033.7.camel@dijkstra.wildebeest.org> References: <20060919034729.GD2378@GreenHouse.cn.ibm.com> <1158667656.3033.7.camel@dijkstra.wildebeest.org> Message-ID: <1158668519.3033.13.camel@dijkstra.wildebeest.org> On Tue, 2006-09-19 at 14:07 +0200, Mark Wielaard wrote: > I simplified the testcase a little so all architectures should report > the same line number as follows: > > 2006-09-19 Mark Wielaard > > * tests/cni/TestLib.cxx (getFuncAddr): Extract define out of > function and put whole definition on one line. > * tests/TestDwfl.java (testGetLine): Use same line number for all > architectures. Oops, forgot to attach the interesting part of the patch. Index: frysk-imports/lib/dw/tests/cni/TestLib.cxx =================================================================== RCS file: /cvs/frysk/frysk-imports/lib/dw/tests/cni/TestLib.cxx,v retrieving revision 1.3 diff -u -r1.3 TestLib.cxx --- frysk-imports/lib/dw/tests/cni/TestLib.cxx 7 Aug 2006 13:25:26 -0000 1.3 +++ frysk-imports/lib/dw/tests/cni/TestLib.cxx 19 Sep 2006 11:58:35 -0000 @@ -47,11 +47,12 @@ return (jint) getpid(); } -jlong -lib::dw::tests::TestLib::getFuncAddr(){ #ifdef __powerpc64__ - return *((jlong*) &getFuncAddr); + #define FUNC_ADDR *((jlong*) &getFuncAddr) #else - return (jlong) &getFuncAddr; + #define FUNC_ADDR (jlong) &getFuncAddr; #endif -} + +// All one one line to make debug line number info predictable +// Next line is line #58 +jlong lib::dw::tests::TestLib::getFuncAddr(){ return FUNC_ADDR; } From zhengyo@cn.ibm.com Tue Sep 19 12:35:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Tue, 19 Sep 2006 12:35:00 -0000 Subject: [patch]why not follow CFLAGS when using $CC in some packages of frysk? Message-ID: <1158669365.2684.74.camel@YZ_X86_64> hi, In frysk, no CFLAGS is followed in some packages, such as elfutils and libunwind, when the $(CC) is used. This may be not so preferable. If we want to compile these packages using -O3 or some other options, we won't get what we expect because all they will be compiled by using no options or some fixed options in the make rules. Thus, we can pass CFLAGS into all packages, but CFLAGS won't take effect in some pacakges! This goes worse if the "-m64" is given as one CFLAGS in PPC64. We write one patch to fix this problem. The patch is split into two parts: frysk-CFLAGS-common.patch and frysk-CFLAGS-supplement.patch. The former should be applied to $FRYSK and $FRYSK-; The latter is for $FRYSK. 2006-09-19 Yong Zheng * common/Makefile.rules: Add $(CFLAGS) for .a.so rules. * frysk-gtk/tlwidgets/Makefile.am: Add $(CFLAGS) for .a.so rules. * frysk-imports/elfutils/src/Makefile.am: Add $(CFLAGS) for libld_elf_i386.so. * frysk-imports/libunwind/src/Makefile.in: Add $(CFLAGS) to $(LINK). Please review. Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-CFLAGS-common.patch Type: text/x-patch Size: 450 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-CFLAGS-supplement.patch Type: text/x-patch Size: 1527 bytes Desc: not available URL: From mark@klomp.org Tue Sep 19 12:44:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 19 Sep 2006 12:44:00 -0000 Subject: draft patch to add signaled observers to the ui In-Reply-To: <450EFD8A.7090306@redhat.com> References: <450EFD8A.7090306@redhat.com> Message-ID: <1158669835.3033.27.camel@dijkstra.wildebeest.org> Hi Phil, On Mon, 2006-09-18 at 15:11 -0500, Phil Muldoon wrote: > I've added task signaled observer to the UI. When the relevant observer > event happens, two default actions take place. A log action, and a plot > to the eventviewer widget of that task, if it has a widget. Great, that is cool to have in the gui. I noticed the message produced in the logs is: Signaled Observer: PID: 14913 TID: 14913 Event: has pending signal: SIGQUIT That is interesting. When the signal observer hits we haven't tried to deliver the signal yet. But it seems there is no way to actually observe the signal hitting the Task. And for all we know the Task will block the signal. I am not sure how to get at this info. Maybe we need to set a CodeObserver on the signal table entry points. But I don't know how to get at those. Ideas? Cheers, Mark From mcvet@redhat.com Tue Sep 19 13:11:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 19 Sep 2006 13:11:00 -0000 Subject: Patch: StackFrame.toString() In-Reply-To: References: <20060911051051.GC19394@GreenHouse.cn.ibm.com> Message-ID: <1158671491.2104.12.camel@towel.toronto.redhat.com> On Mon, 2006-09-18 at 18:26 -0600, Tom Tromey wrote: > In particular getSourceFile() will never return null now -- instead > sourceFile is set to "" in the constructor. I think the > previous behavior is preferable -- now there is no good way to tell > whether the stack frame's source file is known. I didn't see anything > depending on this, so I changed it back. Sure. > Before I check this in (assuming it blessed of course) I wanted to ask > about all the new accessors in StackFrame. Any word on what their > boundary values are? Will startLine == lineNum always be true? (And > if so, how about we get rid of one of them entirely?) What are the > startOffset and endOffset fields for? These members were taken straight out of CurrentLineSection with the intention of removing that class entirely, along with a couple others. I believe that the original use for startOffset and endOffset are the offsets to the beginning and end of the function in memory from that frame's last executed address, but I don't think that they were ever set in CurrentLineSection anyway. Once #3192 gets resolved, I can figure out whether these new fields are actually needed, but I'm not optimistic about it =) - Mike From mcvet@redhat.com Tue Sep 19 13:16:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 19 Sep 2006 13:16:00 -0000 Subject: [Libunwind-devel] Re: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: <1158671788.2104.16.camel@towel.toronto.redhat.com> On Sat, 2006-09-16 at 04:42 -0300, Alexandre Oliva wrote: > On Sep 15, 2006, Alexandre Oliva wrote: > > > Fixing vdso will take new code in libunwind to fetch the vdso ELF > > image from the target process memory. It doesn't look hard, I'll take > > a stab at it in my next hacking session. > > Here it is. Ok to install in frysk? We get perfect stack traces for > Tom's fdtrace with this patch, even when running 32-bit processes on > the FC6T3 x86_64 kernel, that leaves the path portion empty in > /proc/PID/maps in the last line, corresponding to the VDSO. > Go for it - Mike From kasal@ucw.cz Tue Sep 19 13:27:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Tue, 19 Sep 2006 13:27:00 -0000 Subject: [patch]why not follow CFLAGS when using $CC in some packages of frysk? In-Reply-To: <1158669365.2684.74.camel@YZ_X86_64> References: <1158669365.2684.74.camel@YZ_X86_64> Message-ID: <20060919132651.GA11142@camelia.ucw.cz> Hello, On Tue, Sep 19, 2006 at 08:36:05PM +0800, Yong Zheng wrote: > In frysk, no CFLAGS is followed in some packages, such as elfutils and > libunwind, when the $(CC) is used. these are external packages, which we cannot directly influence. We can have local patches as a short-time solution. But it is supposed that the patches won't accumulate, they should be pushed upstream. Sometimes there are other solutions possible though: When building frysk for Fedora Core, I faced certain problems with the build system of elfutils (another problem with CFLAGS). I was not able to convince Roland (the maintainer of elfutils) to accept a solution for the problem. But fortunatley, the long-term plan for frysk on Fedora Core is to use elfutils as an external package, skipping the copy embedded in frysk---and that way my problem with elfutils' build system will simply disappear. (Well, I'm afraid this success story won't help you much...) Stepan From mcvet@redhat.com Tue Sep 19 14:59:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 19 Sep 2006 14:59:00 -0000 Subject: remote unwinding of libunwind In-Reply-To: <450FD0D2.5000703@cn.ibm.com> References: <450FD0D2.5000703@cn.ibm.com> Message-ID: <1158677938.2104.33.camel@towel.toronto.redhat.com> On Tue, 2006-09-19 at 19:13 +0800, Wu Zhou wrote: > Noticing there are quite some stack-unwind code checked into CVS, I spared some time to play around. > The test results seem to be quite satisfactory. It can now get the function name in the > dynamically-loaded library, and extract the source and line information if available. And it also > start to support multi-thread unwinding now. > > But I also noticed some little problems. The first one is while I am playing with Kyle's code. It > can step / unwind both threads now, but it seems the unwinder swallows some frames for itself own > consumption. :-) Looking into the below unwind session, you will notice that there are four level > fames in both threads. But in fact, there are six frames in each. You can see this from the pstack > output. > > $ ./unwinddebug > Enter the PID of the main therad: 8297 > Assuming second thread is pid 8298 > Tracing main thread! > Frames of pid 8297: > > found frame 0 > 0000000000bfb402 (sp=00000000bfe87ba4) > found frame 1 > 0000000008048893 main+0x10e (sp=00000000bfe87d70) > found frame 2 > 0000000000c2e724 __libc_start_main+0xdc (sp=00000000bfe87dd0) > found frame 3 > 0000000008048521 _start+0x21 (sp=00000000bfe87e40) > > Trace Depth = 4 > > Tracing second thread! > Frames of pid 8298: > > found frame 0 > 0000000000bfb402 +0x21 (sp=00000000b7eef264) > found frame 1 > 00000000080486b6 thread1+0x77 (sp=00000000b7eef430) > found frame 2 > 0000000000db440b start_thread+0xa9 (sp=00000000b7eef460) > found frame 3 > 0000000000ce1b7e __clone+0x5e (sp=00000000b7eef4d0) > > Trace Depth = 4 > > $ pstack 8297 > Thread 2 (Thread -1209074784 (LWP 8298)): > #0 0x00bfb402 in __kernel_vsyscall () > #1 0x00ca3f16 in __nanosleep_nocancel () from /lib/libc.so.6 > #2 0x00ca3d3b in sleep () from /lib/libc.so.6 > #3 0x080486b6 in thread1 () > #4 0x00db440b in start_thread () from /lib/libpthread.so.0 > #5 0x00ce1b7e in clone () from /lib/libc.so.6 > Thread 1 (Thread -1209071296 (LWP 8297)): > #0 0x00bfb402 in __kernel_vsyscall () > #1 0x00ca3f16 in __nanosleep_nocancel () from /lib/libc.so.6 > #2 0x00ca3d3b in sleep () from /lib/libc.so.6 > #3 0x08048893 in main () > > > The second one is found while I am playing with Tromey's fdtrace: > > # ./frysk/bindir/fdtrace /home/woodzltc/fdtrace/Closer2 > bad close() call at: > val = 0; in function: null ( at line 0) > val = 134513583; in function: doit2 (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 9) > val = 134513607; in function: main (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 13) > val = 12773156; in function: __libc_start_main (Unknown file at line 0) > val = 134513409; in function: _start (Unknown file at line 0) > bad close() call at: > val = 0; in function: null ( at line 0) > val = 134513583; in function: doit2 (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 9) > val = 134513607; in function: main (/home/woodzltc/AboutFrame/libunwind/fdtrace/Closer2.c at line 13) > val = 12773156; in function: __libc_start_main (Unknown file at line 0) > val = 134513409; in function: _start (Unknown file at line 0) > > The address of the first frame seems to be 0, and "doit()" and "close()" was swallowed as well. > > Anyone noticed these problems before? Is there any work to make improvement on this? > Yup, I noticed it yesterday as well. However, Alex still has some pending patches to go into libunwind. When those get in we'll take a closer look at this... need to fix one problem at a time. > > BTW, I also have one observation that libunwind has only two test cases for remote unwinding. That > is far from enough, IMO. Stack unwind has quite some different scenarios, especially in remote > unwind. We will have no way to be sure how it works in these scenario, if we have not test them. > So I predict there are yet some other problems some where we didn't noticed. > > My two cents is we need to write much more cases to evaluate how libunwind works in various > scenarios: single thread and multi-threads, normal operation and abnormal operation (signal frame or > exception handler or non-local jump)... It is better if we can also extract the backtrace > information from the core dumped out. You're absolutely right - the testcases are lacking. I'll beef this up when I get some time this week! - Mike From cagney@redhat.com Tue Sep 19 15:59:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 19 Sep 2006 15:59:00 -0000 Subject: agenda 2006-09-19 Message-ID: <451013ED.8070209@redhat.com> upstream kernel and utrace - roland, cmoller backtraces (libunwind, ...) - mcvet, ...? fstack - npremji 64-bit (ppc64, x86-64) - timoore, ...? breakpoints (low level, high level) - mjw, timoore disassembly display - mcvet More solid integration between dogtail and frysk - pmuldoon, ldimaggi source view, print simple variables, show inline code (use libdw) - stan, adam, rmoseley java-gnome memory smash - pmuldoon, cagney, sami? rpm updates and patch backports - kasal, cagney test coverage automation and test coverage - cagney, stan -- instruction stepping and the blocking observer - tba console window aka the CLI - requires closure terminal window aka the simple bash observer - requires closure From skasal@redhat.com Tue Sep 19 19:37:00 2006 From: skasal@redhat.com (Stepan Kasal) Date: Tue, 19 Sep 2006 19:37:00 -0000 Subject: Problems building frysk Message-ID: <20060919193707.GA15980@camelia.ucw.cz> Hello Alex, it seems that your commit to frysk-imports/lib/unwind/cni/StackTraceCreator.cxx has broken the build with -Werror. I observe the following: lib/unwind/cni/StackTraceCreator.cxx: In function 'int access_mem(unw_addr_space*, unw_word_t, unw_word_t*, int, void*)': lib/unwind/cni/StackTraceCreator.cxx:146: warning: type-punning to incomplete type might break strict-aliasing rules Could you give me any hint how could that be fixed? Thank you in advance, Stepan From pmuldoon@redhat.com Tue Sep 19 21:44:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Tue, 19 Sep 2006 21:44:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <20060919010634.GC2378@GreenHouse.cn.ibm.com> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <20060919010634.GC2378@GreenHouse.cn.ibm.com> Message-ID: <451064AA.4090800@redhat.com> > If syscall number is saved in updateSyscallEnter() in SyscallObserver, > all the classes that implement updateSyscallEnter() should be aware of > this details, and save the syscall number by themselves. It is not > good, since every time, when we implement updateSyscallEnter(), we > should save the syscall number by ourselves.(Correct me if I am wrong) > After today's discussion I tried locally caching the syscall in the updateSyscallEnter to reuse in updateSyscallExit. I did this in the ui implementation of the Sys call observer to see if we could get around concerns with how we dealt with exceptions. As it turns out, doing this in the interface won't work as SyscallEventInfo makes it own syscall "call" in: arg = syscallEventInfo.returnCode(task); where returnCode calls: public long returnCode (Task task) { return getSyscall(task).getReturnCode(task); } (Tom pointed out the above, btw, after I mentioned with even a locally cached syscall, I was still seeing the same errors.) > IMO, SyscallEventInfo is the good place to cache system call number, > and provides a method number(Task task, Boolean enterSyscall), which > return the system call number and cache it when enterSyscall is true, > while return the cached syscall number when enterSyscall is false. > The current number(Task) return system call number *always* from a > certain register. > > So unless we re-architect how syscallEventInfo works a little bit, then right now caching there is the only way I can see. Regards Phil From tromey@redhat.com Tue Sep 19 22:00:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 19 Sep 2006 22:00:00 -0000 Subject: Patch: StackFrame.toString() In-Reply-To: <1158668411.3033.12.camel@dijkstra.wildebeest.org> References: <20060911051051.GC19394@GreenHouse.cn.ibm.com> <1158668411.3033.12.camel@dijkstra.wildebeest.org> Message-ID: >>>>> "Mark" == Mark Wielaard writes: Mark> Could you provide some more info on what you Mark> are seeing. Or maybe just report a bug with the output of: Mark> ./TestRunner -c FINE frysk.proc.TestBreakpoints I updated, rebuilt, and re-ran the test suite. This time it all worked. I've appended my updated patch. * Adds toString * Removes default sourceFile * Fixes some javadoc things in StackFrame * Corrects a misspelling Ok? Tom Index: frysk-core/frysk/rt/ChangeLog from Tom Tromey * StackFrame.java (toString): New method. (StackFrame): Don't initialize sourceFile if file is not known. (startOffset): Renamed. (getStartOffset): Likewise. (setFunction): Javadoc fixes. (getFunction): Likewise. (getData): Likewise. (getMethodName): Likewise. (getSourceFile): Likewise. (getLineNumber): Likewise. (getColumn): Likewise. (getAddress): Likewise. (getMyTask): Likewise. (getUnwindData): Likewise. (getInner): Likewise. (getOuter): Likewise. (getIsSignalFrame): Likewise. Index: frysk-core/frysk/rt/StackFrame.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/rt/StackFrame.java,v retrieving revision 1.6 diff -u -r1.6 StackFrame.java --- frysk-core/frysk/rt/StackFrame.java 19 Sep 2006 14:18:00 -0000 1.6 +++ frysk-core/frysk/rt/StackFrame.java 19 Sep 2006 21:59:56 -0000 @@ -61,7 +61,7 @@ private int endLine; - private int startOffsset; + private int startOffset; private int endOffset; @@ -132,16 +132,12 @@ this.lineNum = line.getLineNum(); this.startLine = this.lineNum; this.endLine = this.lineNum; - this.startOffsset = 0; + this.startOffset = 0; this.endOffset = -1; this.sourceFile = line.getSourceFile(); this.column = line.getColumn(); } } - else - { - this.sourceFile = ""; - } } /** @@ -151,8 +147,10 @@ private native void initialize (); /** - * Sets func to the incoming DOMFunction representing the function which - * is in turn represented by this StackFrame. + * Sets the DOMFunction representing the function which is in turn + * represented by this StackFrame. This method also calls + * {@link setData} using the function's source as an argument; if + * the function does not have a source, then null is used. * * @param f The DOMFunction for this StackFrame. */ @@ -166,8 +164,8 @@ } /** - * Sets data to the incoming DOMSource, representing the source code of - * the executable. + * Sets the DOMSource, representing the source code of the + * executable. * * @param s The DOMSource for the executable this StackFrame belongs to. */ @@ -177,9 +175,10 @@ } /** - * Returns this StackFrame's function. + * Returns this StackFrame's function. If no function was + * previously set using {@link setFunction}, this will return null. * - * @return func This StackFrame's function. + * @return This StackFrame's function. */ public DOMFunction getFunction() { @@ -187,9 +186,10 @@ } /** - * Returns this StackFrame's source code. + * Returns this StackFrame's source code. If no source was + * previously set using {@link setData}, null is returned. * - * @return data This StackFrame's source code. + * @return This StackFrame's source code. */ public DOMSource getData() { @@ -197,9 +197,8 @@ } /** - * Returns this StackFrame's method name. - * - * @return methodName This StackFrame's method name. + * Return the name of the function associated with this stack frame. + * This will return null if the function's name is not known. */ public String getMethodName () { @@ -207,10 +206,8 @@ } /** - * Returns the name of the source file represented by this StackFrame - * - * @return sourceFile The name of the SourceFile represented by this - * StackFrame. + * Return the name of the source file associated with this stack + * frame. If the source file is not known, this will return null. */ public String getSourceFile () { @@ -218,9 +215,9 @@ } /** - * Returns the current line number of this StackFrame. - * - * @return lineNum The current line number of this Stackframe. + * Return the line number of the source code associated with this + * stack frame. Line numbers begin at 1. If the source line number + * is not known, this will return 0. */ public int getLineNumber () { @@ -230,7 +227,7 @@ /** * Returns the column in the currently executing line in the source file. * - * @return column The column in the currently executing source file line. + * @return The column in the currently executing source file line. */ public int getColumn () { @@ -240,7 +237,7 @@ /** * Returns the program counter for this StackFrame. * - * @return address The program counter for this StackFrame. + * @return The program counter for this StackFrame. */ public long getAddress () { @@ -250,7 +247,7 @@ /** * Returns the Task this StackFrame belongs to. * - * @return myTask The Task this StackFrame belongs to. + * @return The Task this StackFrame belongs to. */ public Task getMyTask () { @@ -260,7 +257,7 @@ /** * Returns the RawDataManaged which represents this StackFrame's cursor. * - * @return unwind_data This StackFrame's cursor. + * @return This StackFrame's cursor. */ protected RawDataManaged getUnwindData () { @@ -270,7 +267,7 @@ /** * Returns this StackFrame's inner frame. * - * @return inner This StackFrame's inner frame. + * @return This StackFrame's inner frame. */ public StackFrame getInner () { @@ -280,19 +277,52 @@ /** * Returns this StackFrame's outer frame. * - * @return outer This StackFrame's outer frame. + * @return This StackFrame's outer frame. */ public StackFrame getOuter () { return outer; } + + /** + * Return a string representation of this stack frame. + * The returned string is suitable for display to the user. + */ + public String toString () + { + StringBuffer builder = new StringBuffer("0x"); + builder.append(Long.toHexString(getAddress())); + String mn = getMethodName(); + if (mn != null && ! "".equals(mn)) + { + builder.append(" in function: "); + builder.append(getMethodName()); + } + String sf = getSourceFile(); + int line = getLineNumber(); + if (sf != null || line != 0) + { + builder.append(" ("); + if (sf != null) + builder.append(sf); + else + builder.append("Unknown source"); + if (line != 0) + { + builder.append(":"); + builder.append(line); + } + builder.append(")"); + } + return builder.toString(); + } public int getEndLine () { return endLine; } - public void setEndLine (int i ) + public void setEndLine (int i) { this.endLine = i; } @@ -312,9 +342,9 @@ this.startLine = i; } - public int getStartOffsset () + public int getStartOffset () { - return startOffsset; + return startOffset; } /** @@ -332,7 +362,7 @@ /** * Returns whether or not this frame is a signal frame. * - * @return isSignalFrame Whether or not this frame is a signal frame. + * @return Whether or not this frame is a signal frame. */ public boolean getIsSignalFrame() { Index: frysk-gui/frysk/gui/srcwin/ChangeLog from Tom Tromey * CurrentLineSection.java (startOffset): Renamed. (CurrentLineSection): Updated. (getStartOffset): Renamed. (setStartOffset): Likewise. * SourceBuffer.java (setCurrentLine): Use renamed getStartOffset. Index: frysk-gui/frysk/gui/srcwin/CurrentLineSection.java =================================================================== RCS file: /cvs/frysk/frysk-gui/frysk/gui/srcwin/CurrentLineSection.java,v retrieving revision 1.3 diff -u -r1.3 CurrentLineSection.java --- frysk-gui/frysk/gui/srcwin/CurrentLineSection.java 8 Sep 2006 18:19:36 -0000 1.3 +++ frysk-gui/frysk/gui/srcwin/CurrentLineSection.java 19 Sep 2006 21:59:57 -0000 @@ -46,7 +46,7 @@ private int endLine; - private int startOffsset; + private int startOffset; private int endOffset; @@ -59,7 +59,7 @@ { startLine = lineStart; endLine = lineEnd; - startOffsset = colStart; + startOffset = colStart; endOffset = colEnd; } @@ -113,13 +113,13 @@ this.startLine = startLine; } - public int getStartOffsset () + public int getStartOffset () { - return startOffsset; + return startOffset; } - public void setStartOffsset (int startOffsset) + public void setStartOffset (int startOffset) { - this.startOffsset = startOffsset; + this.startOffset = startOffset; } } Index: frysk-gui/frysk/gui/srcwin/SourceBuffer.java =================================================================== RCS file: /cvs/frysk/frysk-gui/frysk/gui/srcwin/SourceBuffer.java,v retrieving revision 1.69 diff -u -r1.69 SourceBuffer.java --- frysk-gui/frysk/gui/srcwin/SourceBuffer.java 18 Sep 2006 15:52:09 -0000 1.69 +++ frysk-gui/frysk/gui/srcwin/SourceBuffer.java 19 Sep 2006 21:59:57 -0000 @@ -267,7 +267,7 @@ { int startLine = frame.getStartLine(); - int startCol = frame.getStartOffsset(); + int startCol = frame.getStartOffset(); int endLine = frame.getEndLine(); int endCol = frame.getEndOffset(); From qiyaoltc@cn.ibm.com Wed Sep 20 00:59:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 20 Sep 2006 00:59:00 -0000 Subject: New build dependency audit-libs-devel In-Reply-To: <20060920003048.23815.qmail@sourceware.org> References: <20060920003048.23815.qmail@sourceware.org> Message-ID: <20060920005849.GE2378@GreenHouse.cn.ibm.com> On Wed, Sep 20, 2006 at 12:30:48AM -0000, swagiaal@sourceware.org wrote: > > 2006-09-16 > > * configure.ac: Added search for libaudit.h to insure that > libaudit-devel is installed. audit-libs-devel should be installed, otherwise fail to build like this, checking for libaudit.h... configure: error: no libaudit.h file found in /usr/include/ -- Yao Qi From zhengyo@cn.ibm.com Wed Sep 20 01:16:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 20 Sep 2006 01:16:00 -0000 Subject: [patch]why not follow CFLAGS when using $CC in some packages of frysk? In-Reply-To: <20060919132651.GA11142@camelia.ucw.cz> References: <1158669365.2684.74.camel@YZ_X86_64> <20060919132651.GA11142@camelia.ucw.cz> Message-ID: <1158715037.2684.93.camel@YZ_X86_64> On Tue, 2006-09-19 at 15:26 +0200, Stepan Kasal wrote: > Hello, > > On Tue, Sep 19, 2006 at 08:36:05PM +0800, Yong Zheng wrote: > > In frysk, no CFLAGS is followed in some packages, such as elfutils and > > libunwind, when the $(CC) is used. > > these are external packages, which we cannot directly influence. Yes, both elfutils and libunwind are upstream packages. So it may be difficult for us to inflence these two packages. :-) > > We can have local patches as a short-time solution. But it is > supposed that the patches won't accumulate, they should be pushed > upstream. Altough it's one good solution to have local patches, it may be not so preferable because nobody know whether these local patches will accumulate or not. So it seems that we have to get other ways to do this. > Sometimes there are other solutions possible though: > When building frysk for Fedora Core, I faced certain problems with > the build system of elfutils (another problem with CFLAGS). > I was not able to convince Roland (the maintainer of elfutils) to > accept a solution for the problem. It's a bad news(at least to us)! But the CFLAGS should do be referred when CC is used. If not, we have to pass CC="gcc -m64" instead of CFLAGS="-m64" to configure when we want to build 64-bit frysk. This works well now but brings some trouble to us when adding bi-arch test support for PPC64. We're not sure whether this will bring more trouble in future. > But fortunatley, the long-term > plan for frysk on Fedora Core is to use elfutils as an external > package, skipping the copy embedded in frysk---and that way my > problem with elfutils' build system will simply disappear. > (Well, I'm afraid this success story won't help you much...) Although this success story won't help us much on the problem, it's helpful for us. Thanks! we will search other ways to do this. Best regards Yong Zheng From qiyaoltc@cn.ibm.com Wed Sep 20 01:35:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 20 Sep 2006 01:35:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <451064AA.4090800@redhat.com> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <20060919010634.GC2378@GreenHouse.cn.ibm.com> <451064AA.4090800@redhat.com> Message-ID: <20060920013419.GF2378@GreenHouse.cn.ibm.com> On Tue, Sep 19, 2006 at 04:44:10PM -0500, Phil Muldoon wrote: Here is my patch to cache system call number. In this patch, 1) add a new member syscallNumber in SyscallEventInfo to cache the system call number. 2) add a new method getSyscall(Task task, boolean enterSyscall) to differentiate it is called by updateSyscallEnter or updateSyscallExit. 2006-09-20 Yao Qi * SyscallEventInfo.java (getSyscall): New abstract method. (number): New method. * LinuxEMT64.java (getSyscall): Implement this method. * LinuxIa32.java: Likewise. * LinuxPPC.java: Likewise. * LinuxPPC64.java: Likewise. * TestTaskSyscallObserver.java: Test system call number could be cached or not. Test this patch on x86/x86_64/ppc64, and this patch could also fix bug #3010. -- Yao Qi -------------- next part -------------- Index: frysk-core/frysk/proc/LinuxEMT64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxEMT64.java,v retrieving revision 1.4 diff -u -r1.4 LinuxEMT64.java --- frysk-core/frysk/proc/LinuxEMT64.java 19 Sep 2006 01:21:22 -0000 1.4 +++ frysk-core/frysk/proc/LinuxEMT64.java 20 Sep 2006 00:42:34 -0000 @@ -72,6 +72,11 @@ int number = this.number(task); return LinuxX8664Syscall.syscallByNum (task, number); } + public Syscall getSyscall(Task task, boolean enterSyscall) + { + int number = super.number(task, enterSyscall); + return LinuxX8664Syscall.syscallByNum (task, number); + } }; return info; } Index: frysk-core/frysk/proc/LinuxIa32.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxIa32.java,v retrieving revision 1.9 diff -u -r1.9 LinuxIa32.java --- frysk-core/frysk/proc/LinuxIa32.java 14 Sep 2006 05:58:58 -0000 1.9 +++ frysk-core/frysk/proc/LinuxIa32.java 20 Sep 2006 00:42:34 -0000 @@ -65,6 +65,11 @@ int number = this.number(task); return LinuxIa32Syscall.syscallByNum (task, number); } + public Syscall getSyscall (Task task, boolean enterSyscall) + { + int number = super.number(task, enterSyscall); + return LinuxIa32Syscall.syscallByNum (task, number); + } }; return info; } Index: frysk-core/frysk/proc/LinuxPPC.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC.java,v retrieving revision 1.6 diff -u -r1.6 LinuxPPC.java --- frysk-core/frysk/proc/LinuxPPC.java 19 Sep 2006 01:21:22 -0000 1.6 +++ frysk-core/frysk/proc/LinuxPPC.java 20 Sep 2006 00:42:34 -0000 @@ -41,6 +41,11 @@ int number = this.number(task); return LinuxPowerPCSyscall.syscallByNum (task, number); } + public Syscall getSyscall(Task task, boolean enterSyscall) + { + int number = super.number(task, enterSyscall); + return LinuxPowerPCSyscall.syscallByNum (task, number); + } }; return info; } Index: frysk-core/frysk/proc/LinuxPPC64.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/LinuxPPC64.java,v retrieving revision 1.6 diff -u -r1.6 LinuxPPC64.java --- frysk-core/frysk/proc/LinuxPPC64.java 19 Sep 2006 01:21:22 -0000 1.6 +++ frysk-core/frysk/proc/LinuxPPC64.java 20 Sep 2006 00:42:34 -0000 @@ -40,7 +40,11 @@ int number = this.number(task); return LinuxPowerPCSyscall.syscallByNum (task, number); } - + public Syscall getSyscall(Task task, boolean enterSyscall) + { + int number = super.number(task, enterSyscall); + return LinuxPowerPCSyscall.syscallByNum (task, number); + } }; return info; } Index: frysk-core/frysk/proc/SyscallEventInfo.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/SyscallEventInfo.java,v retrieving revision 1.5 diff -u -r1.5 SyscallEventInfo.java --- frysk-core/frysk/proc/SyscallEventInfo.java 14 Sep 2006 05:58:58 -0000 1.5 +++ frysk-core/frysk/proc/SyscallEventInfo.java 20 Sep 2006 00:42:34 -0000 @@ -48,7 +48,31 @@ public final static int EXIT = 1; public final static int UNKNOWN = -1; + int syscallNumber = -1; + + /** + * Get the system call number from a certain register + * @param task the task that system call occurred + * @return system call number + */ public abstract int number (Task task); + + /** + * When enter into a system call, get system call number from a + * certain register and cache it, while exit from system call, + * get the system call number from the cached value. + * @param task the task that system call occurred + * @param enterSyscall get system call number on the moment that + * enter or exit a system call + * @return system call number + */ + public int number (Task task, boolean enterSyscall) + { + if (enterSyscall) + syscallNumber = number (task); + + return syscallNumber; + } /** * getSyscall does everything on the assumption that there is a * system, and programmer want to know the information about this @@ -58,6 +82,13 @@ * @return the Syscall object */ public abstract Syscall getSyscall (Task task); + /** + * @param task the task that system call occurred + * @param enterSyscall enterSyscall get system call number on the moment that + * enter or exit a system call + * @return the Syscall object + */ + public abstract Syscall getSyscall (Task task, boolean enterSyscall); /** * @param task the task that system call occurred Index: frysk-core/frysk/proc/TestTaskSyscallObserver.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/proc/TestTaskSyscallObserver.java,v retrieving revision 1.16 diff -u -r1.16 TestTaskSyscallObserver.java --- frysk-core/frysk/proc/TestTaskSyscallObserver.java 7 Aug 2006 20:22:15 -0000 1.16 +++ frysk-core/frysk/proc/TestTaskSyscallObserver.java 20 Sep 2006 00:42:35 -0000 @@ -480,31 +480,33 @@ public Action updateSyscallEnter (Task task) { super.updateSyscallEnter (task); - SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task); - int syscallNum = syscallEventInfo.number (task); + frysk.proc.Syscall syscall = getSyscallEventInfo(task).getSyscall(task, true); + // verify that read attempted - if (syscallNum == SyscallNum.SYSread) { - long numberOfBytes = syscallEventInfo.arg (task, 3); + if ("read".equals(syscall.getName())) + { + long numberOfBytes = syscall.getArguments (task, 3); logger.log(Level.FINE, "{0} updateSyscallEnter READ\n", this); if (numberOfBytes != 1) throw new RuntimeException ("bytes to read not 1"); if (readEnter == 0) Manager.eventLoop.add (new PausedReadTimerEvent (task, 500)); ++readEnter; - } + } return Action.CONTINUE; } public Action updateSyscallExit (Task task) { super.updateSyscallExit (task); - SyscallEventInfo syscallEventInfo = getSyscallEventInfo(task); - int syscallNum = syscallEventInfo.number (task); - if (syscallNum == SyscallNum.SYSread) { + frysk.proc.Syscall syscall = getSyscallEventInfo(task).getSyscall(task, false); + + if ("read".equals(syscall.getName())) + { logger.log(Level.FINE, "{0} updateSyscallExit READ\n", this); if (readEnter <= readExit) throw new RuntimeException ("Read exit before enter"); ++readExit; - } + } return Action.CONTINUE; } public Action updateSignaled (Task task, int sig) From woodzltc@cn.ibm.com Wed Sep 20 03:34:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Wed, 20 Sep 2006 03:34:00 -0000 Subject: agenda 2006-09-19 In-Reply-To: <451013ED.8070209@redhat.com> References: <451013ED.8070209@redhat.com> Message-ID: <4510B6D1.7080706@cn.ibm.com> Andrew, any minutes for this meeting? (Sorry, I am asking for this again. :-) Here are some status from our side. Andrew Cagney wrote: > upstream kernel and utrace - roland, cmoller fc6 test3 can't be installed onto ppc64 at this time, we are struggling to see if we can work-around that. So we don't run any test on utrace yet. :-( If the installation of fc6 can't be fixed in a couple of days. We will switch to rawhide to do the test. > backtraces (libunwind, ...) - mcvet, ...? Corey Ashford are porting libunwind to ppc64. I also run some tests with the latest libunwind code, Alex's patch can fix quite some questions. That is great! > fstack - npremji what is fstack supposed to do? something like pstack? If it is, this can be also taken as a test sceanrio for libunwind. :-) > 64-bit (ppc64, x86-64) - timoore, ...? Yao and Yong are working on some aspects of this. Yong encountered some problems when adding bi-arch support for the testsuite. Wish we can resolve that soon. > breakpoints (low level, high level) - mjw, timoore > disassembly display - mcvet Yao did some work in this aspect and posted a patch. And he found later that mcvet are working on this too and checked in something similar. Yao is a little frustrated to see this. We might need to find ways to eliminate this kind of duplicate work. to make Yao happy.... :-) Besides these, we also did some hacking here and there, randonmly. Yao's syscall patch make ftrace works basicly ok on x86_64 and ppc64, on 64-bit binary. > More solid integration between dogtail and frysk - pmuldoon, ldimaggi > source view, print simple variables, show inline code (use libdw) - > stan, adam, rmoseley > java-gnome memory smash - pmuldoon, cagney, sami? > rpm updates and patch backports - kasal, cagney > test coverage automation and test coverage - cagney, stan > > -- > > instruction stepping and the blocking observer - tba > console window aka the CLI - requires closure > terminal window aka the simple bash observer - requires closure > > From aoliva@redhat.com Wed Sep 20 03:54:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 20 Sep 2006 03:54:00 -0000 Subject: implement backtraces for AMD64 In-Reply-To: <20060918033736.GA2378@GreenHouse.cn.ibm.com> (Yao Qi's message of "Mon, 18 Sep 2006 11:37:38 +0800") References: <20060918033736.GA2378@GreenHouse.cn.ibm.com> Message-ID: On Sep 18, 2006, Yao Qi wrote: > I have added a method toString() in Isa to return Isa name, but I did > not check it in. If you think it is needed, I will code a patch for > it. > Personally, I think Isa.toString is useful. Yes, that would be nice. > There has been a factory for Isa, > frysk-core/frysk/proc/IsaFacotry.java, and this factory gets machine > type from ELF file, /proc//exe. Yep. > It is fine to me to add a register factory for libunwind. I'd love that, but I'm not the one making decisions, so don't get the impression that my interest would necessarily lead to patch approval. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Wed Sep 20 04:01:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 20 Sep 2006 04:01:00 -0000 Subject: Frysk minutes 20060905 In-Reply-To: <44FE4F18.5050506@redhat.com> (Andrew Cagney's message of "Wed, 06 Sep 2006 00:31:20 -0400") References: <17661.51678.659095.25687@localhost.redhat.com> <44FE4885.9030303@cn.ibm.com> <44FE4F18.5050506@redhat.com> Message-ID: On Sep 6, 2006, Andrew Cagney wrote: > Wu Zhou wrote: >> >>> libunwind: please test Alex patches. Andrew: to review. We can start >>> plug it into the sourcewindow, in the space reserved for it already. >>> The patches from Alex are not checked in yet. Please review and check >>> in asap. >> >> We had a test. TestStackBacktrace works ok with this patch applied. >> But we have a concern that frysk-sys are using some synchronization >> mechanism to handle ptrace requests. This patch use ptrace >> directly. Is it possible some synchroinization problem might be >> introduced in? >> > Wu, good catch. Yes, the backtrace code cannot call ptrace directory; > it will not work. All ptrace calls must be routed through the ptrace > thread that Mike added. Just for the record (I hadn't read this before, and I'm not sure I've already clarified it), nothing in the backtrace code calls ptrace directly. We're only using part of the libunwind-ptrace interface, and that's the part that interfaces with files et al. All of the callbacks that actually issue ptrace calls are implemented entirely in frysk, so even when the libunwind-ptrace callbacks need to read registers or memory from remote processes, they go through frysk's callbacks to do so, getting correct synchronization. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Wed Sep 20 04:11:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 20 Sep 2006 04:11:00 -0000 Subject: Problems building frysk In-Reply-To: <20060919193707.GA15980@camelia.ucw.cz> (Stepan Kasal's message of "Tue, 19 Sep 2006 21:37:07 +0200") References: <20060919193707.GA15980@camelia.ucw.cz> Message-ID: On Sep 19, 2006, Stepan Kasal wrote: > it seems that your commit to > frysk-imports/lib/unwind/cni/StackTraceCreator.cxx > has broken the build with -Werror. Odd, I don't even get a warning. Not even with -W -Wall... What compiler are you using? I'm on FC6T3+ (tracking rawhide) x86_64. > lib/unwind/cni/StackTraceCreator.cxx:146: warning: type-punning to incomplete type might break strict-aliasing rules > Could you give me any hint how could that be fixed? The canonical way to work around this error, when you know what you're doing, is to add a cast to (void*) between the final cast and the expression. In this case, it is safe, because the pointer is only dereferenced after it is cast back to the original type. A comment to this effect would probably be a good thing. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Wed Sep 20 04:13:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 20 Sep 2006 04:13:00 -0000 Subject: remote unwinding of libunwind In-Reply-To: <450FD0D2.5000703@cn.ibm.com> (Wu Zhou's message of "Tue, 19 Sep 2006 19:13:22 +0800") References: <450FD0D2.5000703@cn.ibm.com> Message-ID: On Sep 19, 2006, Wu Zhou wrote: > The address of the first frame seems to be 0, and "doit()" and "close()" was swallowed as well. > Anyone noticed these problems before? Is there any work to make improvement on this? The patch I posted the other day, for VDSO support, and that I've just checked in, should fix both of these problems. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From qiyaoltc@cn.ibm.com Wed Sep 20 05:47:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 20 Sep 2006 05:47:00 -0000 Subject: No audit-libs-devel-1.1.5-1.ppc64.rpm for FC5 Message-ID: <20060920054548.GG2378@GreenHouse.cn.ibm.com> Hi, Stepan, As Sami check his patch in, libaudit.a is needed to build frysk. audit-libs-devel 64-bit package could be found on FC6Test3 and rawhide, except FC5. Could you help to add these related packages to FC5? Thanks! -- Yao Qi From qiyaoltc@cn.ibm.com Wed Sep 20 10:11:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 20 Sep 2006 10:11:00 -0000 Subject: Check null pointer in DisassemblyWindow Message-ID: <20060920101020.GH2378@GreenHouse.cn.ibm.com> There are some null pointer exceptions when I open DisassemblyWindow, and I code a small patch to fix this problem. I am not good at these classes in java-gnome, so I am not sure this patch could fix all npe or not in DisassemblyWindow. 2006-09-20 Yao Qi * disassembler/DisassemblyWindow.java: Check null pointer before use it. After this patch applied, no npe any more, but I am still confused that the output in disassembly window are *almost* "nop". I suspect that the output in DisassemblyWindow is not right, and additional test case for disassembly is needed. Check it in. -- Yao Qi -------------- next part -------------- Index: frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java =================================================================== RCS file: /cvs/frysk/frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java,v retrieving revision 1.2 diff -u -r1.2 DisassemblyWindow.java --- frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java 16 Sep 2006 18:25:47 -0000 1.2 +++ frysk-gui/frysk/gui/disassembler/DisassemblyWindow.java 20 Sep 2006 08:32:25 -0000 @@ -366,13 +366,11 @@ TreeIter iter = model.getFirstIter(); while (iter != null) - { - - model.setValue(iter, (DataColumnString) cols[1], ": "); - + { if (ins != null) { + model.setValue(iter, (DataColumnString) cols[1], ": "); model.setValue(iter, (DataColumnString) cols[0], Long.toHexString(ins.address)); model.setValue(iter, (DataColumnString) cols[2], ins.instruction); if (li.hasNext()) From mark@klomp.org Wed Sep 20 10:13:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Wed, 20 Sep 2006 10:13:00 -0000 Subject: Patch: StackFrame.toString() In-Reply-To: References: <20060911051051.GC19394@GreenHouse.cn.ibm.com> <1158668411.3033.12.camel@dijkstra.wildebeest.org> Message-ID: <1158747190.3019.3.camel@dijkstra.wildebeest.org> Hi Tom, On Tue, 2006-09-19 at 15:53 -0600, Tom Tromey wrote: > >>>>> "Mark" == Mark Wielaard writes: > > Mark> Could you provide some more info on what you > Mark> are seeing. Or maybe just report a bug with the output of: > Mark> ./TestRunner -c FINE frysk.proc.TestBreakpoints > > I updated, rebuilt, and re-ran the test suite. > This time it all worked. Phew. Good to hear. > I've appended my updated patch. > > * Adds toString > * Removes default sourceFile > * Fixes some javadoc things in StackFrame > * Corrects a misspelling > > Ok? This looks good to me. Thanks. Cheers, Mark From kasal@ucw.cz Wed Sep 20 10:38:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Wed, 20 Sep 2006 10:38:00 -0000 Subject: Trackers in bugzilla Message-ID: <20060920103759.GA26298@camelia.ucw.cz> Hello, I noticed that the tracker bugs in sourceware bugzilla (listed on bugzilla/index.html) are not all in the same state: 1) some of them are RESOLVED WONTFIX 2) some RESOLVED FIXED 3) some NEW Do I gather correctly that RESOLVED WONTFIX is the correct state? Stepan From zhengyo@cn.ibm.com Wed Sep 20 11:47:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 20 Sep 2006 11:47:00 -0000 Subject: Two patches to add bi-arch test in frysk. In-Reply-To: <1158667632.2684.46.camel@YZ_X86_64> References: <1158131338.3390.103.camel@YZ_X86_64> <450847C0.3050900@redhat.com> <1158667632.2684.46.camel@YZ_X86_64> Message-ID: <1158752894.2684.162.camel@YZ_X86_64> On Tue, 2006-09-19 at 20:07 +0800, Yong Zheng wrote: > On Wed, 2006-09-13 at 14:02 -0400, Andrew Cagney wrote: > > The patches to add bi-arch test in frysk is blocking by some problems > found in PPC64. After we do some modifications on the patches, we will > post them out again. Sorry for that! Based on the previous two patches post, we do some modifications and now post out the latest patches to add bi-arch test in frysk. The main modifications are focused on how to filter the "-m64" option in PPC64. Our first try is to intent to specify "-m64" as CFLAGS and then filter it when compiling and linking but fail. The second try is to filter the COMPILE and LINK which carry "-m64" in PPC64. It's just for this that we have to generate all rules for arch32 target in Makefile.gen.sh. Please review the attached patches for details. Now, the patches work well in X86/X86_64/PPC64 based on the cvs head(09-20). But it has the following disadvantages: After applying the pathes, automake will generate some garbage rules in Makefile.in, which will be commented in Makefile on X86_64/PPC64 but will be passed into Makefile in X86 after running configure script. Of course, the garbage rules will influence nothing. After applying the patches and building frysk, you can run the following command to do bi-arch test(in fact, it's just do arch 32 test on X86_64/PPC64 now): ./TestRunner --help # output the usage info of TestRunner ./TestRunner # do what it used to do ./TestRunner --arch=<64|32> # run the 64-bit or 32-bit cases. After you install the frysk, you can run the test through funit with the similar commands as the above. 2006-09-20 Yong Zheng * common/acinclude.m4: Call FRYSK_DO_BIARCH_TEST. * common/Makefile.gen.sh: (echo_biarch_PROGRAMS): Output of rules for bi-arch test. * common/Makefile.rules (pkglibexec_biarch_PROGRAMS, pkglibexec_biarchdir): Define. * common/TestRunner.javain: Refactor to suport bi-arch test. * common/m4/frysk-do-biarch-test.m4: New file, defines FRYSK_DO_BIARCH_TEST. * frysk-imports/frysk/Config.javain (PKGLIBEXEC_BIARCHDIR): Add. * frysk-core/frysk/pkglibexecdir/funit.java (main): Add support for bi-arch test. * frysk-imports/frysk/ju0nit/Runner.java (repeatValue, justBiarchTest, includingBiarchTest, testCases, parser): New. (usage): New method. (setTestCases, GetTestCases): New methods. (setBuildArch, GetBuildArch): New methods. (runArchCases): New method. (runArch32Cases): New method. (Runner): Refactor to support bi-arch test. * frysk-core/Makefile.am: Add rules for funit-child-alias. * frysk-core/frysk/pkglibexecdir/funit.xml: Update the --arch option info. Please reivew. And any comments are welcome! ok to commit? Best regards Yong Zheng -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-common-for-biarch.patch Type: text/x-patch Size: 8406 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frysk-supplement-for-biarch.patch Type: text/x-patch Size: 18925 bytes Desc: not available URL: From rmoseley@redhat.com Wed Sep 20 12:15:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Wed, 20 Sep 2006 12:15:00 -0000 Subject: agenda 2006-09-19 In-Reply-To: <4510B6D1.7080706@cn.ibm.com> References: <451013ED.8070209@redhat.com> <4510B6D1.7080706@cn.ibm.com> Message-ID: <451130F1.8000200@redhat.com> Wu Zhou wrote: > Andrew, any minutes for this meeting? (Sorry, I am asking for this > again. :-) > > Here are some status from our side. > > Andrew Cagney wrote: >> upstream kernel and utrace - roland, cmoller > fc6 test3 can't be installed onto ppc64 at this time, we are > struggling to see if we can work-around that. So we don't run any > test on utrace yet. :-( > If the installation of fc6 can't be fixed in a couple of days. We > will switch to rawhide to do the test. Hmmmm. Interesting, I cannot install fc6 test3 on the x86_64(frysk.boston) machine that Elena sent to Huntsville. I tried installing via CD and installing via the network and no go either way. It stalled every time when trying to format the root ("/") partition. I tried setting up the partitions myself and also let it try to install the partitions itself, but no go. :( > > >> backtraces (libunwind, ...) - mcvet, ...? > Corey Ashford are porting libunwind to ppc64. I also run some tests > with the latest libunwind code, Alex's patch can fix quite some > questions. That is great! > >> fstack - npremji > what is fstack supposed to do? something like pstack? If it is, this > can be also taken as a test sceanrio for libunwind. :-) > >> 64-bit (ppc64, x86-64) - timoore, ...? > Yao and Yong are working on some aspects of this. Yong encountered > some problems when adding bi-arch support for the testsuite. Wish we > can resolve that soon. > >> breakpoints (low level, high level) - mjw, timoore >> disassembly display - mcvet > Yao did some work in this aspect and posted a patch. And he found > later that mcvet are working on this too and checked in something > similar. Yao is a little frustrated to see this. We might need to > find ways to eliminate this kind of duplicate work. to make Yao > happy.... :-) > > Besides these, we also did some hacking here and there, randonmly. > Yao's syscall patch make ftrace works basicly ok on x86_64 and ppc64, > on 64-bit binary. > >> More solid integration between dogtail and frysk - pmuldoon, ldimaggi >> source view, print simple variables, show inline code (use libdw) - >> stan, adam, rmoseley >> java-gnome memory smash - pmuldoon, cagney, sami? >> rpm updates and patch backports - kasal, cagney >> test coverage automation and test coverage - cagney, stan >> >> -- >> >> instruction stepping and the blocking observer - tba >> console window aka the CLI - requires closure >> terminal window aka the simple bash observer - requires closure >> >> From skasal@redhat.com Wed Sep 20 13:40:00 2006 From: skasal@redhat.com (Stepan Kasal) Date: Wed, 20 Sep 2006 13:40:00 -0000 Subject: Add audit-libs-devel-*.ppc64.rpm to FC5 Updates Message-ID: <20060920134042.GA28431@camelia.ucw.cz> Hello, a user has reported that though the FC 5 for ppc contains audit-libs-1.1.5-1.ppc64.rpm, it does not contain the corresponding -devel rpm. I noticed that there are packages audit-1.2.7-{2,3}.fc5 in core/updates/testing/5/ but neither of them contains the devel ppc64 rpm. Would it be possible to push the file audit-libs-devel-1.2.7-3.fc5.ppc64.rpm to the ftp server? Thanks in advance, Stepan From kasal@ucw.cz Wed Sep 20 14:05:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Wed, 20 Sep 2006 14:05:00 -0000 Subject: No audit-libs-devel-1.1.5-1.ppc64.rpm for FC5 In-Reply-To: <20060920054548.GG2378@GreenHouse.cn.ibm.com> References: <20060920054548.GG2378@GreenHouse.cn.ibm.com> Message-ID: <20060920140455.GA28716@camelia.ucw.cz> Hello, On Wed, Sep 20, 2006 at 01:45:50PM +0800, Yao Qi wrote: > audit-libs-devel 64-bit package could be found on FC6Test3 and > rawhide, except FC5. > > Could you help to add these related packages to FC5? Thanks! I asked the release engineering team to do that. (CC went to this list.) Morover, I placed the missing rpms here: http://www.ucw.cz/~kasal/audit-libs-devel-1.1.5-1.ppc64.rpm http://www.ucw.cz/~kasal/audit-libs-devel-1.2.7-3.fc5.ppc64.rpm e97d6efdef9a0a9bba10f731017a4715 audit-libs-devel-1.1.5-1.ppc64.rpm 0cec61163701de2ec40f398bb71f2c7d audit-libs-devel-1.2.7-3.fc5.ppc64.rpm (The 1.2.7-3.fc5 version matches the version from .../core/updates/testing/5/ppc which may eventually get to FC5 Updates.) Have a nice day, Stepan Kasal From pmuldoon@redhat.com Wed Sep 20 14:09:00 2006 From: pmuldoon@redhat.com (Phil Muldoon) Date: Wed, 20 Sep 2006 14:09:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <20060920013419.GF2378@GreenHouse.cn.ibm.com> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <20060919010634.GC2378@GreenHouse.cn.ibm.com> <451064AA.4090800@redhat.com> <20060920013419.GF2378@GreenHouse.cn.ibm.com> Message-ID: <45114B95.3050406@redhat.com> Yao Qi wrote: > On Tue, Sep 19, 2006 at 04:44:10PM -0500, Phil Muldoon wrote: > > Here is my patch to cache system call number. > > In this patch, > 1) add a new member syscallNumber in SyscallEventInfo to > cache the system call number. > 2) add a new method getSyscall(Task task, boolean enterSyscall) to > differentiate it is called by updateSyscallEnter or updateSyscallExit. > +1. The patch looks good to me Regards Phil From scox@redhat.com Wed Sep 20 15:46:00 2006 From: scox@redhat.com (Stan Cox) Date: Wed, 20 Sep 2006 15:46:00 -0000 Subject: minutes 2006-09-19 In-Reply-To: <451130F1.8000200@redhat.com> References: <451013ED.8070209@redhat.com> <4510B6D1.7080706@cn.ibm.com> <451130F1.8000200@redhat.com> Message-ID: <1158767137.10612.550.camel@multics.rdu.redhat.com> Utrace (Chris ) -ptrace on utrace behavior appears to be different than original utrace -If a kill fails then the next ptrace operation is ignored (#203385?) -Thread/Process status when a process clones and then later kills the clone (#?) -Action: Get the C version of the test for 203385 written and committed Backtrace (Mike ) -Most of Alex's patches committed -Source display for previous stack frames works -Action: Investigate the lost frames in backtraces (+cagney) Fstack (Nurdin ) -What is the correct way to handle stack backtracing? Perhaps use the cascading observer model which simplifies iterating through stack frames. -Action: Work out multi-threaded fstack (+pmuldoon) -Action: Investigate the gdb pstack bug (+cagney) 64 bit (Tim ) -32 on 64 bit is mostly done -Adding automatic build 32 on 64 testing -IBM supplied some of the 32 on 64 testing framework infrastructure -ppc executables default to 32 bit to save cache space due to the large register set. -Resolved modulo status of the testsuite Breakpoint (Mark ) -Three steps needed for high level single threaded breakpoints: 1. single instruction stepping 2. address information for file/line 3. stack frame information -Multithreading breakpoint support more difficult (Cagney) -Action: Con call high-level breakpoints (+mjw, +cagney as needed) Disassemble (Mike ) -Single threaded case mostly done -Need to define semantics for multiple threaded case, which currently blocks the main thread -Mostly resolved. This topic can probably transition to handling multi threaded displays Testing & Dogtail (Phil ) -Demo by Len -Is current state okay for the testing framework? -Memory smashing bug has proved elusive. -Seems related to cleanup in java gnome -Tom Tromey's suggestion for two different objects to handle enter/exit may simplify handling complicated cases) -Status needed on dogtail, memory smashing bug, Tom's suggestion -Action: Is dogtail okay for the testing framework (+ldimaggio) -Action: Beat the Java-GNOME memory smash to death (+cagney) Source (Stan , Rick ) -Simple variables for current frame now handled. -Looking at prior frames support with libunwind. -Looking at gui integration -Action: Con call on variables in source window Coverage (Stan, Andrew) -Investigate infrastructure changes needed to support gcov Misc -Investigate vte bug which causes intermittent console window problem (Andrew?) -Come up with workflows for terminal window (Phil?) -Chris problems with demise of cipe -Action: Get closure on the console (cagney) -Action: cipe/vpn solution (moller, cagney) From tromey@redhat.com Wed Sep 20 20:09:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Wed, 20 Sep 2006 20:09:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <20060920013419.GF2378@GreenHouse.cn.ibm.com> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <20060919010634.GC2378@GreenHouse.cn.ibm.com> <451064AA.4090800@redhat.com> <20060920013419.GF2378@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: Yao> 1) add a new member syscallNumber in SyscallEventInfo to Yao> cache the system call number. Yao> 2) add a new method getSyscall(Task task, boolean enterSyscall) to Yao> differentiate it is called by updateSyscallEnter or updateSyscallExit. This strikes me as an awkward API. Wouldn't user code see this same bug if it called the new getSyscall only in the exit handler? I think there are 2 potential solutions that would yield a nicer user experience. First, and simplest, just require the system call number to be discovered when the SyscallEventInfo object is created. E.g.: private final syscallNumber; protected SyscallEventInfo(Task task) { syscallNumber = number(task); } ... then make other needed changes like updating subclass constructors, making 'number' protected, adding a new accessor for users, etc. Or instead of caching the number you could look up and cache the actual Syscall object; same difference. This plan only works if a SyscallEventInfo is created when a syscall is entered, otherwise the lookups won't work. If that isn't always the case, or if the cost of this lookup is too high, then another plan would be to have two kinds of SyscallEventInfo objects -- one used on entry and one on exit. This seems a bit tricky since getReturnCode relies on getting the syscall number, at the moment. What do you think of this? Tom From scox@redhat.com Wed Sep 20 20:54:00 2006 From: scox@redhat.com (Stan Cox) Date: Wed, 20 Sep 2006 20:54:00 -0000 Subject: frysk.lang data structures Message-ID: <1158785623.10612.564.camel@multics.rdu.redhat.com> I'm looking at the frysk-core/frysk/lang support while I'm looking at libunwind support for expressions and trying to visualize how to link the data structures (assuming fortran like nested functions as opposed to trampolines) e.g. func1 (int c, int d) {} func2 (int e, int f) { func3 (int g, int h) {func1(g,h);} /* nested function */ func3 (e,f) } main (char [] args) { {int x,y; {int a,b; /* nested lexical block */ a=x;b=y; func2(a,b); }}} Given the pseudo data structures below, how are Frame.outer, Frame.inner, Subprogram.outer, and LexicalBlock.outer used? e.g. 1. What do {mainFrame,func2,func3,func1}.outer/inner point to? 2. Does mainSubprogram.block point to the int a,b block and that block points to the int x,y block via outer? 3. How should we show that func3 is nested within func2? Thread.task=main Thread.innerMostFrame=mainFrame main_Frame.subprogram=main_Subprogram main_Frame.outer= main_Frame.inner= main_Subprogram.outer= main_Subprogram.block=main_InnerLexicalBlock main_Subprogram.parameters=args main_LexicalBlock.outer=null main_LexicalBlock.variables=x,y main_InnerLexicalBlock.outer=main_LexicalBlock main_InnerLexicalBlock.variables=a,b func2_Frame.subprogram=func2_Subprogram func2_Frame.outer= func2_Frame.inner= func2_Subprogram.outer= func2_Subprogram.block=func2_LexicalBlock func2_Subprogram.parameters=e,f func2_LexicalBlock.outer=null func2_LexicalBlock.variables=null func3_Frame.subprogram=func3_Subprogram func3_Frame.outer= func3_Frame.inner= func3_Subprogram.outer= func3_Subprogram.block=func3_LexicalBlock func3_Subprogram.parameters=g,h func3_LexicalBlock.outer=null func3_LexicalBlock.variables=null func1_Frame.subprogram=func1_Subprogram func1_Frame.outer= func1_Frame.inner= func1_Subprogram.outer= func1_Subprogram.block=func1_LexicalBlock func1_Subprogram.parameters=c,d func1_LexicalBlock.outer=null func1_LexicalBlock.variables=null From zhengyo@cn.ibm.com Wed Sep 20 23:39:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 20 Sep 2006 23:39:00 -0000 Subject: No audit-libs-devel-1.1.5-1.ppc64.rpm for FC5 In-Reply-To: <20060920140455.GA28716@camelia.ucw.cz> References: <20060920054548.GG2378@GreenHouse.cn.ibm.com> <20060920140455.GA28716@camelia.ucw.cz> Message-ID: <1158795633.2684.164.camel@YZ_X86_64> On Wed, 2006-09-20 at 16:04 +0200, Stepan Kasal wrote: > Hello, > Morover, I placed the missing rpms here: > > http://www.ucw.cz/~kasal/audit-libs-devel-1.1.5-1.ppc64.rpm > http://www.ucw.cz/~kasal/audit-libs-devel-1.2.7-3.fc5.ppc64.rpm > > e97d6efdef9a0a9bba10f731017a4715 audit-libs-devel-1.1.5-1.ppc64.rpm > 0cec61163701de2ec40f398bb71f2c7d audit-libs-devel-1.2.7-3.fc5.ppc64.rpm It's great! Now, we can build frysk on PPC64 again! Thanks! Best regards Yong Zheng From qiyaoltc@cn.ibm.com Thu Sep 21 11:27:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 21 Sep 2006 11:27:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <20060919010634.GC2378@GreenHouse.cn.ibm.com> <451064AA.4090800@redhat.com> <20060920013419.GF2378@GreenHouse.cn.ibm.com> Message-ID: <20060921112553.GA23264@GreenHouse.cn.ibm.com> On Wed, Sep 20, 2006 at 02:02:40PM -0600, Tom Tromey wrote: > >>>>> "Yao" == Yao Qi writes: > > If that isn't always the case, or if the cost of this lookup is too > high, then another plan would be to have two kinds of SyscallEventInfo > objects -- one used on entry and one on exit. This seems a bit tricky > since getReturnCode relies on getting the syscall number, at the moment. > > What do you think of this? I prefer the latter one. I still have two questions in my mind, 1) Shall we create two objects of SyscallEventInfo, or extend two new classes from SyscallEventInfo? 2) Supposing there are two objects, one is about enter a syscall and another is about exit a syscall. Does object about enter syscall cache the system call number? (I think yes) If object about enter a syscall cache the syscall number, how could it pass this system call number to the object about exit a system call? -- Yao Qi From qiyaoltc@cn.ibm.com Thu Sep 21 11:32:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 21 Sep 2006 11:32:00 -0000 Subject: agenda 2006-09-19 In-Reply-To: <451130F1.8000200@redhat.com> References: <451013ED.8070209@redhat.com> <4510B6D1.7080706@cn.ibm.com> <451130F1.8000200@redhat.com> Message-ID: <20060921113046.GB23264@GreenHouse.cn.ibm.com> On Wed, Sep 20, 2006 at 07:15:45AM -0500, Rick Moseley wrote: > Wu Zhou wrote: > >Andrew, any minutes for this meeting? (Sorry, I am asking for this > >again. :-) > > > >Here are some status from our side. > > > >Andrew Cagney wrote: > >>upstream kernel and utrace - roland, cmoller > >fc6 test3 can't be installed onto ppc64 at this time, we are > >struggling to see if we can work-around that. So we don't run any > >test on utrace yet. :-( > >If the installation of fc6 can't be fixed in a couple of days. We > >will switch to rawhide to do the test. > Hmmmm. Interesting, I cannot install fc6 test3 on the > x86_64(frysk.boston) machine that Elena sent to Huntsville. I tried > installing via CD and installing via the network and no go either way. > It stalled every time when trying to format the root ("/") partition. I > tried setting up the partitions myself and also let it try to install > the partitions itself, but no go. :( I installed FC6 Test3 on a ppc64 box for ttwwiiccee, but result is the same, kernel could not boot after installation, like this, VFS: Cannot open root device "sda3" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Open a bug in redhat bugzilla, #207462. > -- Yao Qi From qiyaoltc@cn.ibm.com Thu Sep 21 13:57:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Thu, 21 Sep 2006 13:57:00 -0000 Subject: agenda 2006-09-19 In-Reply-To: <451130F1.8000200@redhat.com> References: <451013ED.8070209@redhat.com> <4510B6D1.7080706@cn.ibm.com> <451130F1.8000200@redhat.com> Message-ID: <20060921113046.GB23264@GreenHouse.cn.ibm.com> On Wed, Sep 20, 2006 at 07:15:45AM -0500, Rick Moseley wrote: > Wu Zhou wrote: > >Andrew, any minutes for this meeting? (Sorry, I am asking for this > >again. :-) > > > >Here are some status from our side. > > > >Andrew Cagney wrote: > >>upstream kernel and utrace - roland, cmoller > >fc6 test3 can't be installed onto ppc64 at this time, we are > >struggling to see if we can work-around that. So we don't run any > >test on utrace yet. :-( > >If the installation of fc6 can't be fixed in a couple of days. We > >will switch to rawhide to do the test. > Hmmmm. Interesting, I cannot install fc6 test3 on the > x86_64(frysk.boston) machine that Elena sent to Huntsville. I tried > installing via CD and installing via the network and no go either way. > It stalled every time when trying to format the root ("/") partition. I > tried setting up the partitions myself and also let it try to install > the partitions itself, but no go. :( I installed FC6 Test3 on a ppc64 box for ttwwiiccee, but result is the same, kernel could not boot after installation, like this, VFS: Cannot open root device "sda3" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Open a bug in redhat bugzilla, #207462. > -- Yao Qi From mwielaar@redhat.com Thu Sep 21 13:59:00 2006 From: mwielaar@redhat.com (Mark Wielaard) Date: Thu, 21 Sep 2006 13:59:00 -0000 Subject: Updated LinuxX8664Syscall list and testExecSyscall mystery Message-ID: <1158847023.2992.17.camel@dijkstra.wildebeest.org> Hi, I updated the LinuxX8664Syscall list and enabled the audit test for this architecture. 2006-09-21 Mark Wielaard * LinuxX8664Syscall.java (syscallList): Updated with audit results. * TestSyscallsWithAudit.java (testLinuxEMT64): Enable test. It would be nice if we could use libaudit for generating the syscall lists at runtime. But it seems it doesn't give us the argument types. I did this because I hoped it would help me debug a test failure I am seeing: 1)testExecSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: inSyscall But why that suddenly fails is still a bit of a mystery. It used to pass and I cannot see what recently changed that could make it fail. The logic in TaskState seems flawed though. It assumes that when we get an ptrace exec event then we must be running inside a syscall. We have a couple of states for this special case. But according to my logs this is wrong. At least now I do get syscall exec enter and exit events plus an ptrace-exec-event. I don't know why this worked before. I asked on irc and it seems nobody else is seeing this failure. But if I rework the TaskState to not assume an exec event means an insyscall state transition the test works for me. I am going to clean up TaskState to not have any special exec-event TaskStates (blockedInExecSyscall) unless someone knows of a reason for keeping this. Cheers, Mark From mcvet@redhat.com Thu Sep 21 16:53:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Thu, 21 Sep 2006 16:53:00 -0000 Subject: implement backtraces for AMD64 In-Reply-To: References: Message-ID: <1158847176.16796.2.camel@towel.toronto.redhat.com> On Sun, 2006-09-17 at 04:45 -0300, Alexandre Oliva wrote: > This patch adds the missing bits to enable libunwind-based backtraces > on AMD64/EM64T. A few notes: > > - The existing IsaEMT64 is misnamed: the correct spelling is EM64T, > not EMT64. We should probably prefer the more neutral X86_64 name (as > in the ELF data structure), or favor AMD64, like I did in the new > RegisterAMD64 class (just trying to set balance ;-) > > - I'm not entirely happy with adding libunwind-specific information to > Isa, but Isa doesn't currently provide enough information to enable > some alternate implementation that would keep everything entirely > separate. If we had a method to return the Isa name or the ELF > machine type or some such, then it would be possible to turn that into > a reworked Register* factory/singleton pattern similar to that used > for Isa, all within lib/unwind. It certainly doesn't help that > lib/unwind is in frysk-imports, so it can't use anything in > frysk-core; frysk-core/rt would have to have the glue. > > Comments? Any architectural guidance? Or is this ok to install? > Please go ahead and commit your changes, thanks. - Mike From mark@klomp.org Thu Sep 21 17:33:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 21 Sep 2006 17:33:00 -0000 Subject: Refactored TaskObserver.Code Message-ID: <1158857583.2992.37.camel@dijkstra.wildebeest.org> Hi, While writing faddr (a utility to easily set lots of breakpoints on a process, more on that later) I noticed that the setup of Code TaskObservers isn't very nice if you want to set lots of similar observers. This patch refactors the Code observer so that the actual address on which it is watching is always passed as argument to the task request and when updateHit() is called. That way you can set the same observer on a group of related addresses. 2006-09-21 Mark Wielaard * BreakpointAddresses.java (addBreakpoint): Take address as argument. (removeBreakpoint): Likewise. * PendingCodeObserver.java (address): New field. * Proc.java (requestAddCodeObserver): Take address as argument. (requestDeleteCodeObserver): Likewise. * Task.java (handleAddCodeObserver): Likewise. (handleDeleteCodeObserver): Likewise. (requestAddCodeObserver): Likewise. (requestDeleteCodeObserver): Likewise. * TaskCodeObservation (address): New field. (TaskCodeObservation): Take address as argument. (handleAdd): Pass on address. (handleDelete): Likewise. * TaskObserver.java (Code.getAddress): Removed method. (updateHit): Take address as argument. * TaskState (*.handleAddCodeObserver): Handle address as argument. (*.handleDeleteCodeObserver): Likewise. * TestBreakpoints.java: Update test to pass address as argument. Test cases updated and no regressions (x86_64). Committed, Mark From cagney@redhat.com Thu Sep 21 17:38:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Thu, 21 Sep 2006 17:38:00 -0000 Subject: Refactored TaskObserver.Code In-Reply-To: <1158857583.2992.37.camel@dijkstra.wildebeest.org> References: <1158857583.2992.37.camel@dijkstra.wildebeest.org> Message-ID: <4512CD0E.6030601@redhat.com> Mark Wielaard wrote: > Hi, > > While writing faddr (a utility to easily set lots of breakpoints on a > process, more on that later) I noticed that the setup of Code > TaskObservers isn't very nice if you want to set lots of similar > observers. This patch refactors the Code observer so that the actual > address on which it is watching is always passed as argument to the task > request and when updateHit() is called. That way you can set the same > observer on a group of related addresses. > neat idea Andrew From cagney@redhat.com Fri Sep 22 01:04:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 22 Sep 2006 01:04:00 -0000 Subject: Updated LinuxX8664Syscall list and testExecSyscall mystery In-Reply-To: <1158847023.2992.17.camel@dijkstra.wildebeest.org> References: <1158847023.2992.17.camel@dijkstra.wildebeest.org> Message-ID: <4512CE06.8030303@redhat.com> Mark Wielaard wrote: > Hi, > > I updated the LinuxX8664Syscall list and enabled the audit test for this > architecture. > > 2006-09-21 Mark Wielaard > > * LinuxX8664Syscall.java (syscallList): Updated with audit results. > * TestSyscallsWithAudit.java (testLinuxEMT64): Enable test. > > It would be nice if we could use libaudit for generating the syscall > lists at runtime. But it seems it doesn't give us the argument types. > > Yes, Sami did much research before being forced to settle on this approach, the best of a number of alternatives :-) Andrew From tromey@redhat.com Fri Sep 22 09:51:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Fri, 22 Sep 2006 09:51:00 -0000 Subject: getopt note Message-ID: FYI... I checked in a refactoring to GNU Classpath's getopt code just now. This refactoring pulls the one Classpath dependency (ClasspathToolParser) out of the getopt package and it also adds support for joined short options -- the latter meaning that AFAIK this getopt is feature complete. So, a new import may be in order. Also, Classpath's getopt relies on a message bundle, which I don't think was checked in today. Without this messages won't print properly. Tom From mark@klomp.org Fri Sep 22 11:30:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 22 Sep 2006 11:30:00 -0000 Subject: Disable testThreadedBacktrace on ! ia32 Message-ID: <1158918695.3024.5.camel@dijkstra.wildebeest.org> Hi, Till we get better libunwind support the backtrace tests won't work on anything but x86. So I disabled the newly introduced test for now. 2006-09-22 Mark Wielaard (testThreadedBacktrace): Disabled. Bug #2936. I haven't yet tested the patches from Alexander. If there are specific patches that I should try out to get this enabled again please let me know. Cheers, Mark diff -u -r1.10 TestStackBacktrace.java --- frysk-core/frysk/rt/tests/TestStackBacktrace.java 21 Sep 2006 22:33:18 -0000 1.10 +++ frysk-core/frysk/rt/tests/TestStackBacktrace.java 22 Sep 2006 09:20:52 -0000 @@ -204,6 +204,13 @@ public synchronized void testThreadedBacktrace () throws TaskException { + // Backtraces only work on x86 for now. + if (MachineType.getMachineType() != MachineType.IA32) + { + brokenXXX(2936); + return; + } + AckDaemonProcess process = new AckDaemonProcess( Sig.POLL, new String[] { Build.ABS_BUILDDIR + "/frysk/pkglibexecdir/funit-rt-threader", "" From mark@klomp.org Fri Sep 22 16:47:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 22 Sep 2006 16:47:00 -0000 Subject: testExecSyscall mystery In-Reply-To: <1158847023.2992.17.camel@dijkstra.wildebeest.org> References: <1158847023.2992.17.camel@dijkstra.wildebeest.org> Message-ID: <1158924608.3024.15.camel@dijkstra.wildebeest.org> Hi, On Thu, 2006-09-21 at 15:57 +0200, Mark Wielaard wrote: > I did this because I hoped it would help me debug a test failure I am > seeing: > > 1)testExecSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: inSyscall > > But why that suddenly fails is still a bit of a mystery. It used to pass > and I cannot see what recently changed that could make it fail. The > logic in TaskState seems flawed though. It assumes that when we get an > ptrace exec event then we must be running inside a syscall. We have a > couple of states for this special case. But according to my logs this is > wrong. At least now I do get syscall exec enter and exit events plus an > ptrace-exec-event. > > I don't know why this worked before. I asked on irc and it seems nobody > else is seeing this failure. But if I rework the TaskState to not assume > an exec event means an insyscall state transition the test works for me. > I am going to clean up TaskState to not have any special exec-event > TaskStates (blockedInExecSyscall) unless someone knows of a reason for > keeping this. Tim said he is also seeing this failure. But I have not gotten much further with it. It seems it is a combination of issues. It seems the state machine can be just plain confused and start tracing syscalls with a syscall event indicating exit, which it interprets as an enter. And I do seem to get a execve syscall event, an execed event and then an execve syscall event again. While we assume execve doesn't return so we shouldn't get the second execve syscall event. I am going to focus on something else for now since my head is spinning and I am not making any real progress. If someone else is seeing the above failure and want to take a peek please do. This is now http://sourceware.org/bugzilla/show_bug.cgi?id=3244 Cheers, Mark From cagney@redhat.com Fri Sep 22 16:51:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 22 Sep 2006 16:51:00 -0000 Subject: One patch to fix the TestX8664Modify case and merge TestModify into one case. In-Reply-To: <1157352603.10315.31.camel@YZ_X86_64> References: <1157352603.10315.31.camel@YZ_X86_64> Message-ID: <4514138F.40908@redhat.com> Yong, there's nothing wrong here, and nicely done. Going forward, I'd not hold back and just commit these re-org changes that let you add the PPC64 variant of the test. Andrew Yong Zheng wrote: > hi, > > In frysk-core, there are two platform specific test cases: > TestX8664Modify.java and TestI386Modify.java. As for the > TestX8664Modify, we submitted one patch to fix the problems in it, which > can be read here: > http://sources.redhat.com/ml/frysk/2006-q3/msg00333.html. > > In this patch, all modifications mentioned above are included, and one > new PPC64 specific case TestPPC64Modify is added. Just as Andrew said, > it's better to merge all TestRegs into one case. So we do the same > to TestModify cases. > > 2006-09-04 Yong Zheng > > * frysk-core/Makefile.am: Add funit-ppc64-modify test program. > * frysk-core/frysk/proc/TestRegMemModify.java: New file to add > PPC64 specific case and merge TestModify into one case. > > * frysk-core/frysk/pkglibexecdir/funit-ppc64-modify.S: New PPC64 > specific program > * frysk-core/frysk/pkglibexecdir/funit-x8664-modify.S: Correct > the syscall number on X8664 and do some modifications to keep > synch with TestRegMemModify. > > Rebuild frysk based on the cvs head(09-04) and tested. > Please review it. And if no any objection, we will check it in later. > > Best regards > Yong Zheng > From cagney@redhat.com Fri Sep 22 16:55:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 22 Sep 2006 16:55:00 -0000 Subject: Two patches to add bi-arch test in frysk. In-Reply-To: <1158752894.2684.162.camel@YZ_X86_64> References: <1158131338.3390.103.camel@YZ_X86_64> <450847C0.3050900@redhat.com> <1158667632.2684.46.camel@YZ_X86_64> <1158752894.2684.162.camel@YZ_X86_64> Message-ID: <4514148D.5090506@redhat.com> Yong Zheng wrote: > On Tue, 2006-09-19 at 20:07 +0800, Yong Zheng wrote: > >> On Wed, 2006-09-13 at 14:02 -0400, Andrew Cagney wrote: >> >> The patches to add bi-arch test in frysk is blocking by some problems >> found in PPC64. After we do some modifications on the patches, we will >> post them out again. Sorry for that! >> > > Based on the previous two patches post, we do some modifications and now > post out the latest patches to add bi-arch test in frysk. The main > modifications are focused on how to filter the "-m64" option in PPC64. > > Our first try is to intent to specify "-m64" as CFLAGS and then filter > it when compiling and linking but fail. > > The second try is to filter the COMPILE and LINK which carry "-m64" in > PPC64. It's just for this that we have to generate all rules for arch32 > target in Makefile.gen.sh. Please review the attached patches for > details. > > Now, the patches work well in X86/X86_64/PPC64 based on the cvs > head(09-20). But it has the following disadvantages: > > After applying the pathes, automake will generate some garbage rules in > Makefile.in, which will be commented in Makefile on X86_64/PPC64 but > will be passed into Makefile in X86 after running configure script. Of > course, the garbage rules will influence nothing. > > That is ok. I can grub through the code and dig up other examples of harmless rules. Being able to specify the 32-bit tests will help us get them working. I see the man page is also updated, wicked! Thanks for this, yep ok. Andrew > After applying the patches and building frysk, you can run the following > command to do bi-arch test(in fact, it's just do arch 32 test on > X86_64/PPC64 now): > > ./TestRunner --help # output the usage info of TestRunner > ./TestRunner # do what it used to do > ./TestRunner --arch=<64|32> # run the 64-bit or 32-bit cases. > > After you install the frysk, you can run the test through funit with the > similar commands as the above. > > 2006-09-20 Yong Zheng > > * common/acinclude.m4: Call FRYSK_DO_BIARCH_TEST. > * common/Makefile.gen.sh: (echo_biarch_PROGRAMS): Output of > rules for bi-arch test. > * common/Makefile.rules (pkglibexec_biarch_PROGRAMS, > pkglibexec_biarchdir): Define. > * common/TestRunner.javain: Refactor to suport bi-arch test. > * common/m4/frysk-do-biarch-test.m4: New file, defines > FRYSK_DO_BIARCH_TEST. > > * frysk-imports/frysk/Config.javain (PKGLIBEXEC_BIARCHDIR): > Add. > * frysk-core/frysk/pkglibexecdir/funit.java (main): Add support > for bi-arch test. > * frysk-imports/frysk/ju0nit/Runner.java (repeatValue, > justBiarchTest, includingBiarchTest, testCases, parser): New. > (usage): New method. > (setTestCases, GetTestCases): New methods. > (setBuildArch, GetBuildArch): New methods. > (runArchCases): New method. > (runArch32Cases): New method. > (Runner): Refactor to support bi-arch test. > * frysk-core/Makefile.am: Add rules for funit-child-alias. > * frysk-core/frysk/pkglibexecdir/funit.xml: Update the --arch > option info. > > Please reivew. And any comments are welcome! > ok to commit? > > Best regards > Yong Zheng > From cagney@redhat.com Fri Sep 22 17:03:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 22 Sep 2006 17:03:00 -0000 Subject: testExecSyscall mystery In-Reply-To: <1158924608.3024.15.camel@dijkstra.wildebeest.org> References: <1158847023.2992.17.camel@dijkstra.wildebeest.org> <1158924608.3024.15.camel@dijkstra.wildebeest.org> Message-ID: <45141574.4090001@redhat.com> Mark Wielaard wrote: > Hi, > > On Thu, 2006-09-21 at 15:57 +0200, Mark Wielaard wrote: > >> I did this because I hoped it would help me debug a test failure I am >> seeing: >> >> 1)testExecSyscall(frysk.proc.TestTaskSyscallObserver)junit.framework.AssertionFailedError: inSyscall >> >> But why that suddenly fails is still a bit of a mystery. It used to pass >> and I cannot see what recently changed that could make it fail. The >> logic in TaskState seems flawed though. It assumes that when we get an >> ptrace exec event then we must be running inside a syscall. We have a >> couple of states for this special case. But according to my logs this is >> wrong. At least now I do get syscall exec enter and exit events plus an >> ptrace-exec-event. >> >> I don't know why this worked before. I asked on irc and it seems nobody >> else is seeing this failure. But if I rework the TaskState to not assume >> an exec event means an insyscall state transition the test works for me. >> I am going to clean up TaskState to not have any special exec-event >> TaskStates (blockedInExecSyscall) unless someone knows of a reason for >> keeping this. >> > > Tim said he is also seeing this failure. But I have not gotten much > further with it. It seems it is a combination of issues. It seems the > state machine can be just plain confused and start tracing syscalls with > a syscall event indicating exit, which it interprets as an enter. And I > do seem to get a execve syscall event, an execed event and then an > execve syscall event again. While we assume execve doesn't return so we > shouldn't get the second execve syscall event. > > I think the case you're looking at might occure when a new process is created. The sequence is something like: - requestCreateAttachedChild (observer) -> observer gets notified of child at first instruction -> add syscall observers -> state machine updated to now expect an exit from that exec it is still sitting in -> resume Andrew From cagney@redhat.com Sat Sep 23 01:30:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Sat, 23 Sep 2006 01:30:00 -0000 Subject: Trackers in bugzilla In-Reply-To: <20060920103759.GA26298@camelia.ucw.cz> References: <20060920103759.GA26298@camelia.ucw.cz> Message-ID: <45141758.2050700@redhat.com> I don't know that there really is a correct state for these. For instance: - a tracker bug covering a new task (and sub-tasks) might as well be open until the work is largely done - for closed, well fixed/wontfix are arbitrary Andrew Stepan Kasal wrote: > Hello, > I noticed that the tracker bugs in sourceware bugzilla (listed on > bugzilla/index.html) are not all in the same state: > 1) some of them are RESOLVED WONTFIX > 2) some RESOLVED FIXED > 3) some NEW > > Do I gather correctly that RESOLVED WONTFIX is the correct state? > > Stepan > From tromey@redhat.com Sun Sep 24 20:21:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Sun, 24 Sep 2006 20:21:00 -0000 Subject: Patch: signal frame handling in StackFrame Message-ID: The signal frame handling code in StackFrame looked a bit weird to me. First, 'isSignalFrame' could not possibly be set when it is used in the constructor. Second, I couldn't think of when a user of this class would want to set this field -- it seemed to me that instead this should be a construction-time-only property. So, I wrote the appended. This passes 'make check' but I don't actually know whether it is correct. Any comments? Tom Index: frysk-core/frysk/rt/ChangeLog from Tom Tromey * StackFactory.java (createStackFrame): Updated. * StackFrame.java (setIsSignalFrame): Removed. (StackFrame): Added isSignalFrame argument. Initialize isSignalFrame field. Index: frysk-core/frysk/rt/StackFactory.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/rt/StackFactory.java,v retrieving revision 1.6 diff -u -r1.6 StackFactory.java --- frysk-core/frysk/rt/StackFactory.java 19 Sep 2006 14:18:00 -0000 1.6 +++ frysk-core/frysk/rt/StackFactory.java 23 Sep 2006 01:28:06 -0000 @@ -64,10 +64,9 @@ FrameCursor currentCursor = innermost.getOuter(); while (currentCursor != null) { - StackFrame outerFrame = new StackFrame(currentCursor, task, current); - - if (currentCursor.getIsSignalFrame() == 1) - outerFrame.setIsSignalFrame(true); + StackFrame outerFrame + = new StackFrame(currentCursor, task, current, + currentCursor.getIsSignalFrame() == 1); current.outer = outerFrame; current = outerFrame; Index: frysk-core/frysk/rt/StackFrame.java =================================================================== RCS file: /cvs/frysk/frysk-core/frysk/rt/StackFrame.java,v retrieving revision 1.8 diff -u -r1.8 StackFrame.java --- frysk-core/frysk/rt/StackFrame.java 21 Sep 2006 00:12:53 -0000 1.8 +++ frysk-core/frysk/rt/StackFrame.java 23 Sep 2006 01:28:07 -0000 @@ -92,7 +92,7 @@ */ public StackFrame (FrameCursor current, Task myTask) { - this(current, myTask, null); + this(current, myTask, null, false); } /** @@ -106,13 +106,16 @@ * @param current The FrameCursor representing the current frame. * @param myTask The Task this StackFrame belongs to. * @param inner This StackFrame's inner StackFrame. + * @param isSignalFrame true if the frame is a signal frame */ - public StackFrame (FrameCursor current, Task myTask, StackFrame inner) + public StackFrame (FrameCursor current, Task myTask, StackFrame inner, + boolean isSignalFrame) { this.myTask = myTask; unwind_data = current.getNativeCursor(); initialize(); this.inner = inner; + this.isSignalFrame = isSignalFrame; if (address != 0) /* We were able to pull information from this cursor */ { @@ -362,18 +365,6 @@ } /** - * Sets whether or not this frame is a signal frame - meaning it has been - * sent an interrupt, and we should not decrement its address when trying - * to get its line number from the Dwfl object. - * - * @param sigFrame Whether or not this frame is a 'signal frame.' - */ - public void setIsSignalFrame(boolean sigFrame) - { - this.isSignalFrame = sigFrame; - } - - /** * Returns whether or not this frame is a signal frame. * * @return Whether or not this frame is a signal frame. From timoore@redhat.com Sun Sep 24 21:25:00 2006 From: timoore@redhat.com (Tim Moore) Date: Sun, 24 Sep 2006 21:25:00 -0000 Subject: Enable testGetLine except X86_64 In-Reply-To: <1158667656.3033.7.camel@dijkstra.wildebeest.org> References: <20060919034729.GD2378@GreenHouse.cn.ibm.com> <1158667656.3033.7.camel@dijkstra.wildebeest.org> Message-ID: <4516E8BA.3090907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Wielaard wrote: > Hi, > > On Tue, 2006-09-19 at 11:47 +0800, Yao Qi wrote: >> In bug #2965, Tim reported that this case failed on X8664, but this >> case works on x86 and ppc64. I code a patch to run this case >> except on X86_64. > > The test case does work for me on x86_64. I don't know why it is failing > for Tim, maybe a different compiler that puts a different line number in > the debug info? I'm in the habit of compiling with CGJFLAGS='-g', with the same for the other compiler flags as well, in an effort to improve debuggability; I've assumed that's why I see different line numbers in these tests. Tim > > I simplified the testcase a little so all architectures should report > the same line number as follows: > > 2006-09-19 Mark Wielaard > > * tests/cni/TestLib.cxx (getFuncAddr): Extract define out of > function and put whole definition on one line. > * tests/TestDwfl.java (testGetLine): Use same line number for all > architectures. > > This way the compiler has no choice but to say the function definition > is on line 58. Committed. Please let me know if it still fails > somewhere. > > Cheers, > > Mark > > > ------------------------------------------------------------------------ > > Index: frysk-imports/lib/dw/tests/TestDwfl.java > =================================================================== > RCS file: /cvs/frysk/frysk-imports/lib/dw/tests/TestDwfl.java,v > retrieving revision 1.15 > diff -u -r1.15 TestDwfl.java > --- frysk-imports/lib/dw/tests/TestDwfl.java 19 Sep 2006 03:40:51 -0000 1.15 > +++ frysk-imports/lib/dw/tests/TestDwfl.java 19 Sep 2006 12:00:35 -0000 > @@ -46,16 +46,11 @@ > import lib.dw.DwflDieBias; > import lib.dw.DwflLine; > > -import frysk.imports.Build; > - > public class TestDwfl > extends TestCase > { > public void testGetLine () > { > - if (brokenX8664XXX(2965)) > - return; > - > Dwfl dwfl = new Dwfl(TestLib.getPid()); > assertNotNull(dwfl); > DwflLine line = dwfl.getSourceLine(TestLib.getFuncAddr()); > @@ -64,12 +59,7 @@ > assertEquals("TestLib.cxx", > filename.substring(filename.lastIndexOf("/") + 1)); > > - if(Build.BUILD_ARCH.indexOf("x86_64") != -1) > - assertEquals(55, line.getLineNum()); > - else if (Build.BUILD_ARCH.indexOf("powerpc64") != -1) > - assertEquals(51, line.getLineNum()); > - else > - assertEquals(51, line.getLineNum()); > + assertEquals(58, line.getLineNum()); > > assertEquals(0, line.getColumn()); > } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFFui6eDhWHdXrDRURAhMOAKCWsacwyJsoStN4fibjcUqHqziNrQCeLDiX r/BECcN1Gix4itOnSEBpjv0= =ekw5 -----END PGP SIGNATURE----- From tromey@redhat.com Mon Sep 25 05:25:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 25 Sep 2006 05:25:00 -0000 Subject: System call number cached with help from SyscallObserver In-Reply-To: <20060921112553.GA23264@GreenHouse.cn.ibm.com> References: <20060915070503.GD14319@GreenHouse.cn.ibm.com> <1158320877.3009.41.camel@dijkstra.wildebeest.org> <20060919010634.GC2378@GreenHouse.cn.ibm.com> <451064AA.4090800@redhat.com> <20060920013419.GF2378@GreenHouse.cn.ibm.com> <20060921112553.GA23264@GreenHouse.cn.ibm.com> Message-ID: >>>>> "Yao" == Yao Qi writes: Yao> 1) Shall we create two objects of SyscallEventInfo, or extend two new Yao> classes from SyscallEventInfo? Good question. Yao> 2) Supposing there are two objects, one is about enter a syscall and Yao> another is about exit a syscall. Does object about enter syscall Yao> cache the system call number? (I think yes) If object about enter a Yao> syscall cache the syscall number, how could it pass this system call Yao> number to the object about exit a system call? Another good question. One idea would be to have two different interfaces, one for entering a syscall and one for exiting. Then there would be a single class which implements both. This would allow for identity to be well handled, and would prevent users from directly calling methods which were unavailable. This seems a little clunky though. Perhaps some other solution is available. One thing to consider is that if an observer has to track the relationship between the enter and exit event objects, then there needs to be some relatively simple way to track syscalls which do not have an exit event (e.g., a successful exec) -- otherwise bookkeeping on the observer side could be difficult or impossible. Another way to go is to have one class, with a special "cache the arguments" request, and have getArgument throw an exception if the cache request call was not made at syscall enter time. One way that this is nice is that if multiple observers need a cache, the lookups will only be done a single time. I'm just throwing out ideas here. I don't have a strong feeling for what the best approach is. I just want to avoid situations where writing observers is overly hard or expensive, or situations where "obvious" uses of the API randomly fail, as is now the case. Tom From aoliva@redhat.com Mon Sep 25 05:25:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Mon, 25 Sep 2006 05:25:00 -0000 Subject: Disable testThreadedBacktrace on ! ia32 In-Reply-To: <1158918695.3024.5.camel@dijkstra.wildebeest.org> (Mark Wielaard's message of "Fri, 22 Sep 2006 11:51:34 +0200") References: <1158918695.3024.5.camel@dijkstra.wildebeest.org> Message-ID: On Sep 22, 2006, Mark Wielaard wrote: > Till we get better libunwind support the backtrace tests won't work on > anything but x86. So I disabled the newly introduced test for now. > 2006-09-22 Mark Wielaard > (testThreadedBacktrace): Disabled. Bug #2936. > I haven't yet tested the patches from Alexander. The patch is now in. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva@redhat.com Mon Sep 25 05:51:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Mon, 25 Sep 2006 05:51:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: (Alexandre Oliva's message of "Sun, 17 Sep 2006 03:16:07 -0300") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: On Sep 17, 2006, Alexandre Oliva wrote: > On Sep 15, 2006, Alexandre Oliva wrote: >> Here's the patch that fixes line numbers for main() and addresses >> printed in backtraces for PCs in modules that don't have unwind info. >> I wonder if I should set an upper limit on the symbol name size >> instead of keeping retrying until memory is really exhausted or so. >> Thoughts? > Here's another approach I thought of, that involves a change in the > interface of the get_proc_name callback, requiring it to cope with a > NULL buf and zero buf_len. We could do away with the latter, and pass > in ~(size_t)0 for essentially the same effect, but since it hardly > makes any difference, I thought I'd go for both. > Is this ok for frysk? It should reduce the stack size requirements > when unwinding through ridiculously long symbol names. > Ok for frysk? > for frysk/frysk-imports/libunwind/ChangeLog > from Alexandre Oliva > * src/elfxx.c (lookup_symbol): Cope with NULL buf and zero buf_len. > * src/mi/Gget_proc_name.c (intern_string, get_proc_name): Likewise. > * src/hppa/Gget_proc_info.c (unw_get_proc_info): Use it. > * src/x86/Gget_proc_info.c (unw_get_proc_info): Likewise. > * src/x86_64/Gget_proc_info.c (unw_get_proc_info): Likewise. > * doc/unw_get_proc_name.tex: Document NULL buf and zero buf_len. > * doc/unw_create_addr_space.tex (get_proc_name): Likewise. > * doc/unw_get_proc_name.man: Rebuilt. > * doc/unw_create_addr_space.man: Likewise. Ping? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From qiyaoltc@cn.ibm.com Mon Sep 25 07:16:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 25 Sep 2006 07:16:00 -0000 Subject: Disable testThreadedBacktrace on ! ia32 Message-ID: <20060925055053.GA4063@GreenHouse.cn.ibm.com> Hi, Mark, testThreadedBacktrace fails on my box(x86 rawhide, but FC5 kernel). My gcc version is 4.1.1 20060917 (Red Hat 4.1.1-23). Here are two problems, a) function name is "clone" instead of "__clone" I add some "System.err.println" in this case, and here is the output, [qiyao@GreenHouse frysk-core]$ ./TestRunner frysk.rt.tests.TestStackBacktraceRunning testBacktrace(frysk.rt.tests.TestStackBacktrace) ...PASS Running testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace) ...__libc_start_main clone FAIL junit.framework.ComparisonFailure: expected:<__...> but was:<...> Time: 0.403 There was 1 failure: 1) testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.ComparisonFailure: expected:<__...> but was:<...> at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner) at frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 2, Failures: 1, Errors: 0 It seems that output is "clone" instead of "__clone". Does the function name vary from different versions of library? I do not know what happened on your box when run this case, so I do not change "__clone" to "clone" in this case. b) Compilation flags to test case affect the result. If we compile funit-rt-threader without "-g", the result is like this, Time: 0.341 There was 1 error: 1) testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)java.lang.NullPointerException at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner) at frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) There was 1 failure: 1) testBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.AssertionFailedError: expected:<61> but was:<62> at frysk.rt.tests.TestStackBacktrace.testBacktrace(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 2, Failures: 1, Errors: 1 Compile funit-rt-threder with "-g", the result is like this, [qiyao@GreenHouse frysk-core]$ ./TestRunner frysk.rt.tests.TestStackBacktrace Running testBacktrace(frysk.rt.tests.TestStackBacktrace) ...FAIL junit.framework.AssertionFailedError: expected:<61> but was:<62> Running testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace) ...FAIL junit.framework.AssertionFailedError: expected:<71> but was:<72> Time: 0.39 There were 2 failures: 1) testBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.AssertionFailedError: expected:<61> but was:<62> at frysk.rt.tests.TestStackBacktrace.testBacktrace(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) 2) testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.AssertionFailedError: expected:<71> but was:<72> at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner) at frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner) at frysk.junit.Runner.(TestRunner) at TestRunner.main(TestRunner) FAILURES!!! Tests run: 2, Failures: 2, Errors: 0 -- Yao Qi From mark@klomp.org Mon Sep 25 08:09:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 25 Sep 2006 08:09:00 -0000 Subject: Enable testGetLine except X86_64 In-Reply-To: <4516E8BA.3090907@redhat.com> References: <20060919034729.GD2378@GreenHouse.cn.ibm.com> <1158667656.3033.7.camel@dijkstra.wildebeest.org> <4516E8BA.3090907@redhat.com> Message-ID: <1159168557.2717.6.camel@localhost.localdomain> Hi Tim, On Sun, 2006-09-24 at 22:21 +0200, Tim Moore wrote: > > The test case does work for me on x86_64. I don't know why it is failing > > for Tim, maybe a different compiler that puts a different line number in > > the debug info? > I'm in the habit of compiling with CGJFLAGS='-g', with the same for the > other compiler flags as well, in an effort to improve debuggability; > I've assumed that's why I see different line numbers in these tests. Interesting. So what is the line number that gets reported now for TestDwfl.testGetLine()? Since everything is now on one line (line 58) I am surprised the compiler can actually but something else in. Cheers, Mark From mark@klomp.org Mon Sep 25 08:24:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 25 Sep 2006 08:24:00 -0000 Subject: frysk-core lib/unwind/ChangeLog frysk/proc/Cha ... In-Reply-To: <20060925052357.10484.qmail@sourceware.org> References: <20060925052357.10484.qmail@sourceware.org> Message-ID: <1159171784.2717.26.camel@localhost.localdomain> Hi Alexander, On Mon, 2006-09-25 at 05:23 +0000, aoliva@sourceware.org wrote: > Log message: > frysk-imports/lib/unwind/ChangeLog: > * RegisterAMD64.java: New class. You forgot to cvs add this file. I got an old version from your patch and added it to CVS. Hope it is the correct version. Cheers, Mark From qiyaoltc@cn.ibm.com Mon Sep 25 08:44:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 25 Sep 2006 08:44:00 -0000 Subject: Missing libopcodes.a for ppc64 on FC6 Test3 Message-ID: <20060925082403.GB4063@GreenHouse.cn.ibm.com> Hi, Stepan, /usr/lib64/libopcodes.a is needed to build frysk on ppc64, but any packages on FC6 Test3 do not contain this library. On FC5, /usr/lib64/libopcodes.a is packaged in binutils.ppc64.rpm, but on rawhide, /usr/lib64/libopcodes.a is packaged in binutils-devel.ppc64.rpm. Could you help to add binutils-devel.ppc64.rpm in FC6? Thanks in advance! -- Yao Qi From mark@klomp.org Mon Sep 25 09:57:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 25 Sep 2006 09:57:00 -0000 Subject: Disable testThreadedBacktrace on ! ia32 In-Reply-To: <20060925055053.GA4063@GreenHouse.cn.ibm.com> References: <20060925055053.GA4063@GreenHouse.cn.ibm.com> Message-ID: <1159173845.2717.33.camel@localhost.localdomain> Hi Yao, On Mon, 2006-09-25 at 13:50 +0800, Yao Qi wrote: > a) function name is "clone" instead of "__clone" > I add some "System.err.println" in this case, and here is the output, > > testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.ComparisonFailure: > expected:<__...> but was:<...> > at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner) > at > frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > > FAILURES!!! > Tests run: 2, Failures: 1, Errors: 0 > > It seems that output is "clone" instead of "__clone". Does the > function name vary from different versions of library? I do not know > what happened on your box when run this case, so I do not change > "__clone" to "clone" in this case. Interesting. I tested on x86 (FC development 2.6.18-1.2689.fc6, gcc 4.1.1 20060920). And indeed I also get __clone there. Mike, what kind of system are you using? > b) Compilation flags to test case affect the result. > If we compile funit-rt-threader without "-g", the result is like this, > Time: 0.341 > There was 1 error: > 1) > testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)java.lang.NullPointerException > at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner) > at > frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) > There was 1 failure: > 1) > testBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.AssertionFailedError: > expected:<61> but was:<62> > at frysk.rt.tests.TestStackBacktrace.testBacktrace(TestRunner) > at frysk.junit.Runner.(TestRunner) > at TestRunner.main(TestRunner) That seems to be what Tim is also seeing. Using -g to compile moves the actual debug info/line number by one. Cheers, Mark From zhengyo@cn.ibm.com Mon Sep 25 11:03:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Mon, 25 Sep 2006 11:03:00 -0000 Subject: The TestI386Modify.java and TestX8664Modify.java are deleted now. Message-ID: <1159178285.4957.4.camel@YZ_X86_64> hi, The two cases(TestI386Modify.java and TestX8664Modify.java) are deleted. Of course, we merge them into the new general TestRegMemModify.java together with adding the similar case for PPC64. So use the general TestRegMemModify afterwards please. :-) Best regards Yong Zheng From kasal@ucw.cz Mon Sep 25 11:44:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Mon, 25 Sep 2006 11:44:00 -0000 Subject: Missing libopcodes.a for ppc64 on FC6 Test3 In-Reply-To: <20060925082403.GB4063@GreenHouse.cn.ibm.com> References: <20060925082403.GB4063@GreenHouse.cn.ibm.com> Message-ID: <20060925110347.GA20078@camelia.ucw.cz> Hello Yao, > /usr/lib64/libopcodes.a is needed to build frysk on ppc64, but any > packages on FC6 Test3 do not contain this library. ... > on rawhide, /usr/lib64/libopcodes.a is packaged in > binutils-devel.ppc64.rpm. > > Could you help to add binutils-devel.ppc64.rpm in FC6? I believe no intervention is needed; the next build of FC6 for ppc will contain binutils-devel.ppc64.rpm. Stepan From qiyaoltc@cn.ibm.com Mon Sep 25 13:10:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Mon, 25 Sep 2006 13:10:00 -0000 Subject: Missing libopcodes.a for ppc64 on FC6 Test3 In-Reply-To: <20060925110347.GA20078@camelia.ucw.cz> References: <20060925082403.GB4063@GreenHouse.cn.ibm.com> <20060925110347.GA20078@camelia.ucw.cz> Message-ID: <20060925114414.GC4063@GreenHouse.cn.ibm.com> On Mon, Sep 25, 2006 at 01:03:47PM +0200, Stepan Kasal wrote: > Hello Yao, > > > /usr/lib64/libopcodes.a is needed to build frysk on ppc64, but any > > packages on FC6 Test3 do not contain this library. > ... > > on rawhide, /usr/lib64/libopcodes.a is packaged in > > binutils-devel.ppc64.rpm. > > > > Could you help to add binutils-devel.ppc64.rpm in FC6? > > I believe no intervention is needed; the next build of FC6 for ppc will > contain binutils-devel.ppc64.rpm. Oh, that is great! Thanks for your fast reply! -- Yao Qi From rmoseley@redhat.com Mon Sep 25 13:34:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Mon, 25 Sep 2006 13:34:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> Message-ID: <4517D54D.8060706@redhat.com> Alexandre Oliva wrote: > On Sep 17, 2006, Alexandre Oliva wrote: > > >> On Sep 15, 2006, Alexandre Oliva wrote: >> >>> Here's the patch that fixes line numbers for main() and addresses >>> printed in backtraces for PCs in modules that don't have unwind info. >>> I wonder if I should set an upper limit on the symbol name size >>> instead of keeping retrying until memory is really exhausted or so. >>> Thoughts? >>> > > >> Here's another approach I thought of, that involves a change in the >> interface of the get_proc_name callback, requiring it to cope with a >> NULL buf and zero buf_len. We could do away with the latter, and pass >> in ~(size_t)0 for essentially the same effect, but since it hardly >> makes any difference, I thought I'd go for both. >> > > >> Is this ok for frysk? It should reduce the stack size requirements >> when unwinding through ridiculously long symbol names. >> > > >> Ok for frysk? >> > > >> for frysk/frysk-imports/libunwind/ChangeLog >> from Alexandre Oliva >> > > >> * src/elfxx.c (lookup_symbol): Cope with NULL buf and zero buf_len. >> * src/mi/Gget_proc_name.c (intern_string, get_proc_name): Likewise. >> * src/hppa/Gget_proc_info.c (unw_get_proc_info): Use it. >> * src/x86/Gget_proc_info.c (unw_get_proc_info): Likewise. >> * src/x86_64/Gget_proc_info.c (unw_get_proc_info): Likewise. >> * doc/unw_get_proc_name.tex: Document NULL buf and zero buf_len. >> * doc/unw_create_addr_space.tex (get_proc_name): Likewise. >> * doc/unw_get_proc_name.man: Rebuilt. >> * doc/unw_create_addr_space.man: Likewise. >> > > Ping? > > Hi Alex, I guess *most* of us were hesitating because we don't feel we are qualified to judge the code. If it works ok on your system and does not break any tests I would say check it in so the rest of us can test it. Thanks for your efforts here, Alex. Rick From mcvet@redhat.com Tue Sep 26 02:05:00 2006 From: mcvet@redhat.com (Mike Cvet) Date: Tue, 26 Sep 2006 02:05:00 -0000 Subject: Disable testThreadedBacktrace on ! ia32 In-Reply-To: <1159173845.2717.33.camel@localhost.localdomain> References: <20060925055053.GA4063@GreenHouse.cn.ibm.com> <1159173845.2717.33.camel@localhost.localdomain> Message-ID: <1159191266.16796.9.camel@towel.toronto.redhat.com> On Mon, 2006-09-25 at 10:44 +0200, Mark Wielaard wrote: > Hi Yao, > > On Mon, 2006-09-25 at 13:50 +0800, Yao Qi wrote: > > a) function name is "clone" instead of "__clone" > > I add some "System.err.println" in this case, and here is the output, > > > > testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.ComparisonFailure: > > expected:<__...> but was:<...> > > at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner) > > at > > frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner) > > at frysk.junit.Runner.(TestRunner) > > at TestRunner.main(TestRunner) > > > > FAILURES!!! > > Tests run: 2, Failures: 1, Errors: 0 > > > > It seems that output is "clone" instead of "__clone". Does the > > function name vary from different versions of library? I do not know > > what happened on your box when run this case, so I do not change > > "__clone" to "clone" in this case. > > Interesting. I tested on x86 (FC development 2.6.18-1.2689.fc6, gcc > 4.1.1 20060920). And indeed I also get __clone there. Mike, what kind of > system are you using? > I'm using FC5 2.6.17-1.2187_FC5 with GCC 4.1.1 20060525. > > b) Compilation flags to test case affect the result. > > If we compile funit-rt-threader without "-g", the result is like this, > > Time: 0.341 > > There was 1 error: > > 1) > > testThreadedBacktrace(frysk.rt.tests.TestStackBacktrace)java.lang.NullPointerException > > at frysk.rt.tests.TestStackBacktrace.frameAssertions(TestRunner) > > at > > frysk.rt.tests.TestStackBacktrace.testThreadedBacktrace(TestRunner) > > at frysk.junit.Runner.(TestRunner) > > at TestRunner.main(TestRunner) > > There was 1 failure: > > 1) > > testBacktrace(frysk.rt.tests.TestStackBacktrace)junit.framework.AssertionFailedError: > > expected:<61> but was:<62> > > at frysk.rt.tests.TestStackBacktrace.testBacktrace(TestRunner) > > at frysk.junit.Runner.(TestRunner) > > at TestRunner.main(TestRunner) What is interesting about this one that that 62 is the *correct* line number that libunwind should be pulling out, but I can't figure out why it gives me one line less than it should. This is after my fix for the innermost frames/signal frames memory address decrement. Strange that it appears to be giving the correct line number on your system. I'll file a bug and fix up the test case regarding this. > > That seems to be what Tim is also seeing. Using -g to compile moves the > actual debug info/line number by one. /me wonders what is going on! From qiyaoltc@cn.ibm.com Tue Sep 26 10:21:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Tue, 26 Sep 2006 10:21:00 -0000 Subject: Some java-gnome devel packages for ppc64 is missed on FC6T3 Message-ID: <20060926020456.GD4063@GreenHouse.cn.ibm.com> Here is a list about missed java-gnome devel packages on FC6T3, libglade-java-devel-2.12.5-2.fc6.ppc64.rpm libvte-java-devel-0.12.1-3.fc6.ppc64.rpm vte-devel-0.14.0-1.fc6.ppc64.rpm ncurses-devel-5.5-24.20060715.ppc64.rpm (needed by vte-devel) These packages could be found on rawhide. Is there any plan to add these packages in the next build of FC6? Could you help us check to make sure these packages could be found in the next build of FC6. Thanks! -- Yao Qi From mark@klomp.org Tue Sep 26 13:38:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 26 Sep 2006 13:38:00 -0000 Subject: Replacing sys.SyscallNum with proc.Syscall in TestSyscallSignal Message-ID: <1159266069.3115.39.camel@dijkstra.wildebeest.org> Hi, Tim was testing out x86_64 "32on64" tracing and found an issue with TestSyscallSignal since this is using SyscallNum for finding the system call numbers. Since SyscallNum uses hardcoded numbers for the architecture it was build on that fails for things like "32on64". This patch makes sure the test uses Syscall and looks up the syscalls by name. We should probably deprecate and remove SyscallNum everywhere. 2006-09-26 Mark Wielaard * TestSyscallSignal.java: Replace usage of sys.SyscallNum with proc.Syscall. Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: TestSyscallSignal-noSyscallNum.patch Type: text/x-patch Size: 2395 bytes Desc: not available URL: From kasal@ucw.cz Tue Sep 26 17:29:00 2006 From: kasal@ucw.cz (Stepan Kasal) Date: Tue, 26 Sep 2006 17:29:00 -0000 Subject: Some java-gnome devel packages for ppc64 is missed on FC6T3 In-Reply-To: <20060926020456.GD4063@GreenHouse.cn.ibm.com> References: <20060926020456.GD4063@GreenHouse.cn.ibm.com> Message-ID: <20060926133813.GA3887@camelia.ucw.cz> Hello, On Tue, Sep 26, 2006 at 10:05:00AM +0800, Yao Qi wrote: > Here is a list about missed java-gnome devel packages on FC6T3, > > libglade-java-devel-2.12.5-2.fc6.ppc64.rpm > libvte-java-devel-0.12.1-3.fc6.ppc64.rpm > vte-devel-0.14.0-1.fc6.ppc64.rpm > ncurses-devel-5.5-24.20060715.ppc64.rpm (needed by vte-devel) I have verified that all these packages are present on the FC6T3 ppc tree, as well as on the latest nightly build of the tree. To be absolutely sure, I downloaded the file FC-6-Test3-ppc-DVD.iso, mounted it, and verified that all files are indeed present there. Could you please provide more details? Or is it just a mistake? Have a nice day, Stepan Kasal From cagney@redhat.com Tue Sep 26 18:15:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Tue, 26 Sep 2006 18:15:00 -0000 Subject: agenda 2006-09-26 Message-ID: <4519639B.8010407@redhat.com> Business arising from attached. Next work items. -------------- next part -------------- An embedded message was scrubbed... From: Stan Cox Subject: minutes 2006-09-19 Date: Wed, 20 Sep 2006 11:45:37 -0400 Size: 5662 URL: From rmoseley@redhat.com Tue Sep 26 20:41:00 2006 From: rmoseley@redhat.com (Rick Moseley) Date: Tue, 26 Sep 2006 20:41:00 -0000 Subject: Variable Viewing in Source Window Message-ID: <45196E3D.1080207@redhat.com> Hi all, Stan and I talked last week about viewing variable values in the source window. These items were found to be already done: - Stan is able to display the current information on scalar variables coming from libdwarf. - This variable info is from the current stack frame. - This information is displayed via an output stream that is passed to the calling program. Here is what needs to be done. 1) Source window needs to detect when it is hovering over a variable Hopefully we can get Adam to work this issue 2) There needs to be plumbing so when a variable is hovered over, we can pass it and other necessary info to Stan's code so the proper variable value can be retrieved Rick will work this issue. 3) Other items the source window needs to pass to Stan to get a variable value: PID, task object, line number The line number can be used to determine the proper stack frame so the right variable value can be retrieved The source window will need to get and cache the task object Rick/Adam to work these issues 4) Instead of output streams being passed back to the source window, a string is preferable. Stan will work this issue. 5) Interface to the libdwarf needs to be refined so it can handle stack frames based on a line number Stan will work this issue These are the outstanding things as Stan and I discussed. Andrew, Adam, please advise if we missed anything. When we get this nailed down I will post to the external list. As a fallout of this meeting Adam pointed out that there are some pretty big issues trying to hover over a variable and showing the value in a tooltip-type window. These issues will probably take quiet a bit of time to resolve, so for the time being we will resort to having variables shown when a right-click is done on the variable. Hopefully, later we(Adam :) can come up with a way to make the hover implementation work usefully. Adam has gone off to connect the source window to the core to show the variable values. Stan has already done and checked in the part where a variable value is passed back to the source window in a string. The hope is that sometime this week we will have something rudimentary going and we can refine it from there. Rick From npremji@redhat.com Wed Sep 27 02:00:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Wed, 27 Sep 2006 02:00:00 -0000 Subject: Caution cvs import. Message-ID: <1159303358.27857.13.camel@tow.toronto.redhat.com> I have accidentally committed all of frysk-imports underneath frysk-imports/getopts/src/getopt/gnu/classpath/tools/getopt using a cvs import. Anyone doing a cvs update will be taking all of these files in. I apologize for the inconvenience. From qiyaoltc@cn.ibm.com Wed Sep 27 04:08:00 2006 From: qiyaoltc@cn.ibm.com (Yao Qi) Date: Wed, 27 Sep 2006 04:08:00 -0000 Subject: Some java-gnome devel packages for ppc64 is missed on FC6T3 In-Reply-To: <20060926133813.GA3887@camelia.ucw.cz> References: <20060926020456.GD4063@GreenHouse.cn.ibm.com> <20060926133813.GA3887@camelia.ucw.cz> Message-ID: <20060927020010.GE4063@GreenHouse.cn.ibm.com> On Tue, Sep 26, 2006 at 03:38:13PM +0200, Stepan Kasal wrote: > Hello, > > On Tue, Sep 26, 2006 at 10:05:00AM +0800, Yao Qi wrote: > > Here is a list about missed java-gnome devel packages on FC6T3, > > > > libglade-java-devel-2.12.5-2.fc6.ppc64.rpm > > libvte-java-devel-0.12.1-3.fc6.ppc64.rpm > > vte-devel-0.14.0-1.fc6.ppc64.rpm > > ncurses-devel-5.5-24.20060715.ppc64.rpm (needed by vte-devel) > > I have verified that all these packages are present on the FC6T3 ppc > tree, as well as on the latest nightly build of the tree. > > To be absolutely sure, I downloaded the file FC-6-Test3-ppc-DVD.iso, > mounted it, and verified that all files are indeed present there. > > Could you please provide more details? Or is it just a mistake? Hi, Stepan It is a mistake. These packages could be found in FC-6-Test3-ppc-disc3.iso. Thanks for your check. I mounted FC-6-Test3-ppc-disc3.iso to cd3/ and to cd4/ by mistake, so I fail to find these packages. Sorry for the trouble it brought. > > Have a nice day, > Stepan Kasal -- Yao Qi From aoliva@redhat.com Wed Sep 27 11:11:00 2006 From: aoliva@redhat.com (Alexandre Oliva) Date: Wed, 27 Sep 2006 11:11:00 -0000 Subject: remote dwarf info using libunwind In-Reply-To: <4517D54D.8060706@redhat.com> (Rick Moseley's message of "Mon, 25 Sep 2006 08:10:37 -0500") References: <17654.58091.990245.779626@localhost.redhat.com> <44F7B091.4090003@cn.ibm.com> <44FBFCE2.8030505@cn.ibm.com> <4517D54D.8060706@redhat.com> Message-ID: On Sep 25, 2006, Rick Moseley wrote: > Alexandre Oliva wrote: >> On Sep 17, 2006, Alexandre Oliva wrote: >>> for frysk/frysk-imports/libunwind/ChangeLog >>> from Alexandre Oliva >>> * src/elfxx.c (lookup_symbol): Cope with NULL buf and zero buf_len. >>> * src/mi/Gget_proc_name.c (intern_string, get_proc_name): Likewise. >>> * src/hppa/Gget_proc_info.c (unw_get_proc_info): Use it. >>> * src/x86/Gget_proc_info.c (unw_get_proc_info): Likewise. >>> * src/x86_64/Gget_proc_info.c (unw_get_proc_info): Likewise. >>> * doc/unw_get_proc_name.tex: Document NULL buf and zero buf_len. >>> * doc/unw_create_addr_space.tex (get_proc_name): Likewise. >>> * doc/unw_get_proc_name.man: Rebuilt. >>> * doc/unw_create_addr_space.man: Likewise. > I guess *most* of us were hesitating because we don't feel we are > qualified to judge the code. I see. > If it works ok on your system and does not break any tests I would > say check it in so the rest of us can test it. In this case, it's in! :-) > Thanks for your efforts here, Alex. My pleasure. I guess I'll probably disappear from this list at this point, unless I get further frysk-related assignments. It was fun to be around :-) Please Cc: me explicitly if you find that I broke something or just would like me to clarify something. I'm not leaving the mailing list, but I probably won't pay much attention to it except for stuff in which I'm explicitly Cc:ed. Have fun, and keep up the great work, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Secretary for FSF Latin America http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From zhengyo@cn.ibm.com Wed Sep 27 11:18:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 27 Sep 2006 11:18:00 -0000 Subject: Test result of utrace on PPC64(based on FC6 Test 3 release). Message-ID: <1159355486.4957.79.camel@YZ_X86_64> hi all, Based on the FC6 Test 3, we do one thorough test of utrace on PPC64. The test still consists of the following two parts and we summarize the test results as followings, wishing it can be helpful for you to get to know the progress of utrace on PPC64. 1. Gdb's test on FC6 Test 3 release. The followings are some packages relevant with this test: * kernel: 2.6.17-1.2630.fc6 (shipped with FC6 Test 3) * gcc: 4.1.1 20060828 (Red Hat 4.1.1-20)(shipped with FC6 Test 3) * gdb-6.5: down load from gdb's website. In order to know the progress of utrace on PPC64 more easily, we list all test results including on FC5(kernel: 2.6.17-1.2145_FC5, this kernel is with the original ptrace and does not apply utrace's patch), on FC6 T2(kernel: 2.6.17-1.2517_fc6, the original ptrace in the kernel is replaced by utrace) and on FC6 T3. Table1 Test results for 32on64on64 Testcase FC5 FC6 T2 FC6 T3 expected passes 10673 10660 10654 unexpected failures 339(3.18%) 356(3.34%) 355(3.332%) expected failures 40 40 40 known failures 59 59 59 unresolved testcases 15 14 13 untested testcases 5 4 8 unsupported tests 11 11 11 Table2 Test results for 64on64on64 Testcase FC5 FC6 T2 FC6 T3 expected passes 10684 10665 10637 unexpected failures 392(3.67%) 409(3.835%) 421(3.958%) expected failures 44 44 44 known failures 60 60 60 unresolved testcases 4 4 4 untested testcases 1 1 4 unsupported tests 12 14 12 Notes: 1)32on64on64 means 32-bit cases on 64-bit gdb and on 64-bit kernel. 2)"ulimit -c unlimited" is run at all tests except the 64on64on64 test based on FC6 Test2.(sorry for this mistake) 3)On all 64on64on64 tests, CFLAGS_FOR_TARGET='-m64' is passed as one RUNTESTFLAGS option when running gdb's testcases, which can make all testcases into 64-bit mode except assembly programs. 4)On all 64on64on64 tests, ASFLAGS_FOR_TARGET='-a64 -mppc64' and LDFLAGS_FOR_TARGET='-m elf64ppc' are passed as RUNTESTFLAGS options just for the test based on FC6 T3.(on tests based on FC5 and FC6 T2, we didn't realize this problem. sorry again for this mistake) The figure in Table1 shows the progress of utrace, the unexpected failure rate has a mild decrease(from 3.334% to 3.332%). As for 64on64on64, the unexpected failure rate should have some decrease if considering item 3) and item 4) in the above Notes. 2. utrace's testsuites on FC6 Test 3 release. In this part, we run the test cases from roland's website: ntrace-0.0.6 and crash-suspend. The case crash-suspend seems to work well, but after the crashed process has stopped, we fail when attaching to it by gdb, read the following error messages: Attaching to program: /home/zhengyong/working/utrace_test/crash-suspend/crash, process 3069 ../../gdb/linux-nat.c:1057: internal-error: linux_nat_attach: Assertion `pid == GET_PID (inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) We traced down the error and find WSTOPSIG (status) return 0 but not SIGSTOP, which makes the gdb fail to attach the process stopped by utrace. We're not sure about that the utrace may not set the process's stop status properly in kernel. About the ntrace packages, there're still some failures, read the following for details: * testsuite's result: 1: insmod bad parameter ok 2: module initializer failure ok 3: basic event reporting FAILED (t_basic.at:52) 4: attach on clone ok 5: implicit detach on reap FAILED (t_reap.at:33) 6: vfork-done event FAILED (t_vfork.at:37) 7: quiesce ok 8: read first general register ok 9: single-step out of system call FAILED (t_step.at:37) * testsuite-biarch's result: 1: insmod bad parameter ok 2: module initializer failure ok 3: basic event reporting FAILED (t_basic.at:52) 4: attach on clone ok 5: implicit detach on reap FAILED (t_reap.at:33) 6: vfork-done event FAILED (t_vfork.at:37) 7: quiesce ok 8: read first general register ok 9: single-step out of system call FAILED (t_step.at:37) If the test logs may be helpful, pls let us know and we are willing to send them to you. Best regards Yong Zheng From zhengyo@cn.ibm.com Wed Sep 27 14:15:00 2006 From: zhengyo@cn.ibm.com (Yong Zheng) Date: Wed, 27 Sep 2006 14:15:00 -0000 Subject: Test result of utrace on PPC64(based on FC6 Test 3 release). In-Reply-To: <1159355486.4957.79.camel@YZ_X86_64> References: <1159355486.4957.79.camel@YZ_X86_64> Message-ID: <1159355891.4957.86.camel@YZ_X86_64> The following is the diff of 64on64on64 between FC5 and FC6 Test3 added some comments. Best regards Yong Zheng --- 64on64on64-2.6.17-1.2145_FC5-2006-08-14/gdb.sum 2006-08-15 11:34:10.000000000 +0800 +++ 64on64on64-2.6.17-1.2630.fc6-2006-09-25/gdb.sum 2006-09-26 06:31:49.000000000 +0800 @@ -1,4 +1,4 @@ -Test Run By root on Mon Aug 14 22:40:09 2006 +Test Run By root on Mon Sep 25 17:44:54 2006 Native configuration is powerpc64-unknown-linux-gnu === gdb tests === @@ -37,27 +37,28 @@ Running ../../../gdb-6.5/gdb/testsuite/gdb.arch/powerpc-aix-prologue.exp ... Running ../../../gdb-6.5/gdb/testsuite/gdb.arch/powerpc-prologue.exp ... Running ../../../gdb-6.5/gdb/testsuite/gdb.asm/asm-source.exp ... -PASS: gdb.asm/asm-source.exp: f at main -PASS: gdb.asm/asm-source.exp: next over macro -PASS: gdb.asm/asm-source.exp: step into foo2 +FAIL: gdb.asm/asm-source.exp: running to main in runto +FAIL: gdb.asm/asm-source.exp: f at main +FAIL: gdb.asm/asm-source.exp: next over macro +FAIL: gdb.asm/asm-source.exp: step into foo2 PASS: gdb.asm/asm-source.exp: info target PASS: gdb.asm/asm-source.exp: info symbol PASS: gdb.asm/asm-source.exp: list PASS: gdb.asm/asm-source.exp: search -PASS: gdb.asm/asm-source.exp: f in foo2 -PASS: gdb.asm/asm-source.exp: n in foo2 -PASS: gdb.asm/asm-source.exp: bt ALL in foo2 -PASS: gdb.asm/asm-source.exp: bt 2 in foo2 +FAIL: gdb.asm/asm-source.exp: f in foo2 +FAIL: gdb.asm/asm-source.exp: n in foo2 +FAIL: gdb.asm/asm-source.exp: bt ALL in foo2 +FAIL: gdb.asm/asm-source.exp: bt 2 in foo2 PASS: gdb.asm/asm-source.exp: s 2 PASS: gdb.asm/asm-source.exp: n 2 -PASS: gdb.asm/asm-source.exp: bt 3 in foo3 +FAIL: gdb.asm/asm-source.exp: bt 3 in foo3 PASS: gdb.asm/asm-source.exp: info source asmsrc1.s -PASS: gdb.asm/asm-source.exp: finish from foo3 -PASS: gdb.asm/asm-source.exp: info source asmsrc2.s +FAIL: gdb.asm/asm-source.exp: finish from foo3 +FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s PASS: gdb.asm/asm-source.exp: info sources -PASS: gdb.asm/asm-source.exp: info line -PASS: gdb.asm/asm-source.exp: next over foo3 -PASS: gdb.asm/asm-source.exp: return from foo2 +FAIL: gdb.asm/asm-source.exp: info line +FAIL: gdb.asm/asm-source.exp: next over foo3 +FAIL: gdb.asm/asm-source.exp: return from foo2 PASS: gdb.asm/asm-source.exp: look at global variable PASS: gdb.asm/asm-source.exp: x/i &globalvar PASS: gdb.asm/asm-source.exp: disassem &globalvar &globalvar+1 Our comments: the asm-source executable program will fire SEGV signal. There're some differences in the assembly program format between ppc and ppc64. And assembly programs under gdb.asm is for PPC but not PPC64. So when we compile it into 64-bit mode, it wonnot run well. In the test based on FC5, all these cases passed because we forgot to pass ASFLAGS_FOR_TARGET='-a64 -mppc64' and LDFLAGS_FOR_TARGET='-m elf64ppc', which makes all these assembly programs compiled into 32-bit mode by default and thus they can pass. @@ -302,7 +303,7 @@ PASS: gdb.base/auxv.exp: matching auxv data from live and core PASS: gdb.base/auxv.exp: load core file for info auxv on gcore-created dump PASS: gdb.base/auxv.exp: info auxv on gcore-created dump -PASS: gdb.base/auxv.exp: matching auxv data from live and gcore +FAIL: gdb.base/auxv.exp: matching auxv data from live and gcore Our comments: The root cause is that the output of "info auxv" on gcore have one line different than that of live code: 15 AT_PLATFORM String identifying platform 0xffff91ff4a1
    which should be: 15 AT_PLATFORM String identifying platform 0xffffb64faf5 "power4" Running ../../../gdb-6.5/gdb/testsuite/gdb.base/bang.exp ... PASS: gdb.base/bang.exp: run program Running ../../../gdb-6.5/gdb/testsuite/gdb.base/bfp-test.exp ... @@ -2809,14 +2810,15 @@ PASS: gdb.base/gcore.exp: continue to terminal_func PASS: gdb.base/gcore.exp: save a corefile PASS: gdb.base/gcore.exp: re-load generated corefile -PASS: gdb.base/gcore.exp: where in corefile +FAIL: gdb.base/gcore.exp: where in corefile (pattern 2) Our comments: The output is different with the expected messages. The output is the following: #0 terminal_func () at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:36 #1 0x00000000100006e0 in array_func () at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:51 Cannot access memory at address 0xfffffc5e8f8 And the expected messages is : ".*\[\r\n\]+#0 .* terminal_func \\(\\) at " ".*\[\r\n\]+#1 .* array_func \\(\\) at " ".*\[\r\n\]+#2 .* factorial_func \\(value=1\\) at " ".*\[\r\n\]+#3 .* factorial_func \\(value=2\\) at " ".*\[\r\n\]+#4 .* factorial_func \\(value=3\\) at " ".*\[\r\n\]+#5 .* factorial_func \\(value=4\\) at " ".*\[\r\n\]+#6 .* factorial_func \\(value=5\\) at " ".*\[\r\n\]+#7 .* factorial_func \\(value=6\\) at " ".*\[\r\n\]+#8 .* main \\(.*\\) at " PASS: gdb.base/gcore.exp: corefile restored general registers FAIL: gdb.base/gcore.exp: corefile restored all registers PASS: gdb.base/gcore.exp: corefile restored extern array PASS: gdb.base/gcore.exp: corefile restored static array -PASS: gdb.base/gcore.exp: corefile restored un-initialized array -PASS: gdb.base/gcore.exp: corefile restored heap array -PASS: gdb.base/gcore.exp: corefile restored stack array +FAIL: gdb.base/gcore.exp: corefile restored un-initialized array Our comments: The un-initialized array is: {0, 0, 0, 0} But the expected is : {9, 10, 11, 12} +FAIL: gdb.base/gcore.exp: corefile restored heap array The heap-string from gcore is: 0x0 But the expected is: +FAIL: gdb.base/gcore.exp: capture_command_output failed on print array_func::local_array. The array_func::local_array is : Cannot access memory at address 0xfffffc5e8f8 But expected is: {13, 14, 15, 16} +FAIL: gdb.base/gcore.exp: corefile restored stack array Caused by the above failure "capture_command_output failed on print array_func::local_array." FAIL: gdb.base/gcore.exp: corefile restored backtrace The backtrace from gcore is : #0 terminal_func () at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:36 #1 0x00000000100006e0 in array_func () at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:51 Cannot access memory at address 0xfffffc5e8f8 But the expected backstrace is: #0 terminal_func () at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:36 #1 0x00000000100006e0 in array_func () at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:51 #2 0x0000000010000754 in factorial_func (value=1) at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:64 #3 0x000000001000073c in factorial_func (value=2) at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:62 #4 0x000000001000073c in factorial_func (value=3) at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:62 #5 0x000000001000073c in factorial_func (value=4) at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:62 #6 0x000000001000073c in factorial_func (value=5) at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:62 #7 0x000000001000073c in factorial_func (value=6) at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:62 #8 0x000000001000079c in main () at ../../../gdb-6.5/gdb/testsuite/gdb.base/gcore.c:70 Running ../../../gdb-6.5/gdb/testsuite/gdb.base/gdb1056.exp ... PASS: gdb.base/gdb1056.exp: print 1/0 @@ -3137,7 +3139,7 @@ PASS: gdb.base/info-proc.exp: help info proc PASS: gdb.base/info-proc.exp: info proc without a process PASS: gdb.base/info-proc.exp: info proc with process -PASS: gdb.base/info-proc.exp: info proc mapping +FAIL: gdb.base/info-proc.exp: info proc mapping Our comments: The failure is not so import because it's just check whether the output format is like ".*Mapped address spaces:.* ${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*" or not. Running ../../../gdb-6.5/gdb/testsuite/gdb.base/interp.exp ... PASS: gdb.base/interp.exp: interpreter-exec mi "-var-update *" PASS: gdb.base/interp.exp: interpreter-exec console "show version" @@ -3510,10 +3512,10 @@ PASS: gdb.base/maint.exp: maint print msymbols w/o args FAIL: gdb.base/maint.exp: maint print msymbols PASS: gdb.base/maint.exp: shell rm -f msymbols_output -PASS: gdb.base/maint.exp: cd /home/zhengyong/working/utrace_test/build_gdb_ppc64_64on64_fc5/gdb/testsuite +PASS: gdb.base/maint.exp: cd /home/zhengyong/working/utrace_test/build_gdb_ppc64_64on64/gdb/testsuite FAIL: gdb.base/maint.exp: maint print msymbols PASS: gdb.base/maint.exp: shell rm -f msymbols_output2 -PASS: gdb.base/maint.exp: cd /home/zhengyong/working/utrace_test/build_gdb_ppc64_64on64_fc5/gdb/testsuite +PASS: gdb.base/maint.exp: cd /home/zhengyong/working/utrace_test/build_gdb_ppc64_64on64/gdb/testsuite PASS: gdb.base/maint.exp: maint print symbols w/o args PASS: gdb.base/maint.exp: maint print symbols PASS: gdb.base/maint.exp: shell rm -f symbols_output @@ -4688,14 +4690,14 @@ PASS: gdb.base/recurse.exp: next over b = 0 in first instance PASS: gdb.base/recurse.exp: set first instance watchpoint PASS: gdb.base/recurse.exp: continue to first instance watchpoint, first time -PASS: gdb.base/recurse.exp: continue to recurse (a = 9) -PASS: gdb.base/recurse.exp: continue to recurse (a = 8) -PASS: gdb.base/recurse.exp: continue to recurse (a = 7) -PASS: gdb.base/recurse.exp: continue to recurse (a = 6) -PASS: gdb.base/recurse.exp: continue to recurse (a = 5) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 9) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 8) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 7) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 6) +FAIL: gdb.base/recurse.exp: continue to recurse (a = 5) Out comments: When "(a = 9)" is expected, it's actually "(a = 0)"; "(a = 0)" for "(a = 8)"; "(a = 9)" for "(a = 7)". And when "(a = 6)" is expected, the gdb output: "Error evaluating expression for watchpoint 2^M Previous frame identical to this frame (corrupt stack?)", which causes the following cases failed. We guess the gdb cannot properly handle the frame of recurse calling! The above failed cases can be passed when using gdb-6.5-7.fc6rh shipped with FC6 T3. In our test of gdb-6.5 based on FC6 T3, all applications are compiled by gcc-4.1.1-20060828 shipped with FC6 T3. So we are not sure whether the above cases' failure is caused by utrace, maybe by utrace, gdb and gcc three all. PASS: gdb.base/recurse.exp: next over b = 0 in second instance PASS: gdb.base/recurse.exp: set second instance watchpoint -PASS: gdb.base/recurse.exp: continue to second instance watchpoint, first time +FAIL: gdb.base/recurse.exp: continue to second instance watchpoint, first time FAIL: gdb.base/recurse.exp: continue to recurse (a = 4) FAIL: gdb.base/recurse.exp: continue to recurse (a = 3) FAIL: gdb.base/recurse.exp: continue to recurse (a = 2) @@ -6051,21 +6053,21 @@ PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; break infinite loop PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; break handler PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; continue to infinite loop -FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler entry; performing step +PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; performing step PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; clear infinite loop PASS: gdb.base/sigstep.exp: step on breakpoint, to handler entry; clear handler PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; resync PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; break infinite loop PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; break handler PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; continue to infinite loop -FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler entry; performing next +PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; performing next PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; clear infinite loop PASS: gdb.base/sigstep.exp: next on breakpoint, to handler entry; clear handler PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; resync PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; break infinite loop PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; break handler PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; continue to infinite loop -FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; performing continue +PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; performing continue PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; clear infinite loop PASS: gdb.base/sigstep.exp: continue on breakpoint, to handler entry; clear handler PASS: gdb.base/sigstep.exp: step on breakpoint, skip handler; resync @@ -7305,7 +7307,7 @@ PASS: gdb.cp/annota3.exp: second run until main breakpoint PASS: gdb.cp/annota3.exp: set watch on a.x PASS: gdb.cp/annota3.exp: watch triggered on a.x -PASS: gdb.cp/annota3.exp: annotate-quit +FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1) Running ../../../gdb-6.5/gdb/testsuite/gdb.cp/anon-union.exp ... PASS: gdb.cp/anon-union.exp: next 1 PASS: gdb.cp/anon-union.exp: print foo 1 @@ -9152,11 +9154,7 @@ PASS: gdb.dwarf2/mac-fileno.exp: list func_cu1 PASS: gdb.dwarf2/mac-fileno.exp: ptype func_cu1 Running ../../../gdb-6.5/gdb/testsuite/gdb.fortran/array-element.exp ... -PASS: gdb.fortran/array-element.exp: breakpoint at continue -PASS: gdb.fortran/array-element.exp: continue to breakpoint -PASS: gdb.fortran/array-element.exp: print the first element of array a -PASS: gdb.fortran/array-element.exp: continue to breakpoint once again -PASS: gdb.fortran/array-element.exp: print the second element of array a +UNTESTED: gdb.fortran/array-element.exp: Couldn't compile array-element.f Running ../../../gdb-6.5/gdb/testsuite/gdb.fortran/derived-type.exp ... UNTESTED: gdb.fortran/derived-type.exp: Couldn't compile derived-type.f90 Running ../../../gdb-6.5/gdb/testsuite/gdb.fortran/exprs.exp ... @@ -9268,16 +9266,7 @@ PASS: gdb.fortran/exprs.exp: int powered by real PASS: gdb.fortran/exprs.exp: real powered by real Running ../../../gdb-6.5/gdb/testsuite/gdb.fortran/subarray.exp ... -PASS: gdb.fortran/subarray.exp: breakpoint at the last write statement -PASS: gdb.fortran/subarray.exp: continue to breakpoint -PASS: gdb.fortran/subarray.exp: print str(2:4) -PASS: gdb.fortran/subarray.exp: print str(:3) -PASS: gdb.fortran/subarray.exp: print str(5:) -PASS: gdb.fortran/subarray.exp: print str(:) -PASS: gdb.fortran/subarray.exp: print array(2:4) -PASS: gdb.fortran/subarray.exp: print array(:3) -PASS: gdb.fortran/subarray.exp: print array(5:) -PASS: gdb.fortran/subarray.exp: print array(:) +UNTESTED: gdb.fortran/subarray.exp: Couldn't compile subarray.f Running ../../../gdb-6.5/gdb/testsuite/gdb.fortran/types.exp ... PASS: gdb.fortran/types.exp: set print sevenbit-strings PASS: gdb.fortran/types.exp: set language fortran @@ -9880,11 +9869,7 @@ PASS: gdb.mi/mi-var-block.exp: delete var foo2 PASS: gdb.mi/mi-var-block.exp: delete var cb Running ../../../gdb-6.5/gdb/testsuite/gdb.mi/mi-var-child-f.exp ... -PASS: gdb.mi/mi-var-child-f.exp: breakpoint at MAIN__ -PASS: gdb.mi/mi-var-child-f.exp: mi runto MAIN__ -PASS: gdb.mi/mi-var-child-f.exp: create local variable array -PASS: gdb.mi/mi-var-child-f.exp: get children of array -PASS: gdb.mi/mi-var-child-f.exp: get grandchildren of array (children of first element of second index) +UNTESTED: gdb.mi/mi-var-child-f.exp: Couldn't compile array.f Running ../../../gdb-6.5/gdb/testsuite/gdb.mi/mi-var-child.exp ... PASS: gdb.mi/mi-var-child.exp: breakpoint at do_children_tests PASS: gdb.mi/mi-var-child.exp: mi runto do_children_tests @@ -11110,7 +11095,7 @@ PASS: gdb.threads/gcore-thread.exp: thread 2 is running PASS: gdb.threads/gcore-thread.exp: save a corefile PASS: gdb.threads/gcore-thread.exp: re-load generated corefile -PASS: gdb.threads/gcore-thread.exp: corefile contains at least two threads +FAIL: gdb.threads/gcore-thread.exp: corefile contains at least two threads Our comments: The threads info in gcore file is not correct. The "info threads" shows: Cannot access memory at address 0x4000081e7e0 But the following is expected: * 3 Thread 4398067610160 (LWP 3593) thread2 (arg=0xdeadbeef) at ../../../gdb-6.5/gdb/testsuite/gdb.threads/pthreads.c:93 2 Thread 4398057124400 (LWP 3592) 0x00000080db782fb4 in __nanosleep_nocancel () from /lib64/libc.so.6 1 Thread 553436991392 (LWP 3589) 0x00000080db782fb4 in __nanosleep_nocancel () from /lib64/libc.so.6 PASS: gdb.threads/gcore-thread.exp: a corefile thread is executing thread2 PASS: gdb.threads/gcore-thread.exp: thread2 is current thread in corefile Running ../../../gdb-6.5/gdb/testsuite/gdb.threads/killed.exp ... @@ -11251,7 +11236,7 @@ PASS: gdb.threads/schedlock.exp: listed args (2) PASS: gdb.threads/schedlock.exp: thread 0 ran PASS: gdb.threads/schedlock.exp: thread 1 ran -PASS: gdb.threads/schedlock.exp: thread 2 ran +FAIL: gdb.threads/schedlock.exp: thread 2 ran (didn't run) PASS: gdb.threads/schedlock.exp: thread 3 ran PASS: gdb.threads/schedlock.exp: thread 4 ran PASS: gdb.threads/schedlock.exp: thread 5 ran @@ -11280,8 +11265,8 @@ PASS: gdb.threads/schedlock.exp: continue with lock does not change thread PASS: gdb.threads/schedlock.exp: listed args (4) PASS: gdb.threads/schedlock.exp: other thread 0 didn't run +PASS: gdb.threads/schedlock.exp: other thread 1 didn't run PASS: gdb.threads/schedlock.exp: current thread ran -PASS: gdb.threads/schedlock.exp: other thread 2 didn't run PASS: gdb.threads/schedlock.exp: other thread 3 didn't run PASS: gdb.threads/schedlock.exp: other thread 4 didn't run PASS: gdb.threads/schedlock.exp: other thread 5 didn't run @@ -11299,8 +11284,8 @@ PASS: gdb.threads/schedlock.exp: step with lock does not change thread PASS: gdb.threads/schedlock.exp: listed args (5) PASS: gdb.threads/schedlock.exp: other thread 0 didn't run (stepping) +PASS: gdb.threads/schedlock.exp: other thread 1 didn't run (stepping) PASS: gdb.threads/schedlock.exp: current thread stepped locked -PASS: gdb.threads/schedlock.exp: other thread 2 didn't run (stepping) PASS: gdb.threads/schedlock.exp: other thread 3 didn't run (stepping) PASS: gdb.threads/schedlock.exp: other thread 4 didn't run (stepping) PASS: gdb.threads/schedlock.exp: other thread 5 didn't run (stepping) Our comments: The above three failures pass when we run it separately like: make check RUNTESTFLAGS="CFLAGS_FOR_TARGET='-m64' gdb.threads/schedlock.exp" So the runtest framework may bring us some unexpected failures in thread test. @@ -11415,10 +11400,10 @@ KFAIL: gdb.threads/tls.exp: info address me (PRMS: gdb/1294) Running ../../../gdb-6.5/gdb/testsuite/gdb.threads/watchthreads.exp ... PASS: gdb.threads/watchthreads.exp: successfully compiled posix threads test case -PASS: gdb.threads/watchthreads.exp: watch args[0] +FAIL: gdb.threads/watchthreads.exp: watch args[0] Our comments: The case expects watch args[0] in hardware watchpoint. However on PPC64, no any hardware watchpoints are available, which causes the test case fail. FAIL: gdb.threads/watchthreads.exp: watch args[1] -FAIL: gdb.threads/watchthreads.exp: threaded watch loop (timeout) -PASS: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit +FAIL: gdb.threads/watchthreads.exp: threaded watch loop +FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit Our comments: These two cases fail for the same reason with the above one. FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit FAIL: gdb.threads/watchthreads.exp: watchpoint on args[0] hit in thread FAIL: gdb.threads/watchthreads.exp: watchpoint on args[1] hit in thread @@ -11564,12 +11549,12 @@ From cagney@redhat.com Wed Sep 27 23:18:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Wed, 27 Sep 2006 23:18:00 -0000 Subject: upstream test results Message-ID: <451A8790.2090500@redhat.com> Just FYI, The frysk-imports/tests directory, which checks for bugs in the build system (compiler, kernel, ...), currently has two (and shortly three) potential test failures: frysk3228/LoggerParent: FC-6=XPASS FC-5=XFAIL problem when calling getLogger ("frysk.proc"); frysk3231/ptrace-test: FC-6=FAIL FC-5=PASS can't simultaneously detach and deliver signal; while this impacts any debugging tool, it is frysk with its aggressive test coverage that, yet again, identifies the problem first (there are other bugs similar to 3231 still being analized) Andrew From npremji@redhat.com Thu Sep 28 14:26:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Thu, 28 Sep 2006 14:26:00 -0000 Subject: getopt instead of jargs. Message-ID: <1159399147.2884.1.camel@tow.toronto.redhat.com> The transition from jargs to getopt is complete and jargs has been completely removed from the cvs tree. make check on fc5 succeeds and all is good. Thank you, Nurdin From mark@klomp.org Thu Sep 28 15:54:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Thu, 28 Sep 2006 15:54:00 -0000 Subject: From breakpoint addresses to source line stepping Message-ID: <1159453562.3034.2.camel@dijkstra.wildebeest.org> Hi, This is an incomplete overview of all the issues/tasks remaining to go from the simple (single threaded) breakpoint address support we have now towards full source line stepping for Frysk. Not everything has the same priority and some are just listed as ideas that would be nice to work on when we had infinite time :) And some issues are only listed because I was thinking in the past that we would use breakpoint addresses to implement them, but on further thought that might be the wrong mechanism to use. Comments on how to prioritize issues and what else can be or is being worked on very welcome. And since it is a pretty long list of issues I am sure I got some things wrong, so please correct me where I am wrong. Especially my knowledge about the higher level runtime/language model and the mapping to/from the low level task/addresses is not yet complete. = Current breakpoint address support implemented. - Proc shares breakpoints between Tasks. TaskState makes sure that running Task gets suspended when a new Code TaskObserver is added for an address that doesn't have a breakpoint set yet in the Proc and resumes immediately (unless already blocked). Code: frysk.proc.Proc, frysk.proc.Task, frysk.proc.TaskState frysk.proc.BreakpointAddresses - Supported through int3 on x86 and x86_64 and through trapping on an illegal instruction on ppc64. ppc isn't supported at this moment. A simple instruction replacement is done on the original addresses which gets reset when stepping (not multi-task safe, see below). Code: frysk.proc.BreakPoint, frysk.proc.Isa[IA32|EMT64|PPC64].getBreakpointInstruction(). - Code observers can be set. Code observer can monitor multiple (related) addresses from multiple Tasks. Get updateHit() called. Code: frysk.proc.TaskObserver.Code, frysk.proc.Task,requestAddCodeObserver() = Bugs and Extensions (low level work to do) - exec call should clears all breakpoints We forget to clear and delete the Code observer in this case. http://sourceware.org/bugzilla/show_bug.cgi?id=3255 - traps can be used by applications Some applications install their own trap handlers and might generate trap events themselves. Our sanity checks are to strict and crash and burn in such cases. http://sourceware.org/bugzilla/show_bug.cgi?id=3256 - system call vs breakpoint stepping. When setting a breakpoint on a system call entry point we cannot easily use ptrace for a single step (since it will 'disappear' into the system call). Solution is to monitor syscall exit or set another breakpoint after return. Or maybe utrace will give us a more flexible interface. Needs test. - Unsafe locations/instructions Some locations or instructions mightbe unsafe for setting an breakpoint since they interfere with the instruction semantics. In particular ppc lwarx/stwcx pairs, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207287 for an example. Question are there similar instruction (pairs) on other architectures? Needs test. - Multiple tasks The current setup is not multi-task safe. When an breakpoint address is hit and we can to continue or step over it the original instruction stream is put back, a step is taking in the Task and the breakpoint instructions are put back. When other Tasks are running this means those Task might miss the breakpoint since they are seeing the original instruction stream. Or worse, they might see an invalid instruction stream with partial breakpoint and partial original instructions in place. This is a problem on architectures that have multibyte breakpoint instruction sequences, like on ppc. There are basically 2 ways to solve this issue: - Stop the world, step, resume world. Whenever an breakpoint address is updated all Tasks of the Proc are suspended first. The original instruction stream is restored. The Task that hit the breakpoint is stepped. The breakpoint instruction is put back. And all Tasks are restarted. This is mostly architecture independent. - Out of instruction stream stepping. To keep the other Tasks running (suspending/resuming has a lot of overhead) we can try to use 'out of instruction stream' stepping. A per Task local memory location is found to put the original instruction(s) on. We set the PC to this location, a step is performed and the PC is set back. On architectures that support different lenght instructions we need to parse the original instruction stream. And for (jump, load or branch) instructions that are relative to the PC after the step we need to 'fixup' some of the registers before or after the step. The kprobe code in the linux kernel is an example of this approach. This is highly architecture dependent. - Hardware breakpoints When available (often there are not many hardware breakpoint registers) we should use an hardware breakpoint to speed things up and simplify things (no code patching needed!). As an extension an analysis of which breakpoints are hit the most can be done so we use them for those and switch others to less used addresses. = Even more stuff that would be nice (low level) - Alternative for simple function call tracing Often users will be interested in just function calls being hit. This can be build upon the low level breakpoint addresses. But a simpler way to add this might be to patch the PLT elf entries of libraries loaded. This is what strace does for example. For languages with alternative linking strategies (gcj) other entry point triggers might be used. This ties in with the runtime/language model used. - Pushing observers/trigger logic into tracee It would reduce overhead a lot if some of the observer logic could be pushed in the tracee so a trap event is only generated when some simple condition holds. This would require elaborate code patching and/or loading of a support library in the executable. Very invasive. Would also need an overview of "simple logic" that is useful. Note that systemtap does something like this in kernel space through loading a kernel module that interacts with kprobes. - Better kernel support. Both utrace and user-kprobes will hopefully become available in the future and might ease some of the issues outlined above. utrace: http://people.redhat.com/roland/utrace/ user-kprobes: http://lwn.net/Articles/176281/ http://lwn.net/Articles/182910/ = Instruction stepping (work items) - Stopping the Task (BlockObserver) There are multiple TaskObserver to stop a Task, most appropriate in this case the Code observer which you can give an address. But there isn't a simple way to just stop the Task where it is currently executing. So a BlockObserver should be introduced which only function is to put the Task in a suspended state. From there on you could inspect the Task and possibly initiate instruction stepping. Code: frysk.proc.TaskObserver.Block - Action blocked(Task); - Stepping the Task (StepObserver) This would enable instruction single stepping. On each step the observer would be called with the current pc value. The implementation would need to add a stepping flag to the running and blocked task states which indicate that instead of task.sendContinue() a task.sendStepInstruction() should be done. Note that it is the responsibility of higher level code to decide whether to instruction step of put a breakpoint when using source line stepping. Code: frysk.proc.TaskObserver.Step - Action stepped(Task,long); = Mapping addresses to lines and back - Mapping addresses to source lines Done through lib.dw (Dwlf,DwflLine). This uses dwarf information, so can only be done when debug info is available. In theory an address could belong to different source lines (when different contexts are optimized into common code). But in practise this seems to be ignore (unavailable?). - TagSets Maintained in frysk.gui.srcwin.tags are the set of source line tags that the gui is interested in. Currently there isn't a way to define them (except loading them from the preferences). The concept seems useful outside the gui/srcwin package. - Mapping TagSets to Task addresses Given a TagSet we need a mechanism for mapping them to breakpoint addresses for each Proc we are interested in. Given the whole system approach that frysk we need a way to map these whenever a new Proc is being observered. Map any core code mapped in to sources which can be mapped against the TagSets. We also need a way to monitor the loading (and unloading) of dynamic libraries = source line stepping, step into, step out off... Given all of the above we can finally implement the functions a user would be interested in given a language model view of the sources. From npremji@redhat.com Thu Sep 28 16:18:00 2006 From: npremji@redhat.com (Nurdin Premji) Date: Thu, 28 Sep 2006 16:18:00 -0000 Subject: Getopt examples. Message-ID: <1159458888.2865.41.camel@tow.toronto.redhat.com> In the spirit of a tutorial on using getopt for your programs here is a list of frysk files that now use getopt: frysk-imports/frysk/expr/RunCppParser.java frysk-imports/inua/util/readelf.java frysk-imports/frysk/junit/Runner.java Some things to note: To create a parser use: Parser parser = new Parser ("command name", "version string") or parser = new Parser("command name, "version string", boolean longOnly) if you want to set whether the parser runs in long option only mode. When adding an option to the parser with parser.add(new Option()...) Option is an abstract class. There are many different constructors for Option that have a variety of short name, long name, description, and argument name combinations. If you have a command line option that takes an argument you need to also provide an argument name so that getopt knows that the option takes an argument. parser.add(new Option ("long-name", 'l', "description of long name", ""){});. Option needs to implement the method: void parsed(String arg0) throws OptionException. The argument is always a string, if you need something else you have to parse it from that string. For example for integers use: int i = Integer.parseInt(String s); putting this all together we have: parser.add(new Option ("long-name", 'l', "description of long name", "" { void parsed (String arg0) throws OptionException { try { global_int = Integer.parseInt(arg0); catch (Exception _) { throw new OptionException("Argument " + arg0 + "was not an integer"); } } The convention is to put all the adds into a single function for clarity. Going back to the Parser class, you can override the validate() function to check for more complicated inter-option issues. For example if you absolutely need to get a pid or a command you would do that here. Parser parser = new Parser("ftrace", "0.0", true) { protected void validate() throws OptionException { if (! requestedPid && commandAndArguments == null) throw new OptionException("no command or PID specified"); } }; set the usage message with: parser.setHeader("Usage String"); and finally the parsing stage. The simple rule: anything that is not an option or an argument is a "file" which has to be handled through the function notifyFile with the FileArgumentCallback class. LinkedList globalOtherArguments = new LinkedList(); parser.parse(args, new FileArgumentCallback() { public void notifyFile(String arg) throws OptionException { globalOtherArguments.add(arg); } }; This concludes my tutorial. Lets see if I can find a spot for this on the website somewhere. From tromey@redhat.com Thu Sep 28 16:42:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Thu, 28 Sep 2006 16:42:00 -0000 Subject: Getopt examples. In-Reply-To: <1159458888.2865.41.camel@tow.toronto.redhat.com> References: <1159458888.2865.41.camel@tow.toronto.redhat.com> Message-ID: >>>>> "Nurdin" == Nurdin Premji writes: Nurdin> In the spirit of a tutorial on using getopt for your programs Nurdin> here is a list of frysk files that now use getopt: Thanks for writing this! BTW feel free to send patches or make suggestions for the javadoc, I'd like it to be as clear as possible. (Code changes are ok too :-) Nurdin> parser.add(new Option ("long-name", 'l', "description of long name", Nurdin> ""){});. The GNU convention is that meta-syntactic variables are all uppercase. Eg from appletviewer: compatibilityGroup.add(new Option("encoding", Main.messages.getString ("gcjwebplugin.encoding_description"), "CHARSET") [...] In the help this looks like: -encoding CHARSET specify the HTML character encoding Nurdin> Parser parser = new Parser("ftrace", "0.0", true) { One thing we have in Classpath is a ClasspathToolParser class, which is a subclass of Parser that sets the version number appropriately. This idea may make sense for frysk as well. Tom From scox@redhat.com Fri Sep 29 08:42:00 2006 From: scox@redhat.com (Stan Cox) Date: Fri, 29 Sep 2006 08:42:00 -0000 Subject: minutes 2006-09-26 In-Reply-To: <4519639B.8010407@redhat.com> References: <4519639B.8010407@redhat.com> Message-ID: <1159461704.15957.21.camel@multics.rdu.redhat.com> Utrace (Chris ) -ptrace on utrace behavior appears to be different than original utrace -If a kill fails then the next ptrace operation is ignored (#203385?) -Thread/Process status when a process clones and then later kills the clone (#?) -Action: Get the C version of the test for 203385 written and committed -Roland is out of action for a while. -frysk 3205 (bugzilla 206475) Ptrace requests may be masked by failed signal delivery. -Test case written and a fix is being tested -frysk 3231 (bugzilla 207674) PTRACE_DETACH doesn't deliver signals under utrace. -ptrace behavior changed; investigate. -Action: run frysk tests with patched kernel Backtrace (Mike ) -Missing frames problem solved -Sometimes additional frames are displayed -rt/tests/TestStackBacktrace innermost frame line number is off by 1 -Action: Debug additional frames and line number problem Fstack (Nurdin ) -Changing from jargs to getopt in all callers -Fstack ready other than adding getopt support -Action: Work out multi-threaded fstack (+pmuldoon) -Action: Investigate the gdb pstack bug (+cagney) (Thread is in a state that the caller is expecting an event and doesn't receive it.) 64 bit (Tim ) -32 on 64 bit is done -fixed multi architecture syscall handling Breakpoint (Mark ) -Working on supporting source line breakpoints -Blocking observer (was called stepping observer) may help -New topic for next week -When added to a task then the task becomes blocked -Purpose is to stop a task -When the observer is removed then the task continues -Challenge is when to add and remove observer so single stepping is done -Mark/Tim meeting -Action: Stepping observer design? Disassemble (Mike ) -Adding multiple tasks into source windows handling -Blocking observer would help here too -Multiple threads in a source window is a candidate for a workflow -Andrew posting url about multiple threading for insight -Action: Transition topic to handling multi threaded displays Testing & Dogtail (Phil ) Dogtail is okay for testing except results are not always reliable. -Future desirable is to also use frame buffer and junit testing -Getting dogtail to run headless on brew -bugfix in frame buffer required -Bug cause possibilities are: headless behavior, gnome memory smashing, corba (was it corba or something else?) bug -The memory smashing bug has been isolated Source (Stan , Rick ) -Meeting to discuss symbol/gui interaction -Symbol handling refactored to make gui interaction easier -Looking at prior frames support with libunwind. -Action: prior frame support Coverage (Stan, Andrew) -Investigate infrastructure changes needed to support gcov -No change Syscall (Phil) -Yao's caching syscall ideas -Syscall observers are more complicated than other observers from the core perspective Core file (Phil) -Fcore ... create corefile from running process and load a corefile -How should offline corefiles be handled RPM (Stepan ) -Spinning RPMs and working with Phil with dogtail testing -FC6 push on Friday or Monday -Cannot run dogtail on FC5 because dogtail is not available to brew -How to handle dogtail testing on FC6 -make it a postinstall test due to time to run tests -How to handle errata: respin or backport? -Hesitant to maintain a branch as is done for gcc toolchains -Give people advance warning on when branch will be cut From woodzltc@cn.ibm.com Fri Sep 29 14:08:00 2006 From: woodzltc@cn.ibm.com (Wu Zhou) Date: Fri, 29 Sep 2006 14:08:00 -0000 Subject: minutes 2006-09-26 In-Reply-To: <1159461704.15957.21.camel@multics.rdu.redhat.com> References: <4519639B.8010407@redhat.com> <1159461704.15957.21.camel@multics.rdu.redhat.com> Message-ID: <451CDC51.8090204@cn.ibm.com> Stan, Thanks for the minutes. All of us in China will begin the vacation starting from 10/1... will get back at around 10/8. Phil, we are also interested in fcore and other little utilities, we are very happy to know if there are any progress on that. Stan Cox wrote: > Utrace (Chris ) > -ptrace on utrace behavior appears to be different than original utrace > -If a kill fails then the next ptrace operation is ignored (#203385?) > -Thread/Process status when a process clones and then later kills the > clone (#?) > -Action: Get the C version of the test for 203385 written and > committed > -Roland is out of action for a while. > -frysk 3205 (bugzilla 206475) Ptrace requests may be masked by failed > signal delivery. > -Test case written and a fix is being tested > -frysk 3231 (bugzilla 207674) PTRACE_DETACH doesn't deliver signals > under utrace. > -ptrace behavior changed; investigate. > -Action: run frysk tests with patched kernel > > Backtrace (Mike ) > -Missing frames problem solved > -Sometimes additional frames are displayed > -rt/tests/TestStackBacktrace innermost frame line number is off by 1 > -Action: Debug additional frames and line number problem > > Fstack (Nurdin ) > -Changing from jargs to getopt in all callers > -Fstack ready other than adding getopt support > -Action: Work out multi-threaded fstack (+pmuldoon) > -Action: Investigate the gdb pstack bug (+cagney) > (Thread is in a state that the caller is expecting an event and doesn't > receive it.) > > 64 bit (Tim ) > -32 on 64 bit is done > -fixed multi architecture syscall handling > > Breakpoint (Mark ) > -Working on supporting source line breakpoints > -Blocking observer (was called stepping observer) may help > -New topic for next week > -When added to a task then the task becomes blocked > -Purpose is to stop a task > -When the observer is removed then the task continues > -Challenge is when to add and remove observer so single stepping is > done > -Mark/Tim meeting > -Action: Stepping observer design? > > Disassemble (Mike ) > -Adding multiple tasks into source windows handling > -Blocking observer would help here too > -Multiple threads in a source window is a candidate for a workflow > -Andrew posting url about multiple threading for insight > -Action: Transition topic to handling multi threaded displays > > Testing & Dogtail (Phil ) > Dogtail is okay for testing except results are not always reliable. > -Future desirable is to also use frame buffer and junit testing > -Getting dogtail to run headless on brew > -bugfix in frame buffer required > -Bug cause possibilities are: headless behavior, > gnome memory smashing, corba (was it corba or something else?) bug > -The memory smashing bug has been isolated > > Source (Stan , Rick ) > -Meeting to discuss symbol/gui interaction > -Symbol handling refactored to make gui interaction easier > -Looking at prior frames support with libunwind. > -Action: prior frame support > > Coverage (Stan, Andrew) > -Investigate infrastructure changes needed to support gcov > -No change > > Syscall (Phil) > -Yao's caching syscall ideas > -Syscall observers are more complicated than other observers from the > core perspective > > Core file (Phil) > -Fcore ... create corefile from running process and load a corefile > -How should offline corefiles be handled > > RPM (Stepan ) > -Spinning RPMs and working with Phil with dogtail testing > -FC6 push on Friday or Monday > -Cannot run dogtail on FC5 because dogtail is not available to brew > -How to handle dogtail testing on FC6 > -make it a postinstall test due to time to run tests > -How to handle errata: respin or backport? > -Hesitant to maintain a branch as is done for gcc toolchains > -Give people advance warning on when branch will be cut > > Regards - Wu Zhou From cagney@redhat.com Fri Sep 29 16:47:00 2006 From: cagney@redhat.com (Andrew Cagney) Date: Fri, 29 Sep 2006 16:47:00 -0000 Subject: getopt instead of jargs. In-Reply-To: <1159399147.2884.1.camel@tow.toronto.redhat.com> References: <1159399147.2884.1.camel@tow.toronto.redhat.com> Message-ID: <451D28E4.4000204@redhat.com> Thanks! Since this getopt comes from CLASSPATH, this lets us be more mainstream. Andrew Nurdin Premji wrote: > The transition from jargs to getopt is complete and jargs has been > completely removed from the cvs tree. > > make check on fc5 succeeds and all is good. > > Thank you, > Nurdin > > From mark@klomp.org Fri Sep 29 18:14:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 29 Sep 2006 18:14:00 -0000 Subject: Remove Code observers on exec Message-ID: <1159548458.3022.25.camel@dijkstra.wildebeest.org> Hi, This fixes bug #3255. When we get an execed event the process memory is overridden and we loose all breakpoints. This patch makes sure we purge all inserted and pending Code observers and adds a check for this to TestBreakpoints. I choose to just report deletedFrom() to any pending observers. The other choice was addFailed() which takes a Throwable as cause. But when interested in the reason it is better to watch for exec events. 2006-09-29 Mark Wielaard * BreakpointAddresses.java (removeAllCodeObservers): New method. * Task.java (codeObservers): Make package private. * TaskState.java (Running.handleExecedEvent): Clean up breakpoints. * TestBreakpoints.java: Check deletion of Code observers after exec. 2006-09-29 Mark Wielaard * funit-breakpoints.c (main): Reexec at the end of the loop. Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: breakpoints-exec-event.patch Type: text/x-patch Size: 6261 bytes Desc: not available URL: