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 <umesh.b2...@gmail.com> 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 <sa...@umich.edu> 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 <umesh.b2...@gmail.com> 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 <ksew...@umich.edu> 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
>> <mitch.hayenga+g...@gmail.com> 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 <umesh.b2...@gmail.com> 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
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>>
>> --
>> - Korey
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
