This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 17 Jan 2016 13:24, Joel Brobecker wrote: > > > > this looks hairy and will require a good bit of unwinding. you shouldn't > > > > be defining your own sim_read/sim_write anymore. if you want memory, you > > > > should be using the common memory functions to attach it. if you want to > > > > simulate hardware, you should be using the WITH_HW framework. > > > > > > For the read/write functions, we have a feature read-before-write > > > feature which I don't think the current sim provides. > > > > i don't know what this feature is. could you elaborate ? > > We can configure the simulator to raise a warning/error when > a region of memory which hasn't been written/initialized yet > is being read. > > I think this is a debugging aid, to detect access to uninitialized > memory. this sounds like a useful feature we can add to the common core :) > > > There is > > > also a pre-initialization feature of the RAM to a certain value > > > to make execution more reliable when the program reads undefined > > > memory. What would you suggest we do? > > > > when you attach memory, the default is to be zero filled. we do this > > for all ports. that sounds pretty reliable to me :). > > > > if you want to use a diff value, you can do this from the command line: > > $ run --memory-fill 0xff --memory-size 10Mb ... > > > > did you need something else ? > > I think "need" is a slight overstatement in our context, but perhaps > we could have a to specify what byte value a port wants to use for > pre-filling the memory? I could see a #define that to provide a > common default which each sim could override for their own default; > and then, if people want, a configure option to force whatever value > they want, irrespective of the default chosen by the architecture. the default should be the same across architectures imo, and that default today is zero-filled memory. having a configure flag might be useful, but i'm not sure how many people would actually leverage it. especially when there are flags already (that i showed above) that do what they want. to clarify some background in case it helps: i see the simulator core as a bunch of generic building blocks. the arch port itself only adds support for the ISA (insns & registers) to the equation. once you get beyond that (e.g. the memory or devices), now you're talking about more building blocks than stuff that should be baked in/architecture defaults. so even if today all of the systems that have a visium cpu also initialize the system mem in a specific way, the visium arch core should not be doing any of that. this makes it very easy to take just the visium ISA and construct a new cpu from scratch that has new/different behavior and play around with things. when you do want behavior that matches an existing board, that's where the model framework comes into play. you can define specific cpu/system combinations that match existing products and users can pick those via the --model flag. does that make sense ? > The people who first implemented this visium simulator chose 0xff, > which is just as arbitrary as zero, but it just so happens that using > this value made me realize, when I wrote a test, that I was making an > invalid assumption, and that the test might actually bomb on me anytime. > At the time, I didn't see the problem because my memory region happened > to be initialized to zero, which is the assumption I was making. this can easily be dangerous when you write asm code, but i feel like this doesn't translate (that much) across to C code. static/uninitialized vars (i.e. bss) are required to be zero-initialized. people often run into trouble with uninitialized stack values, but you'd get same behavior there i think in the sim today as you would on a real system. > > currently the sim-trace module does not have output formats. i'm open > > to extending this so ports can add custom hooks to control it. can you > > provide a few sample lines ? would hooking at trace_generic be all you > > needed ? > > For that part, I discussed with Olivier Hainque, who is a lot more > familiar with the traces than I am; the outcome of the discussion > is that it's going to be easier to separate that feature from this > submission, so we'll simply ignore that part for now, because we are > both a bit short on time at the moment. i've started a wiki page here: https://sourceware.org/gdb/wiki/Sim/TODO feel free to add a bullet point there with sub points that outline your requirements. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |