Re: [Mono-dev] How to debug native code?

[Bill Seurer]

When I am debugging problems with native code I use gdb to debug it.  I 
have used other debuggers, too.


If you watch the commands that are running you should be able to see 
when the mono program is called.  Note the parameters.  Then run the 
debugger on mono and then run the program within the debugger using the 
parameters you noted.  When the segmentation fault occurs you can see 
where it happened.


If you add -v options on mono (try using more than one) you can get a 
trace of what native functions are called and the assembler for those 
functions.


Within the debugger you can use this command:

print mono_pmip($pc)

to see the name of the native function you are inside of.


On 01/18/16 20:14, Pin Cheng wrote:

Hi all,

I am trying to port Mono into Aix host, I have am very fundamental question:

How are you guys debug native code?

Because JIT compiler compiles assembly into native code then JIT invoke it,

I am very curious if there errors in native code How do you find out the
bug and fix it.

And if you updates the cpu-.md or -codegen.h how do you
verify your changes is ok?

There must be somewhat effect method to debug the JIT and it specific
architecture.

Since I am porting Mono into Aix, I got  assembler code which
disassembled from native code:

0: 7c 08 02 a6   mflrr0

4: 90 01 00 04  stw r0,4(r1)

8: 94 21 ff b0   stwur1,-80(r1)

c:  93 61 00 48  stw r27,72(r1)

   10:93 e1 00 4c  stw r31,76(r1)

   14:7c 3f 0b 78   mr  r31,r1

   18:90 7f 00 28   stw r3,40(r31)

   1c:90 9f 00 2c   stw r4,44(r31)

   20:90 bf 00 30   stw r5,48(r31)

   24:90 df 00 34   stw r6,52(r31)

   28:38 60 00 00  li  r3,0

   2c:90 7f 00 20   stw r3,32(r31)

   30:38 60 00 00  li  r3,0

   34:90 7f 00 24   stw r3,36(r31)

   38:80 7f 00 30   lwz r3,48(r31)

   3c:2c 03 00 00   cmpwi   r3,0

   40:41 82 00 a4  beq 0xe4

   44:3c 60 20 03   lis r3,8195

   48:60 63 e5 04  ori r3,r3,58628

   4c:80 63 00 00  lwz r3,0(r3)

   50:2c 03 00 00   cmpwi   r3,0

   54:41 82 00 38  beq 0x8c

   58:3d 80 30 3c  lis r12,12348

   5c:61 8c cd d8  ori r12,r12,52696

   60:7d 88 03 a6  mtlrr12

   64:4e 80 00 21  blrl

   68:7c 64 1b 78  mr  r4,r3

   6c:7c 9b 23 78  mr  r27,r4

   70:2c 03 00 00   cmpwi   r3,0

   74:41 82 00 18  beq 0x8c

   78:7f 63 db 78  mr  r3,r27

   7c:3d 80 30 00  lis r12,12288

   80:61 8c 82 90   ori r12,r12,33424

   84:7d 88 03 a6  mtlrr12

   88:4e 80 00 21  blrl

   8c:80 7f 00 2c   lwz r3,44(r31)

   90:80 83 00 00  lwz r4,0(r3)

   94:80 7f 00 28   lwz r3,40(r31)

   98:80 bf 00 34   lwz r5,52(r31)

   9c:7c a8 03 a6   mtlrr5

   a0:4e 80 00 21  blrl

   a4:48 00 00 38  b   0xdc

   a8:80 7f 00 1c   lwz r3,28(r31)

   ac:80 7f 00 1c   lwz r3,28(r31)

   b0:90 7f 00 24   stw r3,36(r31)

   b4:80 7f 00 30   lwz r3,48(r31)

   b8:80 9f 00 24   lwz r4,36(r31)

   bc:90 9f 00 40   stw r4,64(r31)

   c0:90 83 00 00  stw r4,0(r3)

   c4:3d 80 30 3c  lis r12,12348

   c8:61 8c cf 50ori r12,r12,53072

   cc: 7d 88 03 a6  mtlrr12

   d0:4e 80 00 21  blrl

   d4:80 7f 00 40   lwz r3,64(r31)

   d8:48 00 00 04  b   0xdc

   dc:80 7f 00 20   lwz r3,32(r31)

   e0:48 00 00 38  b   0x118

   e4:3c 60 20 03   lis r3,8195

   e8:60 63 e5 04  ori r3,r3,58628

   ec:80 63 00 00  lwz r3,0(r3)

   f0: 28 03 00 00  cmplwi  r3,0

   f4: 40 82 00 40  bne 0x134

   f8: 48 00 00 04  b   0xfc

   fc: 80 7f 00 2c   lwz r3,44(r31)

100:   80 83 00 00  lwz r4,0(r3)

104:   80 7f 00 28   lwz r3,40(r31)

108:   80 bf 00 34   lwz r5,52(r31)

10c:   7c a8 03 a6   mtlrr5

110:   4e 80 00 21  blrl

114:   80 7f 00 20   lwz r3,32(r31)

118:   80 1f 00 54   lwz r0,84(r31)

11c:  

Re: [Mono-dev] Strange build problem

[Alexander Köplinger]

Hey,

Are you sure you’re running this on the nealef-s390x-2 machine and not 
nealef-s390x-1 ?
This sounds exactly like the problem with the ancient gcc we ran into on the -1 
machine, that’s why we’re only using the -2 machine on Jenkins now.

In fact, my IRC log shows we discussed this back in October 2015:

 neale: still no success compiling on nealef-s390x-1, with -O2
 
https://jenkins.mono-project.com/job/z/label=centos-s390x/2065/parsed_console/log_content.html#ERROR1
 System/AndroidPlatform.cs(66,246): error CS1525: Unexpected symbol 
`end-of-file', expecting `end-of-file'
 ._.
 directhex: At least it got rid of the inline errors problem ;-)
 yes this is technically true
 I've never seen this particular problem before
 maybe a checkout problem? want to delete the workspace?
 The z workspace?
 hmm, it affects all files that are completely #ifdefed out
 Yup
 neale: yes
 z gone\
 it's renamed to "z" because the same job also handles windows 
builds, and windows has a silly low PATH_MAX
 which the old name was causing errors for
 Ah
 so single-char job names if they run on windows
 I ran a build in 
/home/jenkins/workspace/test-mono-mainline-communityarchitectures/label/centos-s390x
 (From Sep28) and forced a recompile of Android.cs which has the same ifdef 
situation and the build was clean.
 that job name is the old "z" job
 see, very long name, poor windows
 Understood, just wanted to point out that a build used to work for 
those files

AFAIK we never got past that problem on the -1 machine, so we just stopped 
using it.

- Alex

> Am 20.01.2016 um 03:13 schrieb Neale Ferguson :
> 
> Re: bugzilla 37781
> 
> On the same virtual machine in which the Jenkins bot successfully builds
> mono, I am encountering failures of an unusual type. Thinking it might be
> a hangover to something in the account’s home directory, I created a
> completely new account, cloned from master, configured and built. It craps
> out with the following:
> 
> MCS [build] mscorlib.dll
> Assembly/AssemblyInfo.cs(33,5): error CS8025: Parsing error
> System/AndroidPlatform.cs(66,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/Console.iOS.cs(127,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/Guid.MonoTouch.cs(24,253): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/TimeZoneInfo.Android.cs(737,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/TimeZoneInfo.MonoTouch.cs(109,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System.Globalization/RegionInfo.MonoTouch.cs(54,246): error CS1525:
> Unexpected symbol `end-of-file', expecting `end-of-file'
> System.IO/LogcatTextWriter.cs(80,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System.Security/SecurityManager_mobile.cs(215,246): error CS1525:
> Unexpected symbol `end-of-file', expecting `end-of-file'
> System.Security.Cryptography/CryptoConfig.fullaot.cs(239,246): error
> CS1525: Unexpected symbol `end-of-file', expecting `end-of-file'
> ../../../external/referencesource/mscorlib/system/resources/__hresults.cs(2
> 6,246): error CS1525: Unexpected symbol `end-of-file', expecting
> `end-of-file'
> ../../../external/referencesource/mscorlib/system/resources/looselylinkedre
> sourcereference.cs(89,246): error CS1525: Unexpected symbol `end-of-file',
> expecting `end-of-file'
> Compilation failed: 12 error(s), 0 warnings
> 
> I am at a loss to work out WTF is happening. I like the way the error
> message keeps a straight face when it complains about encountering
> “end-of-file” symbol when it was really expecting “end-of-file”!
> 
> 
> Any suggestions about where to look?
> 
> Neale
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list