Hi Ali,
There was just one issue, and not 2. As instructed by you, I added included
the full_system.hh file, and made some minor
changes to exetrace.cc, and now I can see the symbols being printed out for
SE mode.
I have created a review request at reviews.gem5.org, and the link is
http://reviews.gem5.org/r/1746/
The diff file is shown below :
diff -r 651aab570b4a src/cpu/exetrace.cc
--- a/src/cpu/exetrace.cc Mon Jan 28 09:18:52 2013 -0800
+++ b/src/cpu/exetrace.cc Wed Mar 06 16:23:41 2013 -0800
@@ -43,6 +43,7 @@
#include "cpu/thread_context.hh"
#include "debug/ExecAll.hh"
#include "enums/OpClass.hh"
+#include "sim/full_system.hh"
using namespace std;
using namespace TheISA;
@@ -83,13 +84,33 @@
std::string sym_str;
Addr sym_addr;
Addr cur_pc = pc.instAddr();
- if (debugSymbolTable && Debug::ExecSymbol && !inUserMode(thread)
- && debugSymbolTable->findNearestSymbol(cur_pc, sym_str, sym_addr))
{
- if (cur_pc != sym_addr)
- sym_str += csprintf("+%d",cur_pc - sym_addr);
- outs << "@" << sym_str;
- } else {
- outs << "0x" << hex << cur_pc;
+ if (FullSystem) { // Full System mode
+ if (debugSymbolTable && Debug::ExecSymbol && !inUserMode(thread)
+ && debugSymbolTable->findNearestSymbol(cur_pc, sym_str,
sym_addr)) {
+ if (cur_pc != sym_addr)
+ sym_str += csprintf("+%d",cur_pc - sym_addr);
+ outs << "@" << sym_str;
+ }
+ else {
+ outs << "0x" << hex << cur_pc;
+ }
+ }
+ else { // Syscall Emulation mode
+ if(debugSymbolTable && Debug::ExecSymbol &&
+ debugSymbolTable->findNearestSymbol(cur_pc, sym_str, sym_addr)) {
+ if (cur_pc != sym_addr)
+ sym_str += csprintf("+%d", cur_pc - sym_addr);
+ outs << "0x" << hex << cur_pc << " @" << sym_str;
+ }
+ else {
+ outs << "0x" << hex << cur_pc;
+ }
}
if (inst->isMicroop()) {
Thanks,
Umesh
On Tue, Mar 5, 2013 at 7:51 PM, Ali Saidi <[email protected]> wrote:
> Hi Umesh,
>
> Can you try to fix the issues you mentioned and let us know if that solves
> the problem (or post a patch to reviews.gem5.org)?
>
> For the first issue if you include sim/full_system.hh there is a variable
> called FullSystem that will be true if the simulator is in FS mode.
>
>
> As far as the second issue, in process.cc the symbol table is loaded for
> SE code. I'm not sure why you're not seeing anything, but you can use the
> debug-flag Loader to see all the symbols when the simulator starts.
>
> Thanks,
> Ali
>
>
>
> On Mar 4, 2013, at 2:20 PM, Umesh Bhaskar <[email protected]> wrote:
>
> Hi Mitch, Korey, Ali.
> Thanks for your responses to the question.
>
> I think there has been a miscommunication. I believe that there are 2
> separate issues
>
> Suspected bug 1 : If I am running gem5 in SE mode, then there is no
> kernel code to run, so inUserMode() will
> always return 1, which is correct. The problem is with the "if" condition
> (pasted below)
>
> *if (debugSymbolTable && Debug::ExecSymbol && !inUserMode(thread)*
> * && debugSymbolTable->findNearestSymbol(cur_pc, sym_str,
> sym_addr))*
>
>
> , which is checking for the return
> value of this function even though we are in SE mode. Ideally, the "if"
> condition should check for
> return value of inUserMode only if we are in FS mode.
>
> Suspected bug 2 : Another issue is that the Symbol table is being
> initialized, but my guess is that does not hold any
> symbols, because sym_str is getting a null string after the call to
> findNearestSymbol(). I suspect
> that a bug exists in the code wherein the Symbols are not getting
> registered for the ARM instruction set
> under SE mode.
>
> To help provide more information, I paste my version of the code and also
> the first 2 lines of the
> trace I get when I run with the pre-build Hello World binary
>
> *--- a/src/cpu/exetrace.cc Mon Jan 28 09:18:52 2013 -0800*
> *+++ b/src/cpu/exetrace.cc Mon Mar 04 12:14:39 2013 -0800*
> *@@ -90,6 +90,12 @@*
> * outs << "@" << sym_str;*
> * } else {*
> * outs << "0x" << hex << cur_pc;*
> *+ // added by umeshb*
> *+ outs << "\t@" << sym_str << endl;*
> *+ outs << "debugSymbolTable value : " << debugSymbolTable << endl;
> *
> *+ outs << "ExecSymbol value : " << Debug::ExecSymbol << endl;*
> *+ outs << "debugSymbolTable->findNearestSymbol returns string:"
> << sym_str << endl;*
> *+ outs << "inUserMode returns : " << inUserMode(thread) << endl; *
> * }*
>
>
> The trace looks like this :
>
> *34000: system.cpu T0 : 0x8150 @ *
> *debugSymbolTable value : 0x2f48340*
> *ExecSymbol value : 1*
> *debugSymbolTable->findNearestSymbol returns string:*
> *inUserMode returns : 1*
> * : ldr r12, [pc, #36] : MemRead : D=0x0000000000008960
> A=0x817c*
> * 34000: system.cpu T0 : 0x8154 @*
> *debugSymbolTable value : 0x2f48340*
> *ExecSymbol value : 1*
> *debugSymbolTable->findNearestSymbol returns string:*
> *inUserMode returns : 1*
> * : mov fp, #0 : IntAlu : D=0x0000000000000000*
>
> Thanks,
> Umesh
>
>
>
> On Sun, Mar 3, 2013 at 12:19 PM, Ali Saidi <[email protected]> wrote:
>
>> Hi Umesh,
>>
>> inUserMode is checked because we don't have any access to symbols from
>> user applications, on the kernel. So if we're executing some user mode
>> code, we shouldn't be printing symbols because there is no chance we have
>> some. There could be a bug with how we load the symbols for kernel mode
>> code however. A mask can be applied to that the symbols make sense before
>> translation is enabled, but perhaps that has something to do it. Can you
>> confirm you're not getting symbols while executing kernel code?
>>
>> Thanks,
>> Ali
>>
>> On Mar 1, 2013, at 7:18 PM, Umesh Bhaskar <[email protected]> wrote:
>>
>> I have an interesting update on this :
>> The file src/cpu/exetracer.cc
>>
>> has the following code snippet :
>>
>>
>> ******************************************************************************************
>> std::string sym_str;
>> Addr sym_addr;
>> Addr cur_pc = pc.instAddr();
>> if (debugSymbolTable && Debug::ExecSymbol && !inUserMode(thread)
>> && debugSymbolTable->findNearestSymbol(cur_pc, sym_str,
>> sym_addr)) {
>> if (cur_pc != sym_addr)
>> sym_str += csprintf("+%d",cur_pc - sym_addr);
>> outs << "@" << sym_str;
>> } else {
>> outs << "0x" << hex << cur_pc;
>>
>> ******************************************************************************************
>> There are 2 potential issues with this code/other code related to the
>> code here
>>
>> 1) The debugSymbolTable variable has the starting address of the symbol
>> table,
>> but the findNearestSymbol function returns a null string to sym_str. Why
>> is that
>> happening ? I know that the Symbol table exists because if I run the code
>> with
>> the flag "Loader", the Symbol table gets printed out to the trace
>>
>> 2) Also, the outer "if" statement checks for the value returned by the
>> inUserMode()
>> function, which always returns 1, so the "if" condition fails and the PC
>> value gets printed
>> out instead of the symbol
>>
>>
>>
>> Thanks,
>> Umesh
>>
>>
>> On Thu, Feb 28, 2013 at 6:07 PM, Korey Sewell <[email protected]> wrote:
>>
>>> It looks like the problem is the ARM ISA isn't dumping the function
>>> symbols despite using the "Exec" group debug flag (that flag group has
>>> "ExecSymbol" in it).
>>>
>>> Does anyone that worked on the ARM ISA have experience w/successfully
>>> generating the symbol table and getting that into trace output?
>>>
>>> If that works, Umesh can just generate the trace and "grep" for the
>>> relevant assembly instructions by function name (Assuming that function
>>> doesnt call other functions).
>>>
>>> -Korey
>>>
>>> On Thu, Feb 28, 2013 at 2:46 PM, Mitch Hayenga <
>>> [email protected]> wrote:
>>>
>>>> Not that I know of. For a poor man's version, since it seems you are
>>>> just trying to generate various traces from a region of interest.... You
>>>> could just use the existing m5ops to checkpoint @ the beginning of the
>>>> region of interest and exit @ the end. That way you could just run from
>>>> the checkpoint with the trace flags enabled.
>>>>
>>>> Alternatively, I bet it would be possible to define your own m5ops that
>>>> dynamically enable/disable trace flags. But that would take a bit of work
>>>> and hacking on the simulator.
>>>>
>>>>
>>>> On Thu, Feb 28, 2013 at 4:25 PM, Umesh Bhaskar
>>>> <[email protected]>wrote:
>>>>
>>>>> Hi Gem5 users,
>>>>>
>>>>> The command I issued is :
>>>>>
>>>>> build/ARM/gem5.debug --debug-flags=Exec configs/example/se.py -c
>>>>> tests/test-progs/hello/bin/arm/linux/hello
>>>>>
>>>>> One line from the trace is shown below:
>>>>>
>>>>> 2263500: system.cpu T0 : 0x9cf8.5 : ldr_uop r35, [r34, #16] :
>>>>> MemRead : D=0x00000000000511fc A=0xbefffcac
>>>>>
>>>>> I have a 2 part question
>>>>>
>>>>> 1) Is there anyway I can limit the tracing to just the main() or a
>>>>> subset of instructions inside the main function
>>>>> and not the preliminary setup instructions ? --trace-start is not very
>>>>> suitable for this since it is dependent on simulator
>>>>> ticks
>>>>>
>>>>> 2) If this is not possible, can I, in any way, dump the function and
>>>>> data structure names to the
>>>>> trace file, so that we can easily filter out information relating to a
>>>>> subset of instructions.
>>>>>
>>>>> Thanks,
>>>>> Umesh
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> [email protected]
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gem5-users mailing list
>>>> [email protected]
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>
>>>
>>>
>>> --
>>> - Korey
>>> _______________________________________________
>>> gem5-users mailing list
>>> [email protected]
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
