profile
viewpoint
Who? Me?! mark-i-m operating systems, compilers, distributed systems, and chocolate. A follower of Jesus Christ :)

mark-i-m/os2 18

x86_64 OS kernel with completely async userspace and single address space [WIP]

mark-i-m/os1 3

Simple x86 operating system kernel written in Rust (not actively maintained)

mark-i-m/jobserver 2

A jobserver for running experiments on test machines and copying results back.

mark-i-m/journey 2

Microbenchmarks for linux memory management system

mark-i-m/bus 1

Hacky CLI Utility to help me with buses...

mark-i-m/isb350c 1

A toy implementation of the ISB in verilog for our toy processor.

mark-i-m/backlight 0

Simple program to update the backlight brightness on my laptop

mark-i-m/BaseConverter 0

Converts any base (2 to 35) integer to any other base (2 to 35)

mark-i-m/beta.rust-lang.org 0

the home of the new rust website - now in beta!

mark-i-m/blog.rust-lang.org 0

The Rust Programming Language Blog

push eventmark-i-m/rustc-guide

Yuki Okushi

commit sha 84d2a48f81b1acffe744cb54dada157a7b376591

Update section following current state

view details

Mark Mansi

commit sha d2e17ebf9c68f1dd2c801e9578a94aff3307317c

fix link

view details

Mark Mansi

commit sha b9689eb4b922934f8bd727c7f14c0a430a6d55c0

document ./x.py fmt

view details

push time in 19 minutes

push eventmark-i-m/rustc-guide

Yuki Okushi

commit sha 84d2a48f81b1acffe744cb54dada157a7b376591

Update section following current state

view details

Mark Mansi

commit sha d2e17ebf9c68f1dd2c801e9578a94aff3307317c

fix link

view details

Mark Mansi

commit sha 6322f58018fa45441f31715cc08669fe2f1d2896

spit of type folder and generics subchapters

view details

push time in 19 minutes

push eventmark-i-m/rustc-guide

Yuki Okushi

commit sha 84d2a48f81b1acffe744cb54dada157a7b376591

Update section following current state

view details

Mark Mansi

commit sha d2e17ebf9c68f1dd2c801e9578a94aff3307317c

fix link

view details

Mark Mansi

commit sha 7595e7bdc0d9592ec9b7935421de5098131aa9ba

create a separate chapter on arenas/interning

view details

Mark Mansi

commit sha cc85b2cb00981cdc036d9f7134bac87fb2632ead

update glossary

view details

push time in 20 minutes

push eventmark-i-m/rustc-guide

Yuki Okushi

commit sha 84d2a48f81b1acffe744cb54dada157a7b376591

Update section following current state

view details

Mark Mansi

commit sha d2e17ebf9c68f1dd2c801e9578a94aff3307317c

fix link

view details

push time in 20 minutes

push eventrust-lang/rustc-guide

Mark Mansi

commit sha d2e17ebf9c68f1dd2c801e9578a94aff3307317c

fix link

view details

push time in 22 minutes

PR merged rust-lang/rustc-guide

Fix link
+1 -1

0 comment

1 changed file

mark-i-m

pr closed time in 22 minutes

PR opened rust-lang/rustc-guide

Fix link
+1 -1

0 comment

1 changed file

pr created time in 2 hours

create barnchmark-i-m/rustc-guide

branch : fix-link-6

created branch time in 2 hours

startedTaaitaaiger/jlrs

started time in 4 hours

startedmatthiasbeyer/imag

started time in 4 hours

issue commentrust-lang/rustc-guide

Commit copies of papers?

Actually, I'm coming around to the position that linking to ACM DL or IEEE Explore when possible would be preferable -- though I don't think all of the linked documents are in ACM or IEEE.

mark-i-m

comment created time in 5 hours

pull request commentrust-lang/rustc-guide

Add diagnostics ICE-breakers page

Would it be possible to split the PR. The changes to the diagnostics chapter are nice and don't need to wait for the ICE breaker group to be set up.

estebank

comment created time in 5 hours

PR opened rust-lang/rustc-guide

Document ./x.py fmt

fixes #577

+9 -0

0 comment

1 changed file

pr created time in 5 hours

create barnchmark-i-m/rustc-guide

branch : fmt

created branch time in 5 hours

issue commentrust-lang/rustc-guide

Explain the technical parts of the Walkthrough somewhere

I think it mostly goes through parts of the front-end... I guess that chapter was aimed more at being about the processes of contribution, rather than technical content...

spastorino

comment created time in 5 hours

push eventrust-lang/rustc-guide

Yuki Okushi

commit sha 84d2a48f81b1acffe744cb54dada157a7b376591

Update section following current state

view details

push time in 5 hours

PR merged rust-lang/rustc-guide

Update section following current state

Follow-up for #580

r? @mark-i-m

+4 -5

0 comment

1 changed file

JohnTitor

pr closed time in 5 hours

PR opened rust-lang/rustc-guide

Split of type folder and generics subchapters

as discussed in #530

+251 -248

0 comment

4 changed files

pr created time in 5 hours

create barnchmark-i-m/rustc-guide

branch : ty-split

created branch time in 5 hours

PR opened rust-lang/rustc-guide

Interning chapter

as discussed in #530 and elsewhere

resolves #419

+121 -108

0 comment

6 changed files

pr created time in 5 hours

create barnchmark-i-m/rustc-guide

branch : alloc

created branch time in 5 hours

push eventmark-i-m/rustc-guide

Who? Me?!

commit sha f0a23c81ef5a801356b51ad4f404a144510aa92a

Fix broken links (#570)

view details

Who? Me?!

commit sha 0dde43f5798d6f6c0564d04d04d29ba9cab30a6e

Update README

view details

Wesley Wiser

commit sha 5bd60bc51efaec04e69e2e18b59678e2af066433

Add a mention of the new `-Zllvm-time-trace` flag

view details

Eduard-Mihai Burtescu

commit sha e69b9873578632b39f0f68bdd7b2ba7a21fbf2f1

mir: begin documenting user variable debuginfo. (#571)

view details

Felix S Klock II

commit sha d1ea643074707766807c17eeb53452ea4891c47c

Added example of icebreakers-cleanup-crew (I figure its low cost to just list all the possible pings, compared to the cost of people getting the command wrong or not even knowing the full set of teams possible.)

view details

Tomasz Miąsko

commit sha 693a92f2d20ed126a3661cd6975e35a5d99f9489

Update sanitizers documentation (#562)

view details

Youngsuk Kim

commit sha 2d834a7578fa2961cc141f0cc10436ed11e42216

minor typo fix

view details

Youngsuk Kim

commit sha 6480932518ecc53aca2ca2fffcbdeec37b57e4ac

minor typo fix

view details

Loris-intergalactique

commit sha cb4c20039df67c6ef630b0a7229bb94b2392ff3d

Minor typo correction

view details

Youngsuk Kim

commit sha df680be24bb9b29b858cc3e3f264975f8e083554

Correction of type name (#576) `ConstraintSet` => `OutlivesConstraintSet`

view details

Youngsuk Kim

commit sha d6a6122b951c475fb12f8c407016efa397460cfa

Add link to `rustc::mir::Location` (#579)

view details

Yuki Okushi

commit sha f53a6596231068760c7c4b2ac00e5b0e8702f3a6

Fix link

view details

LORIS INTERGALACTIQUE

commit sha 39dd586828a6ef747fb4b6207988094066a00685

Add links to the rustc docs (#578)

view details

push time in 6 hours

push eventmark-i-m/jobserver

Mark Mansi

commit sha 12e6ebb051faf572a8ced4c7c17427947b4aba9c

display help text more conveniently

view details

push time in a day

push eventrust-lang/rustc-guide

Yuki Okushi

commit sha f53a6596231068760c7c4b2ac00e5b0e8702f3a6

Fix link

view details

push time in 4 days

PR merged rust-lang/rustc-guide

Fix link

Also The macro parser section is outdated. But I'm really not familiar with macro parser. cc @spastorino

+1 -1

1 comment

1 changed file

JohnTitor

pr closed time in 4 days

pull request commentrust-lang/rustc-guide

Fix link

On the whole, the macro parser still works as described (I wrote that section)...

JohnTitor

comment created time in 4 days

pull request commentrust-lang/rustc-guide

Add links to the rustc docs

Overall looks good. Could you move all links to the bottom of the file? So that we can find them easily.

Is that something we want to enforce? I personally tend to put the link next to the thing I'm linking, but I'm fine if we want to change it. But if we are going to put all the links at the bottom, we should go through the whole book and do it everywhere, IMHO.

loris-intergalactique

comment created time in 4 days

pull request commentrust-lang/rfcs

RFC for unsafe blocks in unsafe fn

I have a vague inhibition against a new keyword, but I think this is mostly me resisting change... on the whole I think trusted/unsafe is a good distinction to make, and it definitely goes to the root of what was confusing me when I first tried to learn what "unsafe" means.

One thing to consider is that having two fairly rust-specific keywords increases the "weirdness factor" of Rust for new learners, but maybe it's not too bad.

RalfJung

comment created time in 4 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha ef8c9055f213d3d53f7c0d6af26dac1f6068f46d

add feature to hold or unhold jobs

view details

push time in 4 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha a157dd6dc15eab218ea0fe292f8fb2b470458d0c

go in order of job id

view details

push time in 4 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha adc4c6d0dc221876cee198d43dc5bb66dd9d5f35

tolerate canceling jobs that have not started

view details

push time in 4 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha 70f019f7af60f17fe4c4758378459692bfa09de7

free machines for setup tasks with no class

view details

push time in 4 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha 2d402462de712ea722f2f38da3a51b892ce63e00

stating -> status of, less confusing

view details

push time in 4 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha e603403664ab55c83142acb1578655732cf174f1

properly free machines after setup tasks

view details

push time in 4 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha dbfe4f69fcb33684481e7b43afb6f0f5ec75e359

correct checking before freeing machines

view details

push time in 4 days

delete branch mark-i-m/rust

delete branch : proper-linkcheck-2

delete time in 5 days

pull request commentrust-lang/rust

[WIP] Mark other variants as uninitialized after switch on discriminant

#68241 has merged

ecstatic-morse

comment created time in 5 days

push eventmultifacet/0sim

Mark Mansi

commit sha 6d592540db6b7eb09c98e9d4ae38786b500ea4c6

implement zerosim tracing

view details

push time in 5 days

issue commentrust-lang/rustc-guide

Commit copies of papers?

@JOE1994 That's definitely an option, but we don't link check links to ACM DL because they tend to produce failures... still I don't think we expect those links to every really fail, so maybe we don't need to check them?

mark-i-m

comment created time in 5 days

PR opened rust-lang/rust

Don't error on network failures

This should further reduce spurious failures.

r? @JohnTitor and/or @ehuss

+2 -0

0 comment

1 changed file

pr created time in 5 days

create barnchmark-i-m/rust

branch : proper-linkcheck-2

created branch time in 5 days

push eventmultifacet/0sim

Mark Mansi

commit sha 1c1c22366508a019b2a10865b01cb8aaae9bbd4a

Add ssdswap Also, print the bio error on swap write fail

view details

Mark

commit sha 2c32b7262d1b0bc71759d4d4abd31af4fcd859f1

Implement single- and multi- core TSC offsetting - Add sysfs and procfs parameters for many 0sim parameters - add procfs file to list vcpu offsets

view details

push time in 5 days

push eventmultifacet/0sim

Mark Mansi

commit sha 811506fb9fde5a8a7b67e45afa4d4929aed5a4a5

Make zswap use a radix-tree bitmap to track zero pages

view details

push time in 5 days

create barnchmultifacet/0sim

branch : dev-rebased-2

created branch time in 5 days

startedcli/cli

started time in 6 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha 0e590dbce7d2407c1848e4ca6a856f9c4403c024

fix path of stdout file

view details

push time in 6 days

push eventmultifacet/0sim

Mark Mansi

commit sha 9faaa514555299652ecc437a0cbd330587a2ab39

fix nvdimm driver

view details

push time in 6 days

push eventmultifacet/0sim

Mark Mansi

commit sha da5c8eb5edd7901aaec16c29a16c6293640026ff

update struct page size

view details

push time in 6 days

push eventmark-i-m/jobserver

Mark Mansi

commit sha 640dc3147c9711cb24d90aa19a5cfad89f8bc3e4

better logging

view details

Mark Mansi

commit sha 3e034b0f78e9951a25cde36dc31f719884cfaff5

wake less often, but let client interaction trigger work

view details

push time in 6 days

create barnchmultifacet/0sim

branch : dev-rebased

created branch time in 6 days

push eventrust-lang/rustc-guide

Loris-intergalactique

commit sha cb4c20039df67c6ef630b0a7229bb94b2392ff3d

Minor typo correction

view details

push time in 6 days

PR merged rust-lang/rustc-guide

Minor typo correction

Hi !

A little typo in the Query pages. Happy to make my first little contribution !

Loris

+1 -1

0 comment

1 changed file

loris-intergalactique

pr closed time in 6 days

push eventrust-lang/rustc-guide

Youngsuk Kim

commit sha 6480932518ecc53aca2ca2fffcbdeec37b57e4ac

minor typo fix

view details

push time in 8 days

PR merged rust-lang/rustc-guide

minor typo fix

minor typo fix 😃

+1 -1

0 comment

1 changed file

JOE1994

pr closed time in 8 days

startedgoogle/marl

started time in 8 days

push eventrust-lang/rustc-guide

Youngsuk Kim

commit sha 2d834a7578fa2961cc141f0cc10436ed11e42216

minor typo fix

view details

push time in 8 days

PR merged rust-lang/rustc-guide

minor typo fix

Very minor typo fix...

+1 -1

0 comment

1 changed file

JOE1994

pr closed time in 8 days

create barnchmark-i-m/jobserver

branch : dev

created branch time in 8 days

push eventmark-i-m/rust

mark

commit sha ddb84fcc397984c007e84b1707cad5cd6423d89f

address some review comments/bugs

view details

push time in 10 days

Pull request review commentrust-lang/rust

Generalized article_and_description

 enum EntryKind<'tcx> {     Mod(Lazy<ModData>),     MacroDef(Lazy<MacroDef>),     Closure,-    Generator(Lazy!(GeneratorData<'tcx>)),+    Generator(Lazy<hir::GeneratorKind>),

It seems that doing this would require GeneratorData to be Copy, but that looks like a large struct that probably shouldn't be Copy...

mark-i-m

comment created time in 10 days

pull request commentrust-lang/rust

Generalized article_and_description

@matthewjasper What should I do about src/librustc_typeck/collect.rs which exceeds tidy's maximum number of lines (3004 lines)?

mark-i-m

comment created time in 10 days

pull request commentrust-lang/rust

Cleanup debuginfo generation a bit

cc @eddyb I think

bjorn3

comment created time in 10 days

pull request commentrust-lang/rustc-guide

Add diagnostics ICE-breakers page

Ping @estebank could you fix the typo indicated above? I think this is good to go after that.

estebank

comment created time in 11 days

pull request commentrust-lang/rust

replace the leak check with universes, take 2

@matthewjasper Perhaps retry?

nikomatsakis

comment created time in 11 days

startedsslab-gatech/libmpk

started time in 12 days

push eventrust-lang/rustc-guide

Felix S Klock II

commit sha d1ea643074707766807c17eeb53452ea4891c47c

Added example of icebreakers-cleanup-crew (I figure its low cost to just list all the possible pings, compared to the cost of people getting the command wrong or not even knowing the full set of teams possible.)

view details

push time in 12 days

PR merged rust-lang/rustc-guide

Added example of icebreakers-cleanup-crew

(I figure its low cost to just list all the possible pings, compared to the cost of people getting the command wrong or not even knowing the full set of teams possible.)

+1 -0

0 comment

1 changed file

pnkfelix

pr closed time in 12 days

startedNukesor/pueue

started time in 12 days

issue commentrust-lang/rust

MBE (macro_rules!) pattern-matching is unnecessarily O(n) even in simple cases.

Yeah, $($foo)* to interpolate arbitrary Rust syntax.

@eddyb I should maybe clarify that when I say "valid rust", I mean syntactically, not semantically (e.g. there may still be type errors etc). Perhaps you can elaborate what you mean? How can this produce arbitrary rust syntax if $foo not a tt (or else is only used in a macro invocation)? We know what kind of token tree it is otherwise, so it is seems it should not be hard to check that the interpolated fragment at least syntactically fits there.

Why do we now care about usage?

I feel that current macro error messages are... not great. And I think this is largely due to the fact that it is very hard to check the body of a macro at definition time. Rather, we have to wait for it to be instantiated so we can see what the whole thing expands too.

eddyb

comment created time in 12 days

startedtomaka/redshirt

started time in 12 days

startedrust-lang/measureme

started time in 12 days

issue commentrust-lang/rust

MBE (macro_rules!) pattern-matching is unnecessarily O(n) even in simple cases.

Admittedly, that one seems like a bit of a stretch, but It seems plausible if we say that you can only use a tt metavariable inside a call to a macro. The output of the macro has to be valid rust at some point anyway. Perhaps I'm forgetting something, though?

I thought you were worried about things like ambiguities or compatibility hazards in the patterns of a macro, not anything to do with what the macro expands to.

Most of my concerns are about the patterns, but the fact that a macro can expand to arbitrary things restricts what we can assume about it when checking usage of metavariables.

eddyb

comment created time in 12 days

issue commentrust-lang/rust

MBE: more checks at definition time

Sorry! It's been quite a while!

Given that this lint inherently has false positives (and false negatives), why is it a lint in the compiler instead of clippy?

At the time I proposed the lint, I didn't realize it would have false positives. Also, I don't know enough about clippy to know whether it would be able to implement these.

What is the future for this lint? Is it planned to stay a lint?

Personally, I think they should be enabled by default (at least some of them can be). However, there is a bit more discussion on #68836 ...

At the very least, I think this work has been really useful in giving us an understanding of some of the downsides of the current MBEs implementation and behavior.

mark-i-m

comment created time in 13 days

issue commentrust-lang/rust

MBE (macro_rules!) pattern-matching is unnecessarily O(n) even in simple cases.

@eddyb I agree with you in principle, but I guess I can't see how it can be done.

The hard part is that the current implementation (and thus the stable interface) allows all sorts of crazy things that makes it impossible to check almost anything very conclusively, as we discovered in #61053. For example, it is impossible to determine whether a macro_rules defines a new macro_rules without seeing the use site. This in turn means that we cannot have a complete check for whether all metavariables are well-defined at the definition site (since they may be defined at the call-site by a macro generated there).

In my opinion, we need to first RFC major restrictions on MBEs to make these checks possible to implement at all. In particular:

  • macros should not generate other macros (if you want to do that, use a proc-macro). This allows us to ensure that $var in the body of a macro arm necessarily is a reference to a metavar binding from the macro arm.
  • all the lints from #61053 become hard errors.
  • the body of a macro arm must be valid rust syntax (i.e. you can't emit weird token streams for consumption by another macro).

There are a few other improvements that were identified in #61053 too, which would be good to implement...

Also, cc @ia0 who was involved in implementing those lints...

eddyb

comment created time in 13 days

startedaep/zz

started time in 13 days

issue commentrust-lang/rust

MBE (macro_rules!) pattern-matching is unnecessarily O(n) even in simple cases.

To be more concrete, I think we should focus on decl_macros, making them less expressive as needed (more advanced use cases should use proc-macros). Basically, I think we should be able to fully implement the checks from https://github.com/rust-lang/rust/issues/61053 without any hacks or heuristics; the checks should be sound, complete, and as early as possible.

eddyb

comment created time in 13 days

startedmatplotlib/matplotlib

started time in 13 days

issue commentrust-lang/rust

MBE (macro_rules!) pattern-matching is unnecessarily O(n) even in simple cases.

I'm personally not in favor of complicating the mbe implementation more. It's already quite hard to understand and reason about, and it has a lot of weird corner cases (i.e. allowing surprising behavior) despite our best efforts. If more time is spent on the mbe implementation, I would say it should be to redo the algorithm from scratch and replace it in the next edition or as after a crater run.

eddyb

comment created time in 13 days

startedsorbet/sorbet

started time in 14 days

push eventmultifacet/0sim-workspace

Deployment Bot (from Travis CI)

commit sha 9e6501ca88464f0e33797753f4598fcf35611907

Deploy multifacet/0sim-workspace to github.com/multifacet/0sim-workspace.git:gh-pages

view details

push time in 14 days

push eventmultifacet/0sim-workspace

Mark Mansi

commit sha 58b97156647c2e108f79d9566066db29d9967f06

change branch name to master

view details

push time in 14 days

delete branch multifacet/0sim

delete branch : markm_ztier

delete time in 14 days

delete branch multifacet/0sim

delete branch : markm_ztier-dev

delete time in 14 days

PR closed multifacet/0sim

[v4.4] Diff markm_ztier
+5138 -776

0 comment

48 changed files

mark-i-m

pr closed time in 14 days

PR closed multifacet/0sim

[v4.4] Diff markm_ztier-dev

This PR is just here as a convenient way of seeing the total diff against kernel tag v4.4...

+4587 -776

0 comment

45 changed files

mark-i-m

pr closed time in 14 days

create barnchmultifacet/0sim

branch : dev

created branch time in 14 days

create barnchmultifacet/0sim

branch : master

created branch time in 14 days

push eventmultifacet/0sim

markm

commit sha 39c71116fa3f618bee324e8dbb20620f344aea5b

fix perf build on centos 7

view details

H.J. Lu

commit sha e8f580d802014aa667b8245df0bc600f11741e15

x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

view details

Mark Mansi

commit sha d86ade081d6e1b31ab0c5d2ad67815db9eb54e8a

add 0sim users guide

view details

Mark Mansi

commit sha 00aa89a8392d3466e3d11f777dc384f856dfed74

update readme

view details

Mark Mansi

commit sha fe0d9836da738a4cf208694a99c8411ace2eaeaa

add compile_commands.json to gitignore

view details

Mark Mansi

commit sha af34632140f1f760cd6bd892bbaca8312c21e0fd

Make zswap use a radix-tree bitmap to track zero pages

view details

Mark Mansi

commit sha 5eeb20356a41a2f36786d3169dc1182af89325ca

Add ssdswap Also, print the bio error on swap write fail

view details

Mark

commit sha 871345d7952e6199f4dcb6598a709c53b8f53c49

Implement single- and multi- core TSC offsetting - Add sysfs and procfs parameters for many 0sim parameters - add procfs file to list vcpu offsets

view details

Mark Mansi

commit sha a894126457b2ec5d6bb3e068de3dd7eb3bbee430

implement zerosim tracing

view details

push time in 14 days

create barnchmultifacet/0sim

branch : markm-ztier-old

created branch time in 14 days

push eventmultifacet/0sim

H.J. Lu

commit sha 718850ce1c5ad587f6a70f93be0d2b2c2ff89397

x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 On i386, there are 2 types of PLTs, PIC and non-PIC. PIE and shared objects must use PIC PLT. To use PIC PLT, you need to load _GLOBAL_OFFSET_TABLE_ into EBX first. There is no need for that on x86-64 since x86-64 uses PC-relative PLT. On x86-64, for 32-bit PC-relative branches, we can generate PLT32 relocation, instead of PC32 relocation, which can also be used as a marker for 32-bit PC-relative branches. Linker can always reduce PLT32 relocation to PC32 if function is defined locally. Local functions should use PC32 relocation. As far as Linux kernel is concerned, R_X86_64_PLT32 can be treated the same as R_X86_64_PC32 since Linux kernel doesn't use PLT. R_X86_64_PLT32 for 32-bit PC-relative branches has been enabled in binutils master branch which will become binutils 2.31. [ hjl is working on having better documentation on this all, but a few more notes from him: "PLT32 relocation is used as marker for PC-relative branches. Because of EBX, it looks odd to generate PLT32 relocation on i386 when EBX doesn't have GOT. As for symbol resolution, PLT32 and PC32 relocations are almost interchangeable. But when linker sees PLT32 relocation against a protected symbol, it can resolved locally at link-time since it is used on a branch instruction. Linker can't do that for PC32 relocation" but for the kernel use, the two are basically the same, and this commit gets things building and working with the current binutils master - Linus ] Signed-off-by: H.J. Lu <hjl.tools@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

view details

push time in 14 days

pull request commentrust-lang/rust

implement proper linkchecker hardening

It broke on my other machine, so I pushed a fix. I also added a commit to update rustc-guide. It seems to be working locally.

mark-i-m

comment created time in 15 days

push eventmark-i-m/rust

Yuki Okushi

commit sha 6f5a61b5fb66987a32c25e3877f4f99e37ff067d

Use `next_point` to avoid ICE

view details

Yuki Okushi

commit sha c377ed606c1abfb240321f26cade940946c768e6

Fix ICE with save-analysis

view details

Matthew Jasper

commit sha a606ffdb174dd6a7d226d632994e6a885bf8a1ac

Avoid exponential behaviour when relating types

view details

Ralf Jung

commit sha ee601584403fa11563ed579d4c2cd5b747952056

add raw-addr-of variant to mir_raw_fat_ptr

view details

bors

commit sha 01db5819429352c4ab58f4760c29d6e4ca76d9a7

Auto merge of #68735 - JohnTitor:fix-ice-0202, r=estebank Use `next_point` to avoid ICE Fixes #68730 r? @estebank (I think you're familiar with that)

view details

bors

commit sha a2e80300cd83849dd4fa17af131e603623631bf6

Auto merge of #68756 - JohnTitor:fix-ice-save-analysis-2, r=davidtwco Fix ICE with save-analysis Fixes #68749 It should be fine since it's the same way as `visit_expr`.

view details

bors

commit sha 0d34a8772251b3f9d4dd05c81d9531d455a14fc2

Auto merge of #68772 - matthewjasper:relate-opt, r=davidtwco Avoid exponential behaviour when relating types When equating bound types we check subtyping in both directions. Since closures are invariant in their substs, we end up comparing the two types an exponential number of times. If there are no bound variables this isn't needed. Closes #68061

view details

bors

commit sha c58e09f138075ce6b3079f41f9c2f192a15b896c

Auto merge of #68778 - RalfJung:raw-addr-of, r=eddyb add raw-addr-of variant to mir_raw_fat_ptr As suggested at https://github.com/rust-lang/rust/pull/48300#discussion_r372520388 r? @eddyb

view details

Eduard-Mihai Burtescu

commit sha 0b633c82f094d52a642b53cae64614ff097eebd8

rustc_codegen_ssa: split declare_local into create_dbg_var and dbg_var_addr.

view details

Eduard-Mihai Burtescu

commit sha f4b74773c730e7afb6e81aa90df3ddade7442b60

rustc_codegen_ssa: convert mir::VarDebugInfo into a custom PerLocalVarDebugInfo.

view details

Eduard-Mihai Burtescu

commit sha e35dfad5b8cfe12555c6b7459c75d4b78280bfb2

rustc_codegen_llvm: avoid redundant calls to span_start.

view details

bors

commit sha bdd946df3a7af6be0c075d5ab15f9845b3679364

Auto merge of #68665 - eddyb:debuginfo-early-create-var, r=nagisa codegen: create DIVariables ahead of using them with llvm.dbg.declare. Instead of having `rustc_codegen_llvm` bundle creation of a `DIVariable` and `llvm.dbg.declare` into a single operation, they are now two separate methods, and the `DIVariable` is created earlier, specifically when `mir::VarDebugInfo`s are being partitioned into locals. While this isn't currently needed, it's a prerequisite for #48300, which adds fragmented debuginfo, where one `mir::VarDebugInfo` has multiple parts of itself mapped to different `mir::Place`s. For debuggers to see one composite variable instead of several ones with the same name, we need to create a single `DIVariable` and share it between multiple `llvm.dbg.declare` calls, which are likely pointing to different MIR locals. That makes the `per_local_var_debug_info` partitioning a good spot to do this in, as we can create *exactly* one `DIVariable` per `mir::VarDebugInfo`, and refer to it as many things as needed. I'm opening this PR separately because I want to test its perf impact in isolation (see https://github.com/rust-lang/rust/pull/48300#issuecomment-580121438). r? @nagisa or @oli-obk cc @michaelwoerister @nikomatsakis

view details

mark

commit sha 0c0c31b11c5460ac25a6e8a478d414a56437e92d

implement proper linkchecker hardening

view details

Mark Mansi

commit sha adc8cd9680228c7d3d389387ce585e13f616ba93

update rustc-guide

view details

Mark Mansi

commit sha 5e086c842f7bfac58a3d836495dde5d8c194cccc

some cleanup/fixes

view details

push time in 15 days

delete branch rust-lang/rustc-guide

delete branch : mark-i-m-patch-1

delete time in 16 days

delete branch rust-lang/rustc-guide

delete branch : wesleywiser-patch-1

delete time in 16 days

push eventrust-lang/rustc-guide

Wesley Wiser

commit sha 5bd60bc51efaec04e69e2e18b59678e2af066433

Add a mention of the new `-Zllvm-time-trace` flag

view details

push time in 16 days

push eventrust-lang/rustc-guide

Who? Me?!

commit sha 0dde43f5798d6f6c0564d04d04d29ba9cab30a6e

Update README

view details

push time in 16 days

PR merged rust-lang/rustc-guide

Update README
+2 -2

1 comment

1 changed file

mark-i-m

pr closed time in 16 days

pull request commentrust-lang/rustc-guide

Update README

Wow you're fast!

mark-i-m

comment created time in 16 days

pull request commentrust-lang/rustc-guide

Update sanitizers documentation

Ping @tmiasko any updates?

tmiasko

comment created time in 16 days

more