Skip to content
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.

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

Silverlight compilation issue #60

Closed
wants to merge 1 commit into from
Closed

Silverlight compilation issue #60

wants to merge 1 commit into from

Conversation

DenysVuika
Copy link

I've fixed Silverlight compilation related issue.

@jbevain
Copy link
Owner

jbevain commented Feb 26, 2011

Fixed in master. Thanks!

sbomer added a commit to sbomer/cecil that referenced this pull request Jan 10, 2023
This ensures that section starts are aligned by adjusting the
previous Range's length to ensure the computed start of a new
Range meets the alignment requirements. It was done this way
rather than just computing an aligned start for the new Range,
because the TextMap assumes that the Ranges are contiguous - see
for example GetNextRVA.

GetNextRVA was used to compute the Code RVA, before adding that
segment to the TextMap. This meant that the alignment (only added
later) wasn't taken into account when writing out the code, but
then later the TextMap was modified to include the alignment.

This is fixed by first inserting an aligned zero-length Code
segment before writing the code, then inserting it again once the
length is known. Removing the Code alignment altogether would
work too, but the alignment constants are kept in there, because
it looks like they were added intentionally, even though the
reason is unknown.

Note that before this change, the start of the Code segment (at
least on x64) was not 16-byte aligned in the first place, so this
change will actually move the beginning of the Code segment.
sbomer added a commit to sbomer/cecil that referenced this pull request Jan 10, 2023
This ensures that section starts are aligned by adjusting the
previous Range's length to ensure the computed start of a new
Range meets the alignment requirements. It was done this way
rather than just computing an aligned start for the new Range,
because the TextMap assumes that the Ranges are contiguous - see
for example GetNextRVA.

GetNextRVA was used to compute the Code RVA, before adding that
segment to the TextMap. This meant that the alignment (only added
later) wasn't taken into account when writing out the code, but
then later the TextMap was modified to include the alignment.

This is fixed by first inserting an aligned zero-length Code
segment before writing the code, then inserting it again once the
length is known. Removing the Code alignment altogether would
work too, but the alignment constants are kept in there, because
it looks like they were added intentionally, even though the
reason is unknown.

Note that before this change, the start of the Code segment (at
least on x64) was not 16-byte aligned in the first place, so this
change will actually move the beginning of the Code segment.
vitek-karas pushed a commit to vitek-karas/cecil that referenced this pull request Jun 15, 2023
This ensures that section starts are aligned by adjusting the
previous Range's length to ensure the computed start of a new
Range meets the alignment requirements. It was done this way
rather than just computing an aligned start for the new Range,
because the TextMap assumes that the Ranges are contiguous - see
for example GetNextRVA.

GetNextRVA was used to compute the Code RVA, before adding that
segment to the TextMap. This meant that the alignment (only added
later) wasn't taken into account when writing out the code, but
then later the TextMap was modified to include the alignment.

This is fixed by first inserting an aligned zero-length Code
segment before writing the code, then inserting it again once the
length is known. Removing the Code alignment altogether would
work too, but the alignment constants are kept in there, because
it looks like they were added intentionally, even though the
reason is unknown.

Note that before this change, the start of the Code segment (at
least on x64) was not 16-byte aligned in the first place, so this
change will actually move the beginning of the Code segment.
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants