I have a LLVM IR instruction as follows: store i32 %i.0, i32* %arrayidx, align 4 !0
Note that I attached a metadata !0 to the instruction. And for my purpose, this represents a metadata string which I have declared as follows:
!0 = !{!"hello"}
Now I try to read this using
if (Inst.getMetadata("hello"))
However, upon executing this, I get the following error:
opt: <stdin>:32:43: error: expected instruction opcode
store i32 %i.0, i32* %arrayidx, align 4 !0
Can someone please point out, what I may be doing wrong here?
Just posting to help anyone stuck with the same problem.
The metadata needs a name. So this works:
store i32 %i.0, i32* %arrayidx, align 4, !my_metadata !0
Related
Seems IW_PR_Schrittnummer is only referenced in 3 spots... where it's declared and where its read in the fbd routine... I guess what I'm asking is something writing a number to this variable... or what? If so how would I find it... also what is the action being performed by this first function block? looks like there are 4 inputs, Auto, is Auto Active, does tasknumber = 0, and is Press Free. if all 4 of these are true... then End Auto. Does that sound right??? someone else programmed this for a job that does work. The tags are in German.
1st FBD
Variable Reference
Variable Declaration
2nd fbd just for reference
The IW_PR_Schrittnummer is linked to input I/O using AT %ID716 command. So it gets its value from I/O memory. That basically means that "take this value from input memory at address 716 and the size is D (double word, 32 bits).
I'm not sure how you can check what is in that address when it's defined with direct addressing like this. Hopefully someone else knows a good tip for this!
More info about addresses: https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/18014401038842507.html&id=6547931155168793261
More info about addresses: https://help.codesys.com/webapp/_cds_at_declaration;product=codesys;version=3.5.15.0
That logic from your 1st image works as you said. So AutoFinde will be TRUE, if Auto, AutoAktiv, IstFrei are all TRUE and the input IW_PR_Schrittnummer is 0. Otherwise the AutoFinde will always be FALSE.
I have a variable of type Data in Swift code, using Xcode 10.1, called data. I can see it in the debugger, but I don't know where the actual values are stored. It should contain a letter (one byte) and three Uint8 values, all 0-255, so it should be 4 bytes. The first _length is shown to be 6, so i don't know what else could be added in (one reason I want to see what is actually in there) (below). But I do not understand where the binary value is. The _rawValue does not seem to be it because it contains 4.5 bytes. Perhaps it is a pointer, as it says "RawPointer"?
Where are the actual bytes stored?
Edit:
By setting a new variable equal to data[i], i did figure out the number of bytes is correct (I found the code was putting things in i didn't know). My string is, for example "!C 0 21 255 17", so 6 bytes.
However, I would still love to find an answer to my question: Is there way during debug to view the elements without creating new variables to inspect?
Create an extension of Data as follows:
extension Data {
public var bytes: [UInt8]
{
return [UInt8](self)
}
}
You can view the bytes of data during debugging as:
po data.bytes
Just type po data as NSData in the debug console. You will see the hex bytes like <066465666768>
I am having trouble debugging Swift Strings
func stringTest() {
let test1:String = "test1";
let test2:NSString = "test2";
// <-- Breakpoint here
println(test1);
println(test2);
}
If I set a breakpoint after these lines and try and print test1 I get the following error:
po test1
error: <REPL>:1:1: error: use of unresolved identifier 'test1'
test1
^
But I am able to print test2 successfully:
po test2
test2
It is a bug of Beta. Xcode6-Beta5 has still this bug.
You can only get debug info for swift's variables, but can't get it for swift's constants.
Temporarily you can change let test1 to var test1 and you will got debug info.
Hope this will be fixed in release version. Good Luck in debugging ;)
EDIT:
Unfortunately, the same issue is still happening in first release of Xcode Version 6.0.1 (6A317)
let test1:String -> debug info is unavailable
var test1:String -> debug info is available
EDIT2:
Yes, confirmed. It is fixed also for iOS apps in the latest Xcode 6.1 under OS X Yosemite.
This is most likely a bug in the debug information output. You can check this by grabbing the PC, for instance from register read pc, and then doing:
(lldb) image lookup -va <PC VALUE>
That will print a bunch of stuff, but the last entries will be all the variables currently visible to the debugger, and where they live (in registers or memory.) If you don't see the variable there, then the debug information must have told lldb that the variable is not currently live.
If you can reproduce this in some example code you can make available, please file a bug with bug reporter.apple.com.
I have a couple of issues with a basic UVM based TB I'm trying out to understand sequences and their working.
bvalid is being always picked as 0 in the driver when being updated in the response item
Couple of error messages for last 2 transactions (# UVM_ERROR # 18: uvm_test_top.axi_agent1.axi_base_seqr1##axi_base_seq1 [uvm_test_top.axi_agent1.axi_base_seqr1.axi_base_seq1] Response queue overflow, response was dropped)
Here is the link to the compiling code on EDA Playground
http://www.edaplayground.com/x/3x9
Any suggestions on what I'm missing??
Thanks
venkstart
Having a look at the specification for $urandom_range it shows the signature as: function int unsigned $urandom_range( int unsigned maxval, int unsigned minval = 0 ). Change your call to $urandom_range(1, 0) and it should work.
The second error comes from the fact that you are sending responses from the driver and not picking them up in your sequence. This is the line that does it: seq_item_port.item_done(axi_item_driv_src);. Either just do seq_item_port.item_done(); (don't send responses) or put a call to get_response() inside your sequence after finish_item(). What I usually do is update the fields of the original request and just call item_done(). For example, if I start a read transaction, in my driver I would drive the control signals and wait for the DUT to respond, update the data field of the request with the data I got from the DUT and call item_done() in my driver to mark the request as done. This way if I need this data in my sequence (to constrain some future item, for example) I have it.
I have some question for Cortex-A5 unaligned access exception
Basic System information blow
I and D cache enabled.
Disabled MMU.
Firmware base
In developing the DMA driver code I wrote the following C code.
UINT32 DMA_InstMOV(UINT8 *buf, tENC_RD rd, UINT32 val)
{
buf[0] = CMD_DMAMOV;
buf[1] = rd;
*((UINT32 *)&buf[2]) = val; // this line is exception occur
return SIZE_DMAMOV;
}
Dissamber the code above to check them as follows
DMA_InstMOV
0x00000bf8: e1a03000 .0.. MOV r3,r0
0x00000bfc: e3a000bc .... MOV r0,#0xbc
0x00000c00: e5c30000 .... STRB r0,[r3,#0]
0x00000c04: e5c31001 .... STRB r1,[r3,#1]
0x00000c08: e5832002 . .. STR r2,[r3,#2]
0x00000c0c: e3a00006 .... MOV r0,#6
0x00000c10: e12fff1e ../. BX lr
R3 Value is 0x08040000
STR instruction is executed with unaligned address Exception(Data Abort) occurs.
Cortex A5 is not support unaligned access?
In DDI0406C_b_arm_architecture_reference_manual.pdf(Table A3-1 Alignment requirements of load/store instructions)
LDM, STR is not support unaligned access.
So Data Exception occurs.
But I still have some question
This drivers code is working good in Cortex-R4 core. It didn’t have any problem.
Disassebly code is same.
This is even more confusing
Many linux drivers also use the above code.
If the MMU is turned on, which would solve this problem?
Let’s me know what’s worng for me?
You need to enable MMU for making an unaligned access in cortex A5. Also make sure the bitfield "A" in SCTLR register is set to 0 to ensure that strict alignment fault is disabled
As I see it, you can't do what you are trying if buf is 32-bit aligned.
The compiler doesn't know how buf is aligned, so it assumes you know what you are doing. If you ask for a 32-bit write (by doing something like *((UINT32 *)&buf[2])) then the compilers assumes it is a valid thing to do. It therefore generates a STR instruction, which is only valid for aligned stores. Hence the fault - as buf is 32-bit aligned (as you state), buf[2] is clearly not.
I have no idea why the Cortex-R4 experience should be different, as far as I can tell it operates with the same instruction set and alignment rules as the A5 (but I could be wrong). Maybe you got lucky and your bufs were unaligned such that buf[2] was 32-bit aligned.