Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[sre] Use MonoClass getters in sre-save.c #7352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
luhenry merged 3 commits into from
Mar 4, 2018
Merged

[sre] Use MonoClass getters in sre-save.c #7352

luhenry merged 3 commits into from
Mar 4, 2018

Conversation

@lambdageek
Copy link
Member

@lambdageek lambdageek commented Feb 28, 2018 •
edited by luhenry
Loading

Mostly mechanical.

There was ONE ISSUE:

In mono_image_fill_export_table there's an assignment to type_token:

klass->type_token = mono_metadata_make_token (MONO_TABLE_TYPEDEF, tb->table_idx);

mono/mono/metadata/sre-save.c

Lines 1260 to 1274 in ddf4e7b

mono_image_fill_export_table (MonoDomain *domain, MonoReflectionTypeBuilder *tb,
guint32 module_index, guint32 parent_index, MonoDynamicImage *assembly,
MonoError *error)
{
MonoClass *klass;
guint32 idx, i;
error_init (error);
MonoType *t = mono_reflection_type_get_handle ((MonoReflectionType*)tb, error);
return_if_nok (error);
klass = mono_class_from_mono_type (t);
klass->type_token = mono_metadata_make_token (MONO_TABLE_TYPEDEF, tb->table_idx);

I don't understand why that's there - Wouldn't the type token already be computed for every type builder by now? Why is it okay to change it?

/attn @vargaz

#6925

@marek-safar marek-safar mentioned this pull request Feb 28, 2018
Open
19 tasks
@vargaz
Copy link
Contributor

vargaz commented Feb 28, 2018

Probably because type tokes are recomputed since some tables need to be sorted or something.

@lambdageek
Copy link
Member Author

lambdageek commented Feb 28, 2018 •
edited
Loading

@vargaz so I'm going to argue that that assignment is redundant, let's see if you believe me:

  1. First thing in mono_image_fill_export_table we call mono_reflection_type_get_handle on a MonoReflectionTypeBuilder
  2. That ends up calling mono_reflection_type_handle_mono_type and falls into the is_sre_type_builder branch.
  3. From there we call reflection_setup_internal_class and reflection_setup_internal_class_internal
  4. Which is, thankfully, the only place is sre.c that assigns to type token: 
       klass->type_token = MONO_TOKEN_TYPE_DEF | table_idx;

Which is, I think, the same exact value that sre-save wants to put in there.

I left a g_warning in sre-save.c if the tokens ever don't match. Maybe if we don't see the warning for a while, we can take out that assignment.

kumpera
kumpera approved these changes Mar 1, 2018
View reviewed changes
Copy link
Contributor

@kumpera kumpera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. That assignment is odd but I don't think a g_warning will provide us enough visibility into possible issues.

mono/metadata/sre-save.c Outdated
Copy link
Contributor

@kumpera kumpera Mar 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe PR/locally tests this with a g_error instead and see if anything pops up?

Copy link
Contributor

@vargaz vargaz Mar 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make it a g_error () instead.

@lambdageek
[sre-save] Emit a warning if overwriting a MonoClass token with unequ…
2138334 
…al value

It's not clear to me how we could ever have a class without a type_token set
even with a TypeBuilder.
@lambdageek
[sre-save] Use MonoClass getters in sre-save.c
cb2f887
@lambdageek
[sre-save] Change g_warning to g_error in mono_image_fill_export_table
1bd77d9 
We think this case should not happen.
@lambdageek lambdageek force-pushed the use-getters-sre-save branch from 1e8a073 to 1bd77d9 Compare March 1, 2018 22:37
@lambdageek
Copy link
Member Author

lambdageek commented Mar 1, 2018

Changed the g_warning to a g_error, let's see what happens.

@lambdageek
Copy link
Member Author

lambdageek commented Mar 1, 2018

@slide This may affect IronPython (and the DLR in general).

Specifically mono may now crash with a message TypeBuilder token %08x does not match klass token %08x after an AssemblyBuilder.Save call. It looks like IronPython uses AssemblyBuilderAccess.Save sometimes, so if there are IronPython tests for that, it's worth grabbing a binary package of this PR and trying it out.

@lambdageek
Copy link
Member Author

lambdageek commented Mar 2, 2018

@monojenkins build pkg

@lambdageek
Copy link
Member Author

lambdageek commented Mar 2, 2018

@monojenkins build deb

@luhenry
Copy link
Contributor

luhenry commented Mar 3, 2018

@monojenkins build Linux ARMv7 Interpreter

@luhenry luhenry merged commit 9725d50 into mono:master Mar 4, 2018
@slide
Copy link
Contributor

slide commented Mar 12, 2018

Where do the binary packages get saved?

@lambdageek
Copy link
Member Author

lambdageek commented Mar 12, 2018 •
edited
Loading

@slide the packages from this PR are at
mono-snapshot-pull-request-7352-2018.03.03+12.13.09-assemblies_2018.03.03+12.13.09-1_all.deb
mono-snapshot-pull-request-7352-2018.03.03+12.13.09_2018.03.03+12.13.09-1_amd64.deb
and https://jenkins.mono-project.com/job/build-package-osx-mono-pullrequest/84/

Also the Mono nightly packages since March 5 will include these changes.

Update: fixed the linux links

@lambdageek lambdageek deleted the use-getters-sre-save branch March 28, 2018 18:26
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@lambdageek @luhenry
[sre] Use MonoClass getters in sre-save.c (mono/mono#7352)
1b9e222 
* [sre-save] Emit a warning if overwriting a MonoClass token with unequal value

It's not clear to me how we could ever have a class without a type_token set
even with a TypeBuilder.

* [sre-save] Use MonoClass getters in sre-save.c

* [sre-save] Change g_warning to g_error in mono_image_fill_export_table

We think this case should not happen.


Commit migrated from mono/mono@9725d50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vargaz vargaz Awaiting requested review from vargaz

1 more reviewer

@kumpera kumpera kumpera approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@lambdageek @vargaz @luhenry @slide @kumpera