valgrind.bin - Trực tuyến trên đám mây

CHƯƠNG TRÌNH:

TÊN

valgrind - một bộ công cụ để gỡ lỗi và lập hồ sơ chương trình

SYNOPSIS

valgrind [tùy chọn valgrind] [chương trình của bạn] [tùy chọn chương trình của bạn]

MÔ TẢ

valgrind là một chương trình linh hoạt để gỡ lỗi và cấu hình các tệp thực thi Linux. Nó bao gồm
của một lõi, cung cấp một CPU tổng hợp trong phần mềm, và một loạt các gỡ lỗi và
các công cụ lập hồ sơ. Kiến trúc là mô-đun, do đó, các công cụ mới có thể được tạo dễ dàng và
mà không làm xáo trộn cấu trúc hiện có.

Một số tùy chọn được mô tả bên dưới hoạt động với tất cả các công cụ Valgrind và một số chỉ hoạt động với
một vài hoặc một. Phần MEMCHECK OPTIONS và những phần bên dưới mô tả công cụ cụ thể
tùy chọn.

Trang hướng dẫn sử dụng này chỉ bao gồm cách sử dụng cơ bản và các tùy chọn. Để biết thêm thông tin toàn diện,
vui lòng xem tài liệu HTML trên hệ thống của bạn:
$ INSTALL / share / doc / valgrind / html / index.html hoặc trực tuyến:
http://www.valgrind.org/docs/manual/index.html.

DỤNG CỤ LỰA CHỌN LỰA CHỌN

Lựa chọn quan trọng nhất.

--tool = [vỡ nợ: ghi nhớ]
Chạy công cụ Valgrind có tên tên công cụ, ví dụ như memcheck, cachegrind, callgrind, helgrind,
drd, massif, lackey, none, exp-sgcheck, exp-bbv, exp-dhat, v.v.

BASIC LỰA CHỌN

Các tùy chọn này hoạt động với tất cả các công cụ.

-h --Cứu giúp
Hiển thị trợ giúp cho tất cả các tùy chọn, cho cả lõi và cho công cụ đã chọn. Nếu tùy chọn
được lặp lại nó tương đương với cho --help-gỡ lỗi.

--help-gỡ lỗi
Giống như --Cứu giúpmà còn liệt kê các tùy chọn gỡ lỗi thường chỉ được sử dụng để
Các nhà phát triển của Valgrind.

--phiên bản
Hiển thị số phiên bản của lõi Valgrind. Các công cụ có thể có phiên bản riêng của chúng
những con số. Có một kế hoạch để đảm bảo rằng các công cụ chỉ thực thi khi lõi
là phiên bản mà họ được biết là sẽ làm việc cùng. Điều này được thực hiện để giảm thiểu cơ hội
các vấn đề lạ phát sinh do sự không tương thích giữa phiên bản công cụ và lõi.

-q, --Yên lặng
Chạy âm thầm và chỉ in các thông báo lỗi. Hữu ích nếu bạn đang chạy hồi quy
kiểm tra hoặc có một số máy móc kiểm tra tự động khác.

-v, --dài dòng
Dài dòng hơn. Cung cấp thêm thông tin về các khía cạnh khác nhau của chương trình của bạn, chẳng hạn như:
các đối tượng được chia sẻ được tải, các biện pháp ngăn chặn được sử dụng, tiến trình của thiết bị đo
và các công cụ thực thi, và cảnh báo về hành vi bất thường. Lặp lại tùy chọn
làm tăng mức độ chi tiết.

--trace-children = [vỡ nợ: không]
Khi được bật, Valgrind sẽ theo dõi các quy trình phụ được khởi tạo thông qua giám đốc điều hành hệ thống
gọi. Điều này là cần thiết cho các chương trình đa quy trình.

Lưu ý rằng Valgrind thực sự theo dõi con của một ngã ba (sẽ rất khó nếu không,
kể từ khi ngã ba tạo một bản sao giống hệt của một quy trình), vì vậy tùy chọn này được cho là không tốt
được đặt tên. Tuy nhiên, hầu hết trẻ em của ngã ba cuộc gọi gọi ngay lập tức giám đốc điều hành dù sao.

--trace-children-via = patt1, patt2, ...
Tùy chọn này chỉ có hiệu lực khi --trace-children = vâng được quy định. Nó cho phép
một số trẻ em bị bỏ qua. Tùy chọn này có một danh sách các mẫu được phân tách bằng dấu phẩy cho
tên của các tệp thực thi con mà Valgrind không nên theo dõi. Các mẫu có thể
bao gồm các siêu ký tự? và *, có nghĩa thông thường.

Điều này có thể hữu ích cho việc cắt tỉa các nhánh không quan tâm từ cây các quy trình đang được
chạy trên Valgrind. Nhưng bạn nên cẩn thận khi sử dụng nó. Khi Valgrind bỏ qua theo dõi
vào một tệp thực thi, nó không chỉ bỏ qua việc theo dõi tệp thực thi đó mà còn bỏ qua
truy tìm bất kỳ quy trình con nào của tệp thực thi đó. Nói cách khác, lá cờ không
chỉ khiến việc theo dõi dừng lại ở các tệp thực thi được chỉ định - nó bỏ qua việc theo dõi
toàn bộ quy trình con được bắt nguồn từ bất kỳ tệp thực thi nào được chỉ định.

--trace-children-ignore-by-arg = patt1, patt2, ...
Điều này cũng giống như --trace-trẻ em-bỏ qua, với một điểm khác biệt: quyết định
việc theo dõi một quá trình trẻ em có được thực hiện bằng cách kiểm tra các đối số đối với trẻ em hay không
quy trình, thay vì tên của tệp thực thi của nó.

--child-silent-after-fork = [vỡ nợ: không]
Khi được bật, Valgrind sẽ không hiển thị bất kỳ đầu ra gỡ lỗi hoặc ghi nhật ký nào cho trẻ
quá trình kết quả từ một ngã ba gọi. Điều này có thể làm cho đầu ra ít nhầm lẫn hơn (mặc dù
sai lầm hơn) khi xử lý các quy trình tạo ra trẻ em. Nó đặc biệt
hữu ích kết hợp với --trace-children =. Việc sử dụng tùy chọn này cũng rất
được khuyến nghị nếu bạn đang yêu cầu đầu ra XML (--xml = vâng), vì nếu không thì XML từ
con và cha mẹ có thể trở nên hỗn tạp, điều này thường khiến việc này trở nên vô ích.

--vgdb = [vỡ nợ: đúng]
Valgrind sẽ cung cấp chức năng "gdbserver" khi --vgdb = vâng or --vgdb = đầy đủ is
được chỉ định. Điều này cho phép trình gỡ lỗi GNU GDB bên ngoài kiểm soát và gỡ lỗi chương trình của bạn
khi nó chạy trên Valgrind. --vgdb = đầy đủ gánh chịu chi phí hiệu suất đáng kể, nhưng
cung cấp các điểm ngắt và điểm theo dõi chính xác hơn. Xem Gỡ lỗi chương trình của bạn bằng
Valgrind's gdbserver và GDB để có mô tả chi tiết.

Nếu gdbserver nhúng được bật nhưng không có gdb nào hiện đang được sử dụng, vgdb
tiện ích dòng lệnh có thể gửi "lệnh giám sát" đến Valgrind từ một trình bao. Các
Lõi Valgrind cung cấp một tập hợp các lệnh giám sát Valgrind. Một công cụ có thể tùy chọn
cung cấp các lệnh giám sát cụ thể của công cụ, được ghi lại trong công cụ cụ thể
chương.

--vgdb-error = [vỡ nợ: 999999999]
Sử dụng tùy chọn này khi gdbserver Valgrind được bật với --vgdb = vâng or --vgdb = đầy đủ.
Các công cụ báo lỗi sẽ đợi báo cáo lỗi "số" trước khi đóng băng
chương trình và đang chờ bạn kết nối với GDB. Nó theo sau đó là một giá trị bằng không
sẽ khiến gdbserver được khởi động trước khi chương trình của bạn được thực thi. Đây là
thường được sử dụng để chèn các điểm ngắt GDB trước khi thực thi và cũng hoạt động với các công cụ
không báo lỗi, chẳng hạn như Massif.

--vgdb-stop-at = [vỡ nợ: không ai]
Sử dụng tùy chọn này khi gdbserver Valgrind được bật với --vgdb = vâng or --vgdb = đầy đủ.
Valgrind gdbserver sẽ được gọi cho mỗi lỗi sau --vgdb-lỗi đã
đã báo cáo. Ngoài ra, bạn có thể yêu cầu gdbserver Valgrind được gọi cho
sự kiện, được chỉ định theo một trong những cách sau:

· Danh sách được phân tách bằng dấu phẩy của một hoặc nhiều khởi động ra valgrindabexit.

Giá trị khởi động ra valgrindabexit tương ứng chỉ ra để gọi gdbserver
trước khi chương trình của bạn được thực thi, sau lệnh cuối cùng của chương trình, trên
Xác nhận tình trạng thoát bất thường (ví dụ: lỗi bên trong, hết bộ nhớ, ...).

Lưu ý: khởi động và --vgdb-error = 0 cả hai sẽ khiến cho gdbserver Valgrind được gọi ra
trước khi chương trình của bạn được thực thi. Các --vgdb-error = 0 Ngoài ra sẽ gây ra
chương trình để dừng tất cả các lỗi tiếp theo.

· tất cả các để chỉ định tập hợp hoàn chỉnh. Nó tương đương với
--vgdb-stop-at = khởi động, thoát, valgrindabexit.

· không ai cho tập hợp trống.

--track-fds = [vỡ nợ: không]
Khi được bật, Valgrind sẽ in ra danh sách các bộ mô tả tệp đang mở khi thoát hoặc bật
yêu cầu, thông qua lệnh giám sát gdbserver v.thông tin open_fds. Cùng với mỗi tệp
bộ mô tả được in ra một dấu vết ngăn xếp về nơi tệp đã được mở và bất kỳ chi tiết nào
liên quan đến bộ mô tả tệp, chẳng hạn như tên tệp hoặc chi tiết ổ cắm.

--time-tem = [vỡ nợ: không]
Khi được bật, mỗi thông báo được đặt trước bằng một chỉ báo về việc ép xung đã trôi qua
thời gian kể từ khi khởi động, được biểu thị bằng ngày, giờ, phút, giây và mili giây.

--log-fd = [vỡ nợ: 2, tiêu chuẩn]
Chỉ định rằng Valgrind sẽ gửi tất cả các thông điệp của nó đến tệp được chỉ định
bộ mô tả. Mặc định, 2, là kênh lỗi chuẩn (stderr). Lưu ý rằng điều này có thể
can thiệp vào việc sử dụng stderr của chính khách hàng, vì đầu ra của Valgrind sẽ
xen kẽ với bất kỳ đầu ra nào mà khách hàng gửi tới stderr.

--log-file =
Chỉ định rằng Valgrind sẽ gửi tất cả các thông điệp của nó tới tệp được chỉ định. Nếu
tên tệp trống, nó gây ra hủy bỏ. Có ba mã định dạng đặc biệt
có thể được sử dụng trong tên tệp.

%p được thay thế bằng ID quy trình hiện tại. Điều này rất hữu ích cho chương trình
gọi nhiều quy trình. CẢNH BÁO: Nếu bạn sử dụng --trace-children = vâng và chương trình của bạn
gọi nhiều quy trình HOẶC phân nhánh chương trình của bạn mà không cần gọi thực thi sau đó, và
bạn không sử dụng thông số này (hoặc %q thông số kỹ thuật bên dưới), đầu ra Valgrind từ tất cả
các quy trình đó sẽ đi vào một tệp, có thể lộn xộn và có thể không hoàn chỉnh.

% q {FOO} được thay thế bằng nội dung của biến môi trường FOO. Nếu {FOO}
một phần bị dị dạng, nó gây ra phá thai. Thông số này hiếm khi cần thiết, nhưng rất
hữu ích trong các trường hợp nhất định (ví dụ: khi chạy các chương trình MPI). Ý tưởng là bạn
chỉ định một biến sẽ được đặt khác nhau cho từng quy trình trong công việc, cho
ví dụ BPROC_RANK hoặc bất cứ điều gì có thể áp dụng trong thiết lập MPI của bạn. Nếu tên
biến môi trường không được đặt, nó gây ra sự cố. Lưu ý rằng trong một số shell, {
và } các ký tự có thể cần được thoát bằng dấu gạch chéo ngược.

%% được thay thế bằng %.

Nếu một % được theo sau bởi bất kỳ ký tự nào khác, nó gây ra sự hủy bỏ.

Nếu tên tệp chỉ định một tên tệp tương đối, nó sẽ được đặt trong phần đầu của chương trình
thư mục làm việc: đây là thư mục hiện tại khi chương trình bắt đầu
thực hiện sau ngã ba hoặc sau khi thực thi. Nếu nó chỉ định một tên tệp tuyệt đối (tức là.
bắt đầu bằng '/') sau đó nó được đặt ở đó.

--log-socket =
Chỉ định rằng Valgrind sẽ gửi tất cả các thông điệp của nó đến cổng được chỉ định tại
địa chỉ IP được chỉ định. Cổng có thể bị bỏ qua, trong trường hợp đó, cổng 1500 được sử dụng. Nếu một
không thể thực hiện kết nối với ổ cắm được chỉ định, Valgrind quay trở lại việc ghi
xuất ra lỗi chuẩn (stderr). Tùy chọn này được thiết kế để sử dụng trong
kết hợp với chương trình valgrind-listening. Để biết thêm chi tiết, hãy xem
bình luận trong sách hướng dẫn.

CÓ LỖI LIÊN QUAN LỰA CHỌN

Các tùy chọn này được sử dụng bởi tất cả các công cụ có thể báo cáo lỗi, ví dụ: Memcheck, nhưng không
Cachegrind.

--xml = [vỡ nợ: không]
Khi được bật, các phần quan trọng của đầu ra (ví dụ: thông báo lỗi công cụ) sẽ ở trong
Định dạng XML thay vì văn bản thuần túy. Hơn nữa, đầu ra XML sẽ được gửi đến một
kênh đầu ra khác với đầu ra văn bản thuần túy. Do đó, bạn cũng phải sử dụng một
of --xml-fd, --xml-tệp or --xml-socket để chỉ định nơi XML sẽ được gửi.

Các thư ít quan trọng hơn sẽ vẫn được in dưới dạng văn bản thuần túy, nhưng vì XML
đầu ra và đầu ra văn bản thuần túy được gửi đến các kênh đầu ra khác nhau (đích của
đầu ra văn bản thuần túy vẫn được kiểm soát bởi --log-fd, --log-tệp và - ổ cắm điện)
điều này sẽ không gây ra vấn đề.

Tùy chọn này nhằm mục đích làm cho cuộc sống dễ dàng hơn cho các công cụ tiêu thụ đầu ra của Valgrind như
đầu vào, chẳng hạn như giao diện người dùng GUI. Hiện tại tùy chọn này hoạt động với Memcheck, Helgrind,
DRD và SGcheck. Định dạng đầu ra được chỉ định trong tệp
docs / internals / xml-output-protocol4.txt trong cây nguồn cho Valgrind 3.5.0 hoặc
sau đó.

Các tùy chọn được đề xuất để GUI vượt qua, khi yêu cầu đầu ra XML, là: --xml = vâng
để kích hoạt đầu ra XML, --xml-tệp để gửi đầu ra XML tới một (có lẽ là GUI đã chọn)
tập tin, --log-tệp để gửi đầu ra văn bản thuần túy tới tệp GUI thứ hai được chọn,
--child-silent-after-fork = vângvà -q để hạn chế đầu ra văn bản thuần túy ở mức quan trọng
thông báo lỗi do chính Valgrind tạo ra. Ví dụ: không thể đọc một
tệp nén được coi là một thông báo lỗi nghiêm trọng. Bằng cách này, để thành công
chạy tập tin đầu ra văn bản sẽ trống. Nhưng nếu nó không trống, thì nó sẽ chứa
thông tin quan trọng mà người dùng GUI nên biết.

--xml-fd = [vỡ nợ: -1, Vô hiệu hóa]
Chỉ định rằng Valgrind sẽ gửi đầu ra XML của nó tới bộ mô tả tệp được chỉ định.
Nó phải được sử dụng cùng với --xml = vâng.

--xml-file =
Chỉ định rằng Valgrind sẽ gửi đầu ra XML của nó tới tệp được chỉ định. Nó phải là
được sử dụng kết hợp với --xml = vâng. Bất kì %p or %q trình tự xuất hiện trong tên tệp
được mở rộng theo cách giống hệt như cách chúng dành cho --log-tệp. Xem mô tả
of --log-tệp để biết thêm chi tiết.

--xml-socket =
Chỉ định rằng Valgrind sẽ gửi đầu ra XML của nó đến cổng được chỉ định tại
Địa chỉ IP. Nó phải được sử dụng cùng với --xml = vâng. Hình thức của lập luận là
giống như cái được sử dụng bởi - ổ cắm điện. Xem mô tả của - ổ cắm điện để biết thêm
chi tiết.

--xml-user-comment =
Nhúng thêm một chuỗi nhận xét của người dùng vào đầu đầu ra XML. Chỉ hoạt động khi
--xml = vâng được quy định; bỏ qua nếu không.

--demangle = [vỡ nợ: đúng]
Bật / tắt tự động tách (giải mã) tên C ++. Được bật theo mặc định. Khi nào
được kích hoạt, Valgrind sẽ cố gắng dịch các tên C ++ được mã hóa trở lại thứ gì đó
tiếp cận bản gốc. Trình giải mã xử lý các ký hiệu bị xáo trộn bởi g ++ phiên bản 2.X,
3.X và 4.X.

Một thực tế quan trọng về việc gỡ rối là các tên chức năng được đề cập trong các lần đàn áp
các tệp phải ở dạng bị xáo trộn. Valgrind không phân loại tên hàm khi
tìm kiếm các biện pháp trấn áp có thể áp dụng, bởi vì nếu làm theo cách khác sẽ khiến cho việc trấn áp
nội dung tệp phụ thuộc vào trạng thái của máy móc gỡ rối của Valgrind và cũng chậm
giảm phù hợp đàn áp.

--num-calllers = [vỡ nợ: 12]
Chỉ định số mục nhập tối đa được hiển thị trong dấu vết ngăn xếp xác định chương trình
các địa điểm. Lưu ý rằng các lỗi chỉ được bổ sung khi sử dụng bốn vị trí chức năng hàng đầu
(vị trí trong hàm hiện tại và của ba người gọi ngay lập tức của nó). Vì vậy, điều này
không ảnh hưởng đến tổng số lỗi được báo cáo.

Giá trị tối đa cho giá trị này là 500. Lưu ý rằng cài đặt cao hơn sẽ làm cho Valgrind chạy một
chậm hơn một chút và tốn nhiều bộ nhớ hơn một chút, nhưng có thể hữu ích khi làm việc với
các chương trình có chuỗi cuộc gọi lồng nhau sâu sắc.

--unw-stack-scan-thresh = [vỡ nợ: 0] , --unw-stack-scan-frames = [vỡ nợ:
5]
Hỗ trợ quét ngăn xếp chỉ khả dụng trên các mục tiêu ARM.

Các cờ này cho phép và điều khiển việc tháo cuộn bằng cách quét ngăn xếp. Khi bình thường
cơ chế tháo cuộn ngăn xếp - việc sử dụng các bản ghi CFI của Người lùn và con trỏ khung theo sau
- không thành công, quá trình quét ngăn xếp có thể khôi phục lại dấu vết ngăn xếp.

Lưu ý rằng quá trình quét ngăn xếp là một cơ chế không chính xác, theo kiểu heuristic có thể mang lại rất
kết quả sai lệch, hoặc không có kết quả nào cả. Nó chỉ nên được sử dụng trong trường hợp khẩn cấp, khi bình thường
việc tháo cuộn không thành công và điều quan trọng là phải có dấu vết ngăn xếp.

Quét ngăn xếp là một kỹ thuật đơn giản: trình giải nén đọc các từ từ ngăn xếp và
cố gắng đoán xem địa chỉ nào trong số chúng có thể là địa chỉ trả hàng, bằng cách kiểm tra xem chúng có
chỉ sau lệnh gọi ARM hoặc Ngón tay cái. Nếu vậy, từ được thêm vào
tồn đọng.

Nguy cơ chính xảy ra khi một lệnh gọi hàm trả về, để lại địa chỉ trả lại của nó
được hiển thị và một chức năng mới được gọi, nhưng chức năng mới không ghi đè lên chức năng cũ
Địa chỉ. Kết quả của việc này là backtrace có thể chứa các mục nhập cho các hàm
mà đã trở lại, và vì vậy rất khó hiểu.

Hạn chế thứ hai của việc triển khai này là nó sẽ chỉ quét trang (4KB,
bình thường) chứa con trỏ ngăn xếp bắt đầu. Nếu khung ngăn xếp lớn, điều này
có thể dẫn đến chỉ một số ít (hoặc thậm chí không có bất kỳ) hiện diện trong dấu vết. Ngoài ra, nếu bạn
không may mắn và có một con trỏ ngăn xếp ban đầu gần cuối trang chứa nó,
quét có thể bỏ lỡ tất cả các khung hình thú vị.

Theo mặc định, tính năng quét ngăn xếp bị tắt. Trường hợp sử dụng thông thường là yêu cầu nó khi
nếu không thì dấu vết ngăn xếp sẽ rất ngắn. Vì vậy, để kích hoạt nó, hãy sử dụng
--unw-stack-scan-thresh = number. Điều này yêu cầu Valgrind thử sử dụng tính năng quét ngăn xếp để
"mở rộng" dấu vết ngăn xếp chứa ít hơn khung số.

Nếu quá trình quét ngăn xếp diễn ra, nó sẽ chỉ tạo ra tối đa số khung hình
được chỉ định bởi --unw-stack-scan-frames. Thông thường, quét ngăn xếp tạo ra rất nhiều
các mục nhập rác mà giá trị này được đặt thành giá trị thấp (5) theo mặc định. Trong mọi trường hợp sẽ
một dấu vết ngăn xếp lớn hơn giá trị được chỉ định bởi --num-calllers sẽ được tạo.

--error-limit = [vỡ nợ: đúng]
Khi được bật, Valgrind ngừng báo cáo lỗi sau tổng số 10,000,000 hoặc 1,000
những cái khác nhau, đã được nhìn thấy. Điều này là để ngăn chặn máy móc theo dõi lỗi
trở thành một chi phí hiệu suất lớn trong các chương trình có nhiều lỗi.

--error-exitcode = [vỡ nợ: 0]
Chỉ định một mã thoát thay thế để trả về nếu Valgrind báo cáo bất kỳ lỗi nào trong
chạy. Khi được đặt thành giá trị mặc định (không), giá trị trả về từ Valgrind sẽ luôn
là giá trị trả về của quá trình đang được mô phỏng. Khi được đặt thành giá trị khác không, điều đó
giá trị được trả về thay thế, nếu Valgrind phát hiện bất kỳ lỗi nào. Điều này rất hữu ích cho việc sử dụng
Xác thực như một phần của bộ thử nghiệm tự động, vì nó giúp dễ dàng phát hiện thử nghiệm
các trường hợp Valgrind đã báo cáo lỗi, chỉ bằng cách kiểm tra mã trả lại.

--error-markers = , [vỡ nợ: không ai]
Khi lỗi được xuất ra dưới dạng văn bản thuần túy (tức là không sử dụng XML), --điểm đánh dấu lỗi hướng dẫn
xuất ra một dòng có chứa bắt đầu (cuối) chuỗi trước (sau) mỗi lỗi.

Các dòng đánh dấu như vậy tạo điều kiện thuận lợi cho việc tìm kiếm lỗi và / hoặc trích xuất lỗi trong
tệp đầu ra có chứa lỗi valgrind lẫn với đầu ra của chương trình.

Lưu ý rằng các điểm đánh dấu trống được chấp nhận. Vì vậy, chỉ sử dụng điểm đánh dấu bắt đầu (hoặc kết thúc) là
có thể.

--sigill-chẩn đoán = [vỡ nợ: đúng]
Bật / tắt tính năng in chẩn đoán hướng dẫn bất hợp pháp. Được bật theo mặc định, nhưng
mặc định thành tắt khi --Yên lặng được đưa ra. Mặc định luôn có thể là một cách rõ ràng
ghi đè bằng cách đưa ra tùy chọn này.

Khi được bật, một thông báo cảnh báo sẽ được in, cùng với một số chẩn đoán, bất cứ khi nào
gặp phải một lệnh mà Valgrind không thể giải mã hoặc dịch, trước khi
chương trình được đưa ra một tín hiệu SIGILL. Thông thường, một chỉ dẫn bất hợp pháp chỉ ra một lỗi trong
chương trình hoặc thiếu hỗ trợ cho hướng dẫn cụ thể trong Valgrind. Nhưng một vài
chương trình cố tình cố thực hiện một lệnh có thể bị thiếu và mắc bẫy
tín hiệu SIGILL để phát hiện các tính năng của bộ xử lý. Sử dụng cờ này giúp bạn có thể
tránh đầu ra chẩn đoán mà nếu không bạn sẽ nhận được trong những trường hợp như vậy.

--show-under-main = [vỡ nợ: không]
Theo mặc định, dấu vết ngăn xếp cho các lỗi không hiển thị bất kỳ chức năng nào xuất hiện bên dưới chính
bởi vì hầu hết thời gian đó là nội dung thư viện C và / hoặc gobbledygook không thú vị.
Ngoài ra, nếu chính không có trong dấu vết ngăn xếp, dấu vết ngăn xếp sẽ không hiển thị
bất kỳ chức năng nào bên dưới chính-như các chức năng như glibc's __libc_start_main.
Hơn nữa, nếu chính-như các chức năng có trong dấu vết, chúng được chuẩn hóa như
(phía dưới chủ chốt), để làm cho đầu ra xác định hơn.

Nếu tùy chọn này được bật, tất cả các mục theo dõi ngăn xếp sẽ được hiển thị và chính-giống
các chức năng sẽ không được chuẩn hóa.

--fullpath-after = [vỡ nợ: không hiển thị nguồn đường dẫn]
Theo mặc định, Valgrind chỉ hiển thị tên tệp trong dấu vết ngăn xếp, nhưng không hiển thị đường dẫn đầy đủ đến
các tập tin nguồn. Khi sử dụng Valgrind trong các dự án lớn nơi các nguồn nằm trong
nhiều thư mục khác nhau, điều này có thể gây bất tiện. --fullpath-sau cung cấp một
giải pháp linh hoạt cho vấn đề này. Khi tùy chọn này xuất hiện, đường dẫn đến mỗi
tệp nguồn được hiển thị, với thông báo quan trọng sau: nếu chuỗi được tìm thấy trong
đường dẫn, sau đó là đường dẫn đến và bao gồm chuỗi bị bỏ qua, nếu đường dẫn khác được hiển thị
không sửa đổi. Lưu ý rằng chuỗi không bắt buộc phải là tiền tố của đường dẫn.

Ví dụ: hãy xem xét một tệp có tên /home/janedoe/blah/src/foo/bar/xyzzy.c. Xác định
--fullpath-after = / home / janedoe / blah / src / sẽ khiến Valgrind hiển thị tên là
foo / bar / xyzzy.c.

Vì chuỗi không bắt buộc phải là tiền tố, --fullpath-after = src / sẽ sản xuất
cùng một đầu ra. Điều này hữu ích khi đường dẫn chứa tùy ý do máy tạo
nhân vật. Ví dụ: đường dẫn / my / build / dir / C32A1B47 / blah / src / foo / xyzzy có thể là
được cắt tỉa thành foo / xyzzy bằng cách sử dụng --fullpath-after = / blah / src /.

Nếu bạn chỉ muốn xem đường dẫn đầy đủ, chỉ cần chỉ định một chuỗi trống:
--fullpath-after =. Đây không phải là một trường hợp đặc biệt, chỉ đơn thuần là một hệ quả hợp lý của
quy định trên.

Cuối cùng, bạn có thể sử dụng --fullpath-sau nhiều lần. Bất kỳ sự xuất hiện nào của nó đều gây ra
Có hiệu lực để chuyển sang tạo đường dẫn đầy đủ và áp dụng quy tắc lọc ở trên. Mỗi
đường dẫn được tạo ra được so sánh với tất cả --fullpath-sau-các chuỗi cụ thể, trong
thứ tự được chỉ định. Chuỗi đầu tiên phù hợp khiến đường dẫn bị cắt ngắn như
miêu tả trên. Nếu không có kết quả nào phù hợp, đường dẫn đầy đủ sẽ được hiển thị. Điều này tạo điều kiện cho việc chặt bỏ
tiền tố khi nguồn được lấy từ một số thư mục không liên quan.

--extra-debuginfo-path = [vỡ nợ: không xác định và không sử dụng]
Theo mặc định, Valgrind tìm kiếm trong một số đường dẫn nổi tiếng cho các đối tượng gỡ lỗi, chẳng hạn như
/ usr / lib / debug /.

Tuy nhiên, có thể có các tình huống mà bạn có thể muốn đặt các đối tượng gỡ lỗi tại một
vị trí tùy ý, chẳng hạn như bộ nhớ ngoài khi chạy Valgrind trên thiết bị di động
với bộ nhớ cục bộ hạn chế. Một ví dụ khác có thể là một tình huống mà bạn không có
quyền cài đặt gói đối tượng gỡ lỗi trên hệ thống mà bạn đang chạy
Valgrind.

Trong những trường hợp này, bạn có thể cung cấp một đường dẫn tuyệt đối như một nơi bổ sung, cuối cùng cho
Có giá trị để tìm kiếm các đối tượng gỡ lỗi bằng cách chỉ định
--extra-debuginfo-path = / path / to / debug / objects. Đường dẫn đã cho sẽ được thêm vào trước
tên đường dẫn tuyệt đối của đối tượng được tìm kiếm. Ví dụ: nếu Valgrind đang tìm kiếm
debuginfo cho /w/x/y/zz.so và --extra-debuginfo-path = / a / b / c được chỉ định, nó sẽ
tìm đối tượng gỡ lỗi tại /a/b/c/w/x/y/zz.so.

Cờ này chỉ nên được chỉ định một lần. Nếu nó được chỉ định nhiều lần, chỉ
trường hợp cuối cùng được vinh danh.

--debuginfo-server = ipaddr: cổng [vỡ nợ: không xác định và không sử dụng]
Đây là một tính năng mới, thử nghiệm, được giới thiệu trong phiên bản 3.9.0.

Trong một số trường hợp, có thể thuận tiện khi đọc debuginfo từ các đối tượng được lưu trữ trên
máy khác nhau. Với cờ này, Valgrind sẽ truy vấn một máy chủ debuginfo đang chạy trên
ipaddr và đang nghe trên cổng port, nếu nó không thể tìm thấy đối tượng debuginfo trong cục bộ
hệ thống tập tin.

Máy chủ debuginfo phải chấp nhận kết nối TCP trên cổng cổng. Máy chủ debuginfo là
chứa trong tệp nguồn auxprogs / valgrind-di-server.c. Nó sẽ chỉ phục vụ từ
thư mục mà nó được bắt đầu. cổng mặc định là 1500 trong cả máy khách và máy chủ nếu
không được chỉ định.

Nếu Valgrind tìm kiếm debuginfo cho /w/x/y/zz.so bằng cách sử dụng máy chủ debuginfo
sẽ loại bỏ các thành phần tên đường dẫn và chỉ yêu cầu zz.so trên máy chủ. Điều đó trong
turn sẽ chỉ tìm một đối tượng debuginfo phù hợp trong thư mục làm việc hiện tại của nó.

Dữ liệu debuginfo được truyền thành các đoạn nhỏ (8 KB) theo yêu cầu của Valgrind.
Mỗi khối được nén bằng cách sử dụng LZO để giảm thời gian truyền. Việc thực hiện có
đã được điều chỉnh để có hiệu suất tốt nhất qua liên kết mạng 802.11g (WiFi) một giai đoạn.

Lưu ý rằng kiểm tra đối tượng chính và đối tượng gỡ lỗi phù hợp, sử dụng liên kết gỡ lỗi GNU CRC
, được thực hiện ngay cả khi sử dụng máy chủ debuginfo. Để tắt tính năng kiểm tra như vậy,
bạn cũng cần chỉ định --allow-mismatching-debuginfo = yes.

Theo mặc định, hệ thống xây dựng Valgrind sẽ xây dựng máy chủ valgrind-di-cho mục tiêu
nền tảng, mà gần như chắc chắn không phải là những gì bạn muốn. Cho đến nay chúng tôi đã không thể
tìm hiểu cách tải automake / autoconf để xây dựng nó cho nền tảng xây dựng. Nếu bạn muốn
để sử dụng nó, bạn sẽ phải biên dịch lại nó bằng tay bằng lệnh hiển thị ở đầu
auxprogs / valgrind-di-server.c.

--allow-mismatching-debuginfo = no | yes [Không]
Khi đọc debuginfo từ các đối tượng debuginfo riêng biệt, Valgrind sẽ kiểm tra theo mặc định
đối tượng chính và đối tượng debuginfo khớp nhau, bằng cách sử dụng cơ chế liên kết gỡ lỗi GNU. Cái này
đảm bảo rằng nó không đọc debuginfo từ các đối tượng debuginfo lỗi thời và
cũng đảm bảo rằng Valgrind không thể bị lỗi do không khớp.

Kiểm tra này có thể được ghi đè bằng cách sử dụng --allow-mismatching-debuginfo = yes. Điều này có thể
hữu ích khi debuginfo và các đối tượng chính chưa được phân chia theo cách thích hợp. Thì là ở
Tuy nhiên, hãy cẩn thận khi sử dụng điều này: nó vô hiệu hóa tất cả kiểm tra tính nhất quán và Valgrind
đã được quan sát thấy sự cố khi đối tượng chính và debuginfo không khớp.

--suppressions = [vỡ nợ: $ PREFIX / lib / valgrind / default.supp]
Chỉ định một tệp bổ sung để đọc mô tả các lỗi cần loại bỏ. Bạn có thể
sử dụng tối đa 100 tệp nén bổ sung.

--gen-đàn áp = [vỡ nợ: không]
Khi đặt thành Vâng, Valgrind sẽ tạm dừng sau mỗi lỗi hiển thị và in ra dòng:

---- Cấm in? --- [Return / N / n / Y / y / C / c] ----

nhấn Ret, hoặc là N Ret or n Ret, khiến Valgrind tiếp tục thực thi mà không in
sự đàn áp cho lỗi này.

nhấn Y Ret or y Ret khiến Valgrind viết một lệnh triệt tiêu cho lỗi này. Bạn có thể
sau đó cắt và dán nó vào một tệp nén nếu bạn không muốn nghe về
lỗi trong tương lai.

Khi đặt thành tất cả các, Valgrind sẽ in một lệnh chặn cho mọi lỗi được báo cáo, mà không
truy vấn người dùng.

Tùy chọn này đặc biệt hữu ích với các chương trình C ++, vì nó in ra
sự đàn áp với những cái tên bị xáo trộn, theo yêu cầu.

Lưu ý rằng các phần dập tắt được in càng cụ thể càng tốt. Bạn có thể muốn chung
lên những cái tương tự, bằng cách thêm ký tự đại diện vào tên hàm và bằng cách sử dụng mức khung
ký tự đại diện. Các cơ sở bảo tồn hoang dã mạnh mẽ nhưng linh hoạt và với một chút
chỉnh sửa cẩn thận, bạn có thể loại bỏ toàn bộ các lỗi liên quan với
chỉ có một số đàn áp.

Đôi khi hai lỗi khác nhau bị triệt tiêu bởi cùng một lần triệt tiêu, trong trường hợp đó
Valgrind sẽ xuất ra lệnh triệt tiêu nhiều lần, nhưng bạn chỉ cần có một
sao chép trong tệp nén của bạn (nhưng có nhiều hơn một tệp sẽ không gây ra sự cố). Cũng,
tên đàn áp được đưa ra là ; tên không
thực sự quan trọng, nó chỉ được sử dụng với -v tùy chọn in ra tất cả sự đàn áp đã sử dụng
Hồ sơ.

--input-fd = [vỡ nợ: 0, tiêu chuẩn]
Khi đang sử dụng --gen-Suppression = vâng, Valgrind sẽ dừng để đọc đầu vào bàn phím
từ bạn khi mỗi lỗi xảy ra. Theo mặc định, nó đọc từ đầu vào chuẩn (stdin),
đây là vấn đề đối với các chương trình đóng stdin. Tùy chọn này cho phép bạn chỉ định
một bộ mô tả tệp thay thế để đọc đầu vào.

--dsymutil = không | có [Đúng]
Tùy chọn này chỉ phù hợp khi chạy Valgrind trên Mac OS X.

Mac OS X sử dụng lược đồ liên kết thông tin gỡ lỗi hoãn lại (debuginfo). Khi đối tượng
các tệp chứa debuginfo được liên kết thành .dylib hoặc tệp thực thi, debuginfo là
không được sao chép vào tệp cuối cùng. Thay vào đó, debuginfo phải được liên kết thủ công bằng
chạy dsymutil, một tiện ích do hệ thống cung cấp, trên tệp thực thi hoặc .dylib. Các
kết quả debuginfo kết hợp được đặt trong một thư mục cùng với tệp thực thi hoặc
.dylib, nhưng có phần mở rộng .dSYM.

Với --dsymutil = không, Valgrind sẽ phát hiện các trường hợp trong đó thư mục .dSYM là
bị thiếu, hoặc có nhưng dường như không khớp với tệp thực thi được liên kết hoặc
.dylib, rất có thể vì nó đã lỗi thời. Trong những trường hợp này, Valgrind sẽ in
thông báo cảnh báo nhưng không thực hiện thêm hành động nào.

Với --dsymutil = vâng, Valgrind, trong những trường hợp như vậy, sẽ tự động chạy dsymutil như
cần thiết để cập nhật debuginfo. Đối với tất cả các mục đích thực tế, nếu bạn luôn
sử dụng --dsymutil = vâng, sau đó không bao giờ cần phải chạy dsymutil theo cách thủ công hoặc như một phần
của hệ thống xây dựng ứng dụng của bạn, vì Valgrind sẽ chạy nó khi cần thiết.

Valgrind sẽ không cố gắng chạy dsymutil trên bất kỳ tệp thực thi hoặc thư viện nào trong / usr /,
/ thùng rác /, / sbin /, / opt /, / sw /, / Hệ thống /, / Thư viện / hoặc / Ứng dụng / vì dsymutil sẽ
luôn luôn thất bại trong những tình huống như vậy. Cả hai đều không thành công vì debuginfo
các thành phần hệ thống được cài đặt sẵn không có sẵn ở bất kỳ đâu và cũng bởi vì nó sẽ
yêu cầu quyền ghi trong các thư mục đó.

Cẩn thận khi sử dụng --dsymutil = vâng, vì nó sẽ gây ra .dSYM tồn tại từ trước
thư mục được xóa và tạo lại một cách thầm lặng. Cũng lưu ý rằng dsymutil khá
chậm, đôi khi quá mức như vậy.

--max-stackframe = [vỡ nợ: 2000000]
Kích thước tối đa của khung ngăn xếp. Nếu con trỏ ngăn xếp di chuyển nhiều hơn số tiền này
thì Valgrind sẽ giả định rằng chương trình đang chuyển sang một ngăn xếp khác.

Bạn có thể cần sử dụng tùy chọn này nếu chương trình của bạn có các mảng lớn được phân bổ theo ngăn xếp.
Valgrind theo dõi con trỏ ngăn xếp của chương trình của bạn. Nếu nó thay đổi nhiều hơn
số lượng ngưỡng, Valgrind giả định rằng chương trình của bạn đang chuyển sang một ngăn xếp khác và
Memcheck hoạt động khác với việc thay đổi con trỏ ngăn xếp nhỏ hơn
ngưỡng cửa. Thông thường heuristic này hoạt động tốt. Tuy nhiên, nếu chương trình của bạn phân bổ lớn
cấu trúc trên ngăn xếp, kinh nghiệm này sẽ bị đánh lừa và sau đó Memcheck sẽ
báo cáo số lượng lớn các truy cập ngăn xếp không hợp lệ. Tùy chọn này cho phép bạn thay đổi
ngưỡng đến một giá trị khác.

Bạn chỉ nên cân nhắc sử dụng tùy chọn này nếu đầu ra gỡ lỗi của Valgrind hướng bạn đến
làm như vậy. Trong trường hợp đó, nó sẽ cho bạn biết ngưỡng mới mà bạn nên chỉ định.

Nói chung, phân bổ các cấu trúc lớn trên ngăn xếp là một ý tưởng tồi, bởi vì bạn có thể
dễ dàng hết dung lượng ngăn xếp, đặc biệt là trên các hệ thống có bộ nhớ hạn chế hoặc
mong đợi hỗ trợ số lượng lớn các luồng mỗi luồng với một ngăn xếp nhỏ, và cũng vì
kiểm tra lỗi do Memcheck thực hiện sẽ hiệu quả hơn đối với dữ liệu được phân bổ theo heap
so với dữ liệu được phân bổ theo ngăn xếp. Nếu bạn phải sử dụng tùy chọn này, bạn có thể muốn
xem xét việc viết lại mã của bạn để phân bổ trên heap thay vì trên ngăn xếp.

--main-stacksize = [vỡ nợ: sử dụng hiện hành 'ulimit' giá trị]
Chỉ định kích thước của ngăn xếp của luồng chính.

Để đơn giản hóa việc quản lý bộ nhớ của nó, Valgrind dự trữ tất cả không gian cần thiết cho chính
ngăn xếp của luồng khi khởi động. Điều đó có nghĩa là nó cần biết kích thước ngăn xếp được yêu cầu tại
khởi động

Theo mặc định, Valgrind sử dụng giá trị "ulimit" hiện tại cho kích thước ngăn xếp, hoặc 16 MB,
cái nào thấp hơn. Trong nhiều trường hợp, điều này cung cấp kích thước ngăn xếp trong khoảng 8 đến 16 MB,
mà hầu như không bao giờ bị tràn đối với hầu hết các ứng dụng.

Nếu bạn cần tổng kích thước ngăn xếp lớn hơn, hãy sử dụng --main-stacksize để xác định nó. Chỉ đặt nó
cao như bạn cần, vì dành nhiều dung lượng hơn mức bạn cần (nghĩa là, hàng trăm
nhiều megabyte hơn bạn cần) hạn chế trình cấp phát bộ nhớ của Valgrind và có thể
giảm tổng dung lượng bộ nhớ mà Valgrind có thể sử dụng. Đây chỉ thực sự là của
ý nghĩa trên máy 32-bit.

Trên Linux, bạn có thể yêu cầu một ngăn xếp có kích thước lên đến 2GB. Valgrind sẽ dừng lại với một
thông báo chẩn đoán nếu ngăn xếp không thể được cấp phát.

--main-stacksize chỉ ảnh hưởng đến kích thước ngăn xếp cho luồng ban đầu của chương trình. Nó có
không ảnh hưởng đến kích thước của ngăn xếp luồng, vì Valgrind không phân bổ chúng.

Bạn có thể cần sử dụng cả hai --main-stacksize và - max-stackframe cùng nhau. Nó là
quan trọng là phải hiểu điều đó --main-stacksize đặt tổng kích thước ngăn xếp tối đa,
trong khi - max-stackframe chỉ định kích thước lớn nhất của bất kỳ một khung ngăn xếp nào. Bạn sẽ
phải tìm ra --main-stacksize giá trị cho bản thân (thông thường, nếu
mặc định của ứng dụng). Nhưng Valgrind sẽ cho bạn biết những điều cần thiết - max-stackframe kích thước,
Nếu cần.

Như đã thảo luận thêm trong phần mô tả của - max-stackframe, một yêu cầu cho một
ngăn xếp là một dấu hiệu của các vấn đề về khả năng di chuyển tiềm ẩn. Tốt nhất bạn nên đặt tất cả
dữ liệu lớn trong bộ nhớ được phân bổ theo heap.

--max-thread = [vỡ nợ: 500]
Theo mặc định, Valgrind có thể xử lý tới 500 luồng. Đôi khi, con số đó cũng
nhỏ. Sử dụng tùy chọn này để cung cấp một giới hạn khác. Ví dụ - max-thread = 3000.

MALLOC () - LIÊN QUAN LỰA CHỌN

Đối với các công cụ sử dụng phiên bản malloc của riêng họ (ví dụ: Memcheck, Massif, Helgrind, DRD),
các tùy chọn sau được áp dụng.

--alignment = [vỡ nợ: 8 or 16, tùy on các nền tảng]
Theo mặc định của Valgrind malloc, phân bổ tài chính, v.v., trả về một khối có địa chỉ bắt đầu là
Căn chỉnh 8 byte hoặc căn chỉnh 16 byte (giá trị tùy thuộc vào nền tảng và khớp với
nền tảng mặc định). Tùy chọn này cho phép bạn chỉ định một căn chỉnh khác. Các
giá trị được cung cấp phải lớn hơn hoặc bằng giá trị mặc định, nhỏ hơn hoặc bằng
4096, và phải là lũy thừa của hai.

--redzone-size = [vỡ nợ: phụ thuộc on các dụng cụ]
Valgrind's trung quốc, phân bổ lại, vv, thêm các khối đệm trước và sau mỗi khối heap
được phân bổ bởi chương trình đang chạy. Các khối đệm như vậy được gọi là redzones. Các
giá trị mặc định cho kích thước redzone phụ thuộc vào công cụ. Ví dụ: Memcheck thêm và
bảo vệ tối thiểu 16 byte trước và sau mỗi khối được phân bổ bởi máy khách.
Điều này cho phép nó phát hiện khối thiếu hoặc vượt quá lên đến 16 byte.

Việc tăng kích thước vùng redzone giúp nó có thể phát hiện được các phần vượt quá khoảng cách lớn hơn,
nhưng làm tăng dung lượng bộ nhớ được sử dụng bởi Valgrind. Giảm kích thước redzone sẽ
giảm bộ nhớ cần thiết của Valgrind nhưng cũng giảm cơ hội phát hiện
over / underruns, do đó không được khuyến khích.

KHÔNG PHỔ BIẾN LỰA CHỌN

Các tùy chọn này áp dụng cho tất cả các công cụ, vì chúng ảnh hưởng đến một số hoạt động khó hiểu của Valgrind
cốt lõi. Hầu hết mọi người sẽ không cần sử dụng chúng.

--smc-check = [vỡ nợ: tất cả không phải tệp cho x86 / amd64 / s390x,
ngăn xếp cho khác vòm]
Tùy chọn này kiểm soát việc phát hiện mã tự sửa đổi của Valgrind. Nếu không kiểm tra là
xong, khi một chương trình thực thi một số mã, sau đó ghi đè nó bằng mã mới và
thực thi mã mới, Valgrind sẽ tiếp tục thực thi các bản dịch mà nó đã thực hiện
mã cũ. Điều này có thể dẫn đến hành vi không chính xác và / hoặc sự cố.

Đối với kiến ​​trúc "hiện đại" - bất kỳ thứ gì không phải là x86, amd64 hoặc s390x - mặc định
is ngăn xếp. Điều này là do một chương trình đúng phải thực hiện hành động rõ ràng để thiết lập lại
Tính nhất quán của bộ nhớ cache DI sau khi sửa đổi mã. Valgrind quan sát và tôn vinh như vậy
các hành động, với kết quả là mã tự sửa đổi được xử lý minh bạch bằng XNUMX
chi phi thêm.

Đối với x86, amd64 và s390x, chương trình không bắt buộc phải thông báo cho phần cứng của
yêu cầu đồng bộ kết nối DI. Do đó, mặc định là tất cả không phải tệp, bao gồm
trường hợp bình thường của việc tạo mã vào khu vực mmap'd ẩn danh (không được hỗ trợ bởi tệp).

Ý nghĩa của bốn cài đặt có sẵn như sau. Không phát hiện (không ai),
phát hiện mã tự sửa đổi trên ngăn xếp (được GCC sử dụng để triển khai
chức năng) (ngăn xếp), phát hiện mã tự sửa đổi ở mọi nơi (tất cả các), và phát hiện
mã tự sửa đổi ở mọi nơi ngoại trừ trong các ánh xạ được hỗ trợ bởi tệp (tất cả không phải tệp).

Chạy với tất cả các sẽ làm chậm Valgrind xuống đáng kể. Chạy với không ai sẽ hiếm khi
tăng tốc mọi thứ, vì rất ít mã được tạo động trong hầu hết các chương trình.
Sản phẩm VALGRIND_DISCARD_TRANSLATIONS yêu cầu của khách hàng là một sự thay thế cho --smc-check = tất cả
và --smc-check = all-non-file điều đó đòi hỏi nhiều nỗ lực của lập trình viên hơn nhưng cho phép Valgrind
để chạy chương trình của bạn nhanh hơn, bằng cách thông báo chính xác khi nào cần dịch
làm lại.

--smc-check = all-non-file cung cấp một phiên bản rẻ hơn nhưng hạn chế hơn của
--smc-check = tất cả. Nó bổ sung kiểm tra cho bất kỳ bản dịch nào không bắt nguồn từ
ánh xạ bộ nhớ được sao lưu tệp. Các ứng dụng điển hình tạo mã, ví dụ như JITs
trong trình duyệt web, tạo mã vào các khu vực bản đồ dài ẩn danh, trong khi mã "cố định"
của trình duyệt luôn tồn tại trong các ánh xạ được hỗ trợ bởi tệp. --smc-check = all-non-file mất
lợi thế của quan sát này, hạn chế chi phí kiểm tra đối với mã
có khả năng được tạo JIT.

--read-inline-info = [vỡ nợ: xem phía dưới]
Khi được bật, Valgrind sẽ đọc thông tin về các lệnh gọi hàm nội tuyến từ DWARF3
thông tin gỡ lỗi. Điều này làm chậm quá trình khởi động Valgrind và làm cho nó sử dụng nhiều bộ nhớ hơn (thường dành cho
mỗi đoạn mã nội tuyến, 6 từ và khoảng trắng cho tên hàm), nhưng kết quả là
trong các đường xếp chồng mô tả nhiều hơn. Đối với bản phát hành 3.10.0, chức năng này được bật
theo mặc định chỉ dành cho các mục tiêu Linux, Android và Solaris và chỉ cho các công cụ
Memcheck, Helgrind và DRD. Đây là một ví dụ về một số hệ thống ngăn xếp với
--read-inline-info = no:

== 15380 == Nhảy hoặc di chuyển có điều kiện phụ thuộc vào (các) giá trị chưa được khởi tạo
== 15380 == tại 0x80484EA: main (inlinfo.c: 6)
== 15380 ==
== 15380 == Nhảy hoặc di chuyển có điều kiện phụ thuộc vào (các) giá trị chưa được khởi tạo
== 15380 == tại 0x8048550: fun_noninline (inlinfo.c: 6)
== 15380 == bởi 0x804850E: main (inlinfo.c: 34)
== 15380 ==
== 15380 == Nhảy hoặc di chuyển có điều kiện phụ thuộc vào (các) giá trị chưa được khởi tạo
== 15380 == tại 0x8048520: main (inlinfo.c: 6)

Và đây là những lỗi tương tự với --read-inline-info = yes:

== 15377 == Nhảy hoặc di chuyển có điều kiện phụ thuộc vào (các) giá trị chưa được khởi tạo
== 15377 == tại 0x80484EA: fun_d (inlinfo.c: 6)
== 15377 == bởi 0x80484EA: fun_c (inlinfo.c: 14)
== 15377 == bởi 0x80484EA: fun_b (inlinfo.c: 20)
== 15377 == bởi 0x80484EA: fun_a (inlinfo.c: 26)
== 15377 == bởi 0x80484EA: main (inlinfo.c: 33)
== 15377 ==
== 15377 == Nhảy hoặc di chuyển có điều kiện phụ thuộc vào (các) giá trị chưa được khởi tạo
== 15377 == tại 0x8048550: fun_d (inlinfo.c: 6)
== 15377 == bởi 0x8048550: fun_noninline (inlinfo.c: 41)
== 15377 == bởi 0x804850E: main (inlinfo.c: 34)
== 15377 ==
== 15377 == Nhảy hoặc di chuyển có điều kiện phụ thuộc vào (các) giá trị chưa được khởi tạo
== 15377 == tại 0x8048520: fun_d (inlinfo.c: 6)
== 15377 == bởi 0x8048520: main (inlinfo.c: 35)

--read-var-info = [vỡ nợ: không]
Khi được bật, Valgrind sẽ đọc thông tin về các loại biến và vị trí từ
Thông tin gỡ lỗi DWARF3. Điều này làm chậm đáng kể khởi động Valgrind và làm cho nó sử dụng
nhiều bộ nhớ hơn đáng kể, nhưng đối với các công cụ có thể tận dụng nó (Memcheck,
Helgrind, DRD) nó có thể dẫn đến các thông báo lỗi chính xác hơn. Ví dụ, đây là
một số lỗi tiêu chuẩn do Memcheck phát hành:

== 15363 == (Các) byte chưa khởi tạo được tìm thấy trong yêu cầu kiểm tra của khách hàng
== 15363 == tại 0x80484A9: croak (varinfo1.c: 28)
== 15363 == bởi 0x8048544: main (varinfo1.c: 55)
== 15363 == Địa chỉ 0x80497f7 là 7 byte bên trong ký hiệu dữ liệu "global_i2"
== 15363 ==
== 15363 == (Các) byte chưa khởi tạo được tìm thấy trong yêu cầu kiểm tra của khách hàng
== 15363 == tại 0x80484A9: croak (varinfo1.c: 28)
== 15363 == bởi 0x8048550: main (varinfo1.c: 56)
== 15363 == Địa chỉ 0xbea0d0cc nằm trên ngăn xếp của luồng 1
== 15363 == trong khung # 1, được tạo bởi main (varinfo1.c: 45)

Và đây là những lỗi tương tự với --read-var-info = yes:

== 15370 == (Các) byte chưa khởi tạo được tìm thấy trong yêu cầu kiểm tra của khách hàng
== 15370 == tại 0x80484A9: croak (varinfo1.c: 28)
== 15370 == bởi 0x8048544: main (varinfo1.c: 55)
== 15370 == Vị trí 0x80497f7 là 0 byte bên trong global_i2 [7],
== 15370 == một biến toàn cục được khai báo tại varinfo1.c: 41
== 15370 ==
== 15370 == (Các) byte chưa khởi tạo được tìm thấy trong yêu cầu kiểm tra của khách hàng
== 15370 == tại 0x80484A9: croak (varinfo1.c: 28)
== 15370 == bởi 0x8048550: main (varinfo1.c: 56)
== 15370 == Vị trí 0xbeb4a0cc là 0 byte bên trong var cục bộ "local"
== 15370 == được khai báo tại varinfo1.c: 46, trong khung # 1 của luồng 1

--vgdb-thăm dò = [vỡ nợ: 5000]
Là một phần của vòng lặp chính, trình lập lịch Valgrind sẽ thăm dò ý kiến ​​để kiểm tra xem một số hoạt động
(chẳng hạn như một lệnh bên ngoài hoặc một số đầu vào từ gdb) phải được xử lý bởi gdbserver.
Cuộc thăm dò hoạt động này sẽ được thực hiện sau khi đã chạy số lượng khối cơ bản nhất định (hoặc
nhiều hơn một chút so với số khối cơ bản đã cho). Cuộc bình chọn này khá rẻ nên
giá trị mặc định được đặt tương đối thấp. Bạn có thể giảm giá trị này hơn nữa nếu vgdb
không thể sử dụng lệnh gọi hệ thống ptrace để ngắt Valgrind nếu tất cả các chủ đề đều
thời gian) bị chặn trong một cuộc gọi hệ thống.

--vgdb-shadow-register = không | có [vỡ nợ: không]
Khi được kích hoạt, gdbserver sẽ hiển thị các thanh ghi bóng Valgrind cho GDB. Với cái này,
Giá trị của thanh ghi bóng Valgrind có thể được kiểm tra hoặc thay đổi bằng cách sử dụng GDB.
Hiển thị thanh ghi bóng chỉ hoạt động với GDB phiên bản 7.1 trở lên.

--vgdb-prefix = [vỡ nợ: / tmp / vgdb-pipe]
Để giao tiếp với gdb / vgdb, Valgrind gdbserver tạo 3 tệp (2 tệp FIFO có tên
và một tệp bộ nhớ được chia sẻ mmap). Tùy chọn tiền tố kiểm soát thư mục và tiền tố
để tạo các tệp này.

--run-libc-freeres = [vỡ nợ: đúng]
Tùy chọn này chỉ phù hợp khi chạy Valgrind trên Linux.

Thư viện GNU C (libc.so), được sử dụng bởi tất cả các chương trình, có thể cấp phát bộ nhớ cho
những công dụng riêng của nó. Thông thường, nó không bận tâm đến việc giải phóng bộ nhớ đó khi chương trình kết thúc—
sẽ không có ích gì, vì hạt nhân Linux lấy lại tất cả các tài nguyên quy trình khi
quy trình vẫn thoát, vì vậy nó sẽ chỉ làm mọi thứ chậm lại.

Các tác giả glibc nhận ra rằng hành vi này gây ra các bộ kiểm tra rò rỉ, chẳng hạn như Valgrind,
để báo cáo sai sự cố rò rỉ trong glibc, khi việc kiểm tra rò rỉ được thực hiện ở lối ra. Để tránh
điều này, họ đã cung cấp một quy trình được gọi là __libc_freeres đặc biệt để phát hành glibc
tất cả bộ nhớ nó đã cấp phát. Memcheck do đó cố gắng chạy __libc_freeres ở lối ra.

Thật không may, trong một số phiên bản glibc rất cũ, __libc_freeres là đủ
lỗi để gây ra lỗi phân đoạn. Điều này đặc biệt đáng chú ý trên Red Hat 7.1.
Vì vậy, tùy chọn này được cung cấp để ngăn chặn việc chạy __libc_freeres. Nếu là của bạn
chương trình dường như chạy tốt trên Valgrind, nhưng mặc định khi thoát, bạn có thể thấy rằng
--run-libc-freeres = không khắc phục điều đó, mặc dù với cái giá phải trả là báo cáo sai
rò rỉ không gian trong libc.so.

--sim-hints = hint1, hint2, ...
Chuyển các gợi ý khác cho Valgrind để sửa đổi một chút hành vi được mô phỏng trong
cách không chuẩn hoặc nguy hiểm, có thể để giúp mô phỏng các tính năng lạ. Qua
mặc định không có gợi ý nào được bật. Sử dụng cẩn thận! Các gợi ý hiện đã biết là:

· lax-ioctls: Hãy rất lỏng lẻo về việc xử lý ioctl; giả định duy nhất là kích thước
đúng. Không yêu cầu khởi tạo bộ đệm đầy đủ khi viết.
Nếu không có điều này, sử dụng một số trình điều khiển thiết bị có số lượng lớn ioctl lạ
các lệnh trở nên rất mệt mỏi.

· tương thích với cầu chì: Cho phép xử lý đặc biệt đối với một số cuộc gọi hệ thống nhất định có thể chặn
trong hệ thống tệp FUSE. Điều này có thể cần thiết khi chạy Valgrind trên
chương trình đa luồng sử dụng một luồng để quản lý hệ thống tệp FUSE và
một chuỗi khác để truy cập hệ thống tệp đó.

· kích hoạt bên ngoài: Kích hoạt một số phép thuật đặc biệt cần thiết khi chương trình đang được chạy
chính nó là Valgrind.

· tiền tố no-inner-: Tắt in tiền tố > trước mỗi stdout hoặc stderr
dòng đầu ra trong một Valgrind bên trong được điều hành bởi một Valgrind bên ngoài. Cái này hữu ích
khi chạy kiểm tra hồi quy Valgrind trong thiết lập bên ngoài / bên trong. Lưu ý rằng
tiếp đầu ngữ > sẽ luôn được in trước các dòng ghi nhật ký gỡ lỗi bên trong.

· không-nptl-pthread-stackcache: Gợi ý này chỉ phù hợp khi chạy Valgrind trên
Linux.

Thư viện pthread GNU glibc (libpthread.so), được sử dụng bởi các chương trình pthread,
duy trì một bộ nhớ cache của các ngăn xếp pthread. Khi một pthread kết thúc, bộ nhớ được sử dụng
đối với ngăn xếp pthread và một số cấu trúc dữ liệu liên quan đến lưu trữ cục bộ luồng không
luôn được phát hành trực tiếp. Bộ nhớ này được giữ trong bộ nhớ cache (tối đa một kích thước nhất định),
và được sử dụng lại nếu một luồng mới được bắt đầu.

Bộ nhớ cache này khiến công cụ helgrind báo cáo một số tình trạng chủng tộc dương tính giả
lỗi trên bộ nhớ đã lưu trong bộ nhớ cache này, vì helgrind không hiểu glibc bên trong
nguyên thủy đồng bộ hóa bộ nhớ cache. Vì vậy, khi sử dụng helgrind, hãy tắt bộ nhớ cache
giúp tránh tình trạng chủng tộc dương tính giả, đặc biệt là khi sử dụng chủ đề
các biến lưu trữ cục bộ (ví dụ: các biến sử dụng __chủ đề vòng loại).

Khi sử dụng công cụ ghi nhớ, việc tắt bộ đệm sẽ đảm bảo bộ nhớ được glibc sử dụng
để xử lý các biến __thread được giải phóng trực tiếp khi một luồng kết thúc.

Lưu ý: Valgrind vô hiệu hóa bộ đệm bằng cách sử dụng một số kiến ​​thức nội bộ về ngăn xếp glibc
triển khai bộ nhớ cache và bằng cách kiểm tra thông tin gỡ lỗi của pthread
thư viện. Do đó, kỹ thuật này hơi mỏng manh và có thể không hoạt động đối với tất cả các glibc
các phiên bản. Điều này đã được thử nghiệm thành công với các phiên bản glibc khác nhau (ví dụ:
2.11, 2.16, 2.18) trên các nền tảng khác nhau.

· cửa lỏng lẻo: (Chỉ dành cho Solaris) Hãy hết sức lỏng lẻo trong việc xử lý cuộc gọi hệ thống cửa qua
bộ mô tả tệp cửa không được công nhận. Không yêu cầu bộ đệm đầy đủ là
khởi tạo khi viết. Nếu không có điều này, các chương trình sử dụng libdoor(3LIB) chức năng
với ngữ nghĩa hoàn toàn độc quyền có thể báo cáo số lượng lớn các kết quả dương tính giả.

--fair-Schedule = [vỡ nợ: không]
Sản phẩm - lịch trình đôi tùy chọn điều khiển cơ chế khóa được Valgrind sử dụng để tuần tự hóa
thực hiện luồng. Cơ chế khóa kiểm soát cách các luồng được lên lịch,
và các cài đặt khác nhau mang lại sự cân bằng khác nhau giữa công bằng và hiệu suất. Vì
thêm chi tiết về lược đồ tuần tự hóa chuỗi Valgrind và tác động của nó đối với
hiệu suất và lập lịch luồng, xem Lập lịch và Hiệu suất đa luồng.

· Giá trị --fair-Schedule = có kích hoạt một lịch trình công bằng. Tóm lại, nếu nhiều
các chủ đề đã sẵn sàng để chạy, các chủ đề sẽ được lên lịch theo kiểu vòng tròn.
Cơ chế này không có sẵn trên tất cả các nền tảng hoặc phiên bản Linux. Nếu không
có sẵn, đang sử dụng --fair-Schedule = có sẽ làm cho Valgrind kết thúc với một lỗi.

Bạn có thể thấy cài đặt này cải thiện khả năng phản hồi tổng thể nếu bạn đang chạy một
chương trình đa luồng tương tác, ví dụ như trình duyệt web, trên Valgrind.

· Giá trị --fair-Schedule = thử kích hoạt lập lịch trình hợp lý nếu có trên nền tảng.
Nếu không, nó sẽ tự động trở lại --fair-Schedule = không.

· Giá trị --fair-Schedule = không kích hoạt bộ lập lịch không đảm bảo tính công bằng
giữa các luồng đã sẵn sàng để chạy, nhưng nhìn chung sẽ cho hiệu suất cao nhất.

--kernel-variant = variant1, variant2, ...
Xử lý các lệnh gọi và ioctl hệ thống phát sinh từ các biến thể nhỏ của hạt nhân mặc định cho
nền tảng này. Điều này rất hữu ích để chạy trên các hạt nhân bị tấn công hoặc với các mô-đun hạt nhân
chẳng hạn hỗ trợ các ioctls không chuẩn. Sử dụng cẩn thận. Nếu bạn không
hiểu tùy chọn này làm gì thì bạn gần như chắc chắn không cần nó. Hiện tại
các biến thể đã biết là:

· bproc: hỗ trợ cái sys_broc cuộc gọi hệ thống trên x86. Điều này là để chạy trên BProc,
là một biến thể nhỏ của Linux tiêu chuẩn, đôi khi được sử dụng để xây dựng
các cụm.

· android-no-hw-tls: một số phiên bản của trình giả lập Android dành cho ARM không cung cấp
phần cứng TLS (trạng thái luồng cục bộ) và Valgrind bị treo khi khởi động. Sử dụng
biến thể này để chọn phần mềm hỗ trợ cho TLS.

· android-gpu-sgx5xx: sử dụng cái này để hỗ trợ việc xử lý các ioctls độc quyền cho
Dòng GPU PowerVR SGX 5XX trên thiết bị Android. Không chọn được cái này thì không
gây ra sự cố ổn định, nhưng có thể khiến Memcheck báo cáo lỗi sai sau
chương trình thực hiện các ioctls dành riêng cho GPU.

· android-gpu-adreno3xx: tương tự, sử dụng điều này để hỗ trợ xử lý
ioctls cho loạt GPU Qualcomm Adreno 3XX trên thiết bị Android.

--merge-recursive-frames = [vỡ nợ: 0]
Một số thuật toán đệ quy, ví dụ như triển khai cây nhị phân cân bằng, tạo
nhiều dấu vết ngăn xếp khác nhau, mỗi dấu vết chứa các chu kỳ của cuộc gọi. Một chu kỳ được định nghĩa là
hai giá trị bộ đếm chương trình giống nhau được phân tách bằng XNUMX hoặc nhiều bộ đếm chương trình khác
các giá trị. Sau đó, Valgrind có thể sử dụng nhiều bộ nhớ để lưu trữ tất cả các dấu vết ngăn xếp này. Đây là
sử dụng bộ nhớ kém khi xem xét rằng các dấu vết ngăn xếp như vậy chứa lặp đi lặp lại không thú vị
các cuộc gọi đệ quy thay vì các thông tin thú vị hơn, chẳng hạn như hàm có
bắt đầu cuộc gọi đệ quy.

Tùy chọn --merge-recursive-frames = hướng dẫn Valgrind phát hiện và hợp nhất
chu kỳ cuộc gọi đệ quy có kích thước lên đến khung. Khi một chu kỳ như vậy là
được phát hiện, Valgrind ghi lại chu kỳ trong dấu vết ngăn xếp như một bộ đếm chương trình duy nhất.

Giá trị 0 (mặc định) không gây ra hợp nhất cuộc gọi đệ quy. Giá trị 1 sẽ gây ra
ngăn xếp dấu vết của các thuật toán đệ quy đơn giản (ví dụ: triển khai giai thừa)
bị sụp đổ. Giá trị của 2 thường sẽ cần thiết để thu gọn các dấu vết ngăn xếp được tạo ra
bằng các thuật toán đệ quy như cây nhị phân, sắp xếp nhanh, v.v. Giá trị cao hơn có thể là
cần thiết cho các thuật toán đệ quy phức tạp hơn.

Lưu ý: các cuộc gọi đệ quy được phát hiện bằng cách phân tích các giá trị của bộ đếm chương trình. Họ không phải
được phát hiện bằng cách nhìn vào tên chức năng.

--num-transtab-sector = [vỡ nợ: 6 cho Android nền tảng, 16 cho tất cả các khác]
Valgrind dịch và chỉnh sửa mã máy chương trình của bạn thành các đoạn nhỏ
(các khối cơ bản). Các bản dịch được lưu trữ trong một bộ nhớ cache dịch được phân chia
thành một số phần (lĩnh vực). Nếu bộ nhớ cache đầy, khu vực chứa
bản dịch cũ nhất được làm trống và sử dụng lại. Nếu cần lại những bản dịch cũ này,
Valgrind phải dịch lại và đo lại mã máy tương ứng, đó là
đắt tiền. Nếu tập hợp làm việc "hướng dẫn được thực thi" của một chương trình lớn, tăng
số lượng các lĩnh vực có thể cải thiện hiệu suất bằng cách giảm số lượng
bản dịch lại cần thiết. Các ngành được phân bổ theo yêu cầu. Sau khi được phân bổ, một khu vực có thể
không bao giờ được giải phóng và chiếm không gian đáng kể, tùy thuộc vào công cụ và giá trị
of --avg-transtab-entry-size (khoảng 40 MB mỗi sector cho Memcheck). Sử dụng tùy chọn
--stats = vâng để có được thông tin chính xác về bộ nhớ được sử dụng bởi một khu vực và
phân bổ và tái chế các lĩnh vực.

--avg-transtab-entry-size = [vỡ nợ: 0, có nghĩa là sử dụng công cụ cung cấp vỡ nợ]
Kích thước trung bình của khối cơ bản đã dịch. Kích thước trung bình này được sử dụng để kích thước
quy mô của một khu vực. Mỗi công cụ cung cấp một giá trị mặc định được sử dụng. Nếu giá trị mặc định này
quá nhỏ, các lĩnh vực dịch thuật sẽ trở nên đầy quá nhanh chóng. Nếu điều này mặc định
giá trị quá lớn, một phần đáng kể của bộ nhớ khu vực dịch sẽ không được sử dụng.
Lưu ý rằng kích thước trung bình của một bản dịch khối cơ bản phụ thuộc vào công cụ và có thể
phụ thuộc vào các tùy chọn công cụ. Ví dụ: tùy chọn ghi nhớ --track-origin = yes tăng
kích thước của các bản dịch khối cơ bản. Sử dụng --avg-transtab-entry-size để điều chỉnh
kích thước của các cung, để đạt được bộ nhớ hoặc để tránh quá nhiều phiên dịch lại.

--aspace-minaddr = [vỡ nợ: phụ thuộc on các nền tảng]
Để tránh xung đột tiềm ẩn với một số thư viện hệ thống, Valgrind không sử dụng
không gian địa chỉ bên dưới --aspace-minaddr giá trị, giữ nó được bảo lưu trong trường hợp một thư viện
đặc biệt yêu cầu bộ nhớ trong vùng này. Vì vậy, một số giá trị "bi quan" được đoán
bởi Valgrind tùy thuộc vào nền tảng. Trên linux, theo mặc định, Valgrind tránh sử dụng
64MB đầu tiên ngay cả khi thường không có xung đột trong vùng hoàn chỉnh này. Bạn có thể dùng
tùy chọn --aspace-minaddr để ứng dụng đói bộ nhớ của bạn được hưởng lợi từ
nhiều bộ nhớ thấp hơn này. Mặt khác, nếu bạn gặp phải một xung đột, ngày càng tăng
giá trị aspace-minaddr có thể giải quyết nó. Xung đột thường sẽ tự biểu hiện bằng
lỗi mmap trong phạm vi thấp của không gian địa chỉ. Địa chỉ được cung cấp phải là trang
được căn chỉnh và phải bằng hoặc lớn hơn thành 0x1000 (4KB). Để tìm giá trị mặc định trên
nền tảng, hãy làm điều gì đó chẳng hạn như valgrind -d -d date 2> & 1 | grep -i minaddr. Giá trị
thấp hơn 0x10000 (64KB) được biết là có thể gây ra sự cố trên một số bản phân phối.

--valgrind-stacksize = [vỡ nợ: 1 MB]
Đối với mỗi luồng, Valgrind cần ngăn xếp 'riêng tư' của riêng nó. Kích thước mặc định cho những
ngăn xếp chủ yếu có kích thước, và như vậy là đủ trong hầu hết các trường hợp. Trong trường hợp
kích thước quá nhỏ, Valgrind sẽ mặc định. Trước khi mặc định, một cảnh báo có thể là
do Valgrind sản xuất khi gần đến giới hạn.

Sử dụng tùy chọn --valgrind-stacksize nếu một cảnh báo (không chắc) như vậy được tạo ra, hoặc
Valgrind chết do vi phạm phân đoạn. Các vi phạm phân đoạn như vậy đã được
được thấy khi tách các ký hiệu C ++ khổng lồ.

Nếu ứng dụng của bạn sử dụng nhiều luồng và cần nhiều bộ nhớ, bạn có thể đạt được một số
bộ nhớ bằng cách giảm kích thước của các ngăn xếp Valgrind này bằng cách sử dụng tùy chọn
--valgrind-stacksize.

--show-emwarns = [vỡ nợ: không]
Khi được kích hoạt, Valgrind sẽ phát ra cảnh báo về khả năng giả lập CPU của nó trong một số trường hợp nhất định.
Những điều này thường không thú vị.

--require-text-Symbol =: sonamepatt: fnnamepatt
Khi một đối tượng được chia sẻ có tên trùng khớp sonamepatt được tải vào quy trình,
kiểm tra tất cả các ký hiệu văn bản mà nó xuất ra. Nếu không có ai trong số đó phù hợp fnnamepatt, in một
thông báo lỗi và bỏ chạy. Điều này giúp bạn có thể đảm bảo rằng quá trình chạy diễn ra
không tiếp tục trừ khi một đối tượng được chia sẻ nhất định có chứa một tên hàm cụ thể.

Cả hai sonamepatt và fnnamepatt có thể được viết bằng cách sử dụng thông thường ? và * ký tự đại diện. Vì
thí dụ: ": * libc.so *: foo? bar". Bạn có thể sử dụng các ký tự khác ngoài dấu hai chấm để phân tách
hai mẫu. Điều quan trọng chỉ là ký tự đầu tiên và dấu phân tách
nhân vật giống nhau. Ví dụ, ví dụ trên cũng có thể được viết
"Q * libc.so * Qfoo? Bar". Nhiều
--require-text-Symbol cờ được cho phép, trong trường hợp đó các đối tượng được chia sẻ được tải
vào quá trình sẽ được kiểm tra đối với tất cả chúng.

Mục đích của việc này là để hỗ trợ việc sử dụng đáng tin cậy các thư viện được đánh dấu. Ví dụ,
giả sử chúng ta có một phiên bản của GCC's libgomp.so đã được đánh dấu bằng
chú thích để hỗ trợ Helgrind. Nó chỉ là quá dễ dàng và khó hiểu để tải sai,
không chú thích libgomp.so vào ứng dụng. Vì vậy, ý tưởng là: thêm một ký hiệu văn bản trong
thư viện được đánh dấu, chẳng hạn chú thích_for_helgrind_3_6, và sau đó đưa cờ
--require-text-Symbol =: * libgomp * so *: annotated_for_helgrind_3_6 để khi libgomp.so
được tải, Valgrind sẽ quét bảng biểu tượng của nó và nếu biểu tượng không hiện diện thì chạy
đã hủy bỏ, thay vì tiếp tục im lặng với thư viện chưa được đánh dấu. Lưu ý rằng bạn
nên đặt toàn bộ cờ trong dấu ngoặc kép để ngăn chặn các vỏ mở rộng * và ?
ký tự đại diện.

--soname-từ đồng nghĩa = syn1 = pattern1, syn2 = pattern2, ...
Khi một thư viện được chia sẻ được tải, Valgrind sẽ kiểm tra các chức năng trong thư viện
phải được thay thế hoặc bọc lại. Ví dụ: Memcheck thay thế tất cả các liên quan đến malloc
các hàm (malloc, free, calloc, ...) với các phiên bản riêng. Những sự thay thế như vậy là
được thực hiện theo mặc định chỉ trong các thư viện được chia sẻ có tên khớp với tên được xác định trước
mẫu (ví dụ: libc.so * trên linux). Theo mặc định, không có thay thế nào được thực hiện cho một
thư viện liên kết hoặc cho các thư viện thay thế như tcmalloc. Trong một số trường hợp,
thay thế cho phép --soname-từ đồng nghĩa để chỉ định một mẫu từ đồng nghĩa bổ sung, đưa ra
linh hoạt trong việc thay thế.

Hiện tại, tính linh hoạt này chỉ được phép đối với các chức năng liên quan đến malloc, bằng cách sử dụng
từ đồng nghĩa somalloc. Từ đồng nghĩa này có thể sử dụng được cho tất cả các công cụ thay thế tiêu chuẩn
các chức năng liên quan đến malloc (ví dụ: memcheck, massif, drd, helgrind, exp-dhat,
thí nghiệm-sgk).

· Thư viện malloc thay thế: để thay thế các chức năng liên quan đến malloc trong một thư viện thay thế
thư viện với soname mymalloclib.so, đưa ra tùy chọn
--soname-từ đồng nghĩa = somalloc = mymalloclib.so. Một mẫu có thể được sử dụng để kết hợp nhiều
tên thư viện. Ví dụ, --soname-từ đồng nghĩa = somalloc = * tcmalloc * sẽ phù hợp
tên của tất cả các biến thể của thư viện tcmalloc (gốc, gỡ lỗi, cấu hình, ...
biến thể tcmalloc).

Lưu ý: tên của thư viện chia sẻ elf có thể được truy xuất bằng cách sử dụng bản thân
tiện ích.

· Việc thay thế trong một thư viện được liên kết tĩnh được thực hiện bằng cách sử dụng NONE mô hình.
Ví dụ: nếu bạn liên kết với libtcmalloc.a, memcheck sẽ hoạt động bình thường khi bạn
đưa ra tùy chọn --soname-từ đồng nghĩa = somalloc = KHÔNG. Lưu ý rằng mẫu KHÔNG CÓ sẽ
khớp với tệp thực thi chính và bất kỳ thư viện được chia sẻ nào không có soname.

· Để chạy bản dựng Firefox "mặc định" cho Linux, trong đó JEMalloc được liên kết với
thực thi chính, sử dụng --soname-từ đồng nghĩa = somalloc = KHÔNG.

NỢ GIÁ TRỊ LỰA CHỌN

Ngoài ra còn có một số tùy chọn để gỡ lỗi chính Valgrind. Bạn không cần phải sử dụng chúng
trong quá trình hoạt động bình thường của mọi thứ. Nếu bạn muốn xem danh sách, hãy sử dụng --help-gỡ lỗi tùy chọn.

KIỂM TRA LỰA CHỌN

--leak-check = [vỡ nợ: tóm lược]
Khi được bật, tìm kiếm rò rỉ bộ nhớ khi chương trình khách kết thúc. Nếu được đặt thành
tóm tắt, nó cho biết có bao nhiêu lần rò rỉ xảy ra. Nếu được đặt thành Full or Vâng, từng rò rỉ riêng lẻ
sẽ được hiển thị chi tiết và / hoặc được tính là lỗi, như được chỉ định bởi các tùy chọn
--show-rò rỉ-các loại và - lỗi-cho-rò-rỉ-các loại.

--leak-Resolution = [vỡ nợ: cao]
Khi thực hiện kiểm tra rò rỉ, hãy xác định mức độ sẵn sàng của Memcheck để xem xét sự khác biệt
các dấu vết giống nhau vì mục đích hợp nhất nhiều chỗ rò rỉ thành một
báo cáo rò rỉ. Khi đặt thành thấp, chỉ có hai mục đầu tiên cần khớp. Khi nào med, bốn
mục nhập phải phù hợp. Khi nào cao, tất cả các mục nhập cần phải khớp.

Để gỡ lỗi rò rỉ khó khăn, bạn có thể muốn sử dụng --leak-Resolution = cao bên nhau
với --num-calllers = 40 hoặc một số lớn như vậy.

Lưu ý rằng --leak-Resolution cài đặt không ảnh hưởng đến khả năng tìm thấy của Memcheck
rò rỉ. Nó chỉ thay đổi cách trình bày kết quả.

--show-rò rỉ-loại = [vỡ nợ: xác định, có thể]
Chỉ định các loại rò rỉ để hiển thị trong Full tìm kiếm rò rỉ, bằng một trong những cách sau:

· Danh sách được phân tách bằng dấu phẩy của một hoặc nhiều xác định không trực tiếp có thể có thể tiếp cận.

· tất cả các để chỉ định bộ hoàn chỉnh (tất cả các loại rò rỉ). Nó tương đương với
--show-rò rỉ-loại = xác định, gián tiếp, có thể, có thể tiếp cận.

· không ai cho tập hợp trống.

--errors-cho-rò rỉ-loại = [vỡ nợ: xác định, có thể]
Chỉ định các loại rò rỉ được tính là lỗi trong Full tìm kiếm rò rỉ. Các is
được chỉ định tương tự như --show-rò rỉ-các loại

--leak-check-heuristics = [vỡ nợ: tất cả các]
Chỉ định tập hợp các kinh nghiệm kiểm tra rò rỉ sẽ được sử dụng trong quá trình tìm kiếm rò rỉ. Các
heuristics kiểm soát con trỏ bên trong nào đến một khối khiến nó được coi là
có thể tiếp cận được. Tập hợp heuristic được chỉ định theo một trong những cách sau:

· Danh sách được phân tách bằng dấu phẩy của một hoặc nhiều chuỗi tiêu chuẩn chiều dài64 mảng mới
sự kế thừa.

· tất cả các để kích hoạt tập hợp đầy đủ các phương pháp phỏng đoán. Nó tương đương với
--leak-check-heuristics = stdstring, length64, newarray, multipleinheritance.

· không ai cho tập hợp trống.

Lưu ý rằng những kinh nghiệm này phụ thuộc vào bố cục của các đối tượng được tạo ra bởi
Trình biên dịch C ++. Chúng đã được thử nghiệm với một số phiên bản gcc (ví dụ: 4.4 và 4.7). Họ
có thể không hoạt động bình thường với các trình biên dịch C ++ khác.

--show-Reahable = , --show-could-lost =
Các tùy chọn này cung cấp một cách thay thế để chỉ định các loại rò rỉ sẽ hiển thị:

· --show-Reahable = không --show-could-lost = vâng tương đương với
--show-rò rỉ-loại = xác định, có thể.

· --show-Reahable = không --show-could-lost = không tương đương với
--show-rò rỉ-loại = xác định.

· --show-Reahable = vâng tương đương với --show-rò rỉ-loại = tất cả.

Lưu ý rằng --show-could-lost = không không có hiệu lực nếu --show-Reahable = vâng được quy định.

--undef-value-error = [vỡ nợ: đúng]
Kiểm soát xem Memcheck báo cáo có sử dụng lỗi giá trị không xác định hay không. Đặt cái này thành Không if
bạn không muốn thấy lỗi giá trị không xác định. Nó cũng có tác dụng phụ là tăng tốc độ
lên Memcheck phần nào.

--track-origin = [vỡ nợ: không]
Kiểm soát xem Memcheck có theo dõi nguồn gốc của các giá trị chưa được khởi tạo hay không. Theo mặc định, nó
không, có nghĩa là mặc dù nó có thể cho bạn biết rằng một giá trị chưa được khởi tạo là
được sử dụng theo cách nguy hiểm, nó không thể cho bạn biết giá trị chưa được khởi tạo đến từ đâu
từ. Điều này thường gây khó khăn cho việc theo dõi vấn đề gốc rễ.

Khi đặt thành Vâng, Memcheck theo dõi nguồn gốc của tất cả các giá trị chưa được khởi tạo.
Sau đó, khi lỗi giá trị chưa khởi tạo được báo cáo, Memcheck sẽ cố gắng hiển thị
nguồn gốc của giá trị. Nguồn gốc có thể là một trong bốn vị trí sau: khối đống,
phân bổ ngăn xếp, yêu cầu của khách hàng hoặc các nguồn khác (ví dụ: lệnh gọi đến
đứa trẻ).

Đối với các giá trị chưa được khởi tạo bắt nguồn từ khối heap, Memcheck hiển thị vị trí của khối
đã được phân bổ. Đối với các giá trị chưa được khởi tạo bắt nguồn từ phân bổ ngăn xếp, Memcheck
có thể cho bạn biết hàm nào đã phân bổ giá trị, nhưng không nhiều hơn thế - thường là nó
hiển thị cho bạn vị trí nguồn của dấu ngoặc nhọn mở của hàm. Bạn nên làm điều đó
kiểm tra cẩn thận để đảm bảo rằng tất cả các biến cục bộ của hàm đã được khởi tạo đúng cách.

Chi phí hoạt động: theo dõi xuất xứ rất tốn kém. Nó làm giảm một nửa tốc độ của Memcheck và
tăng mức sử dụng bộ nhớ lên tối thiểu 100MB và có thể hơn thế nữa. Tuy nhiên nó có thể
giảm đáng kể nỗ lực cần thiết để xác định nguyên nhân gốc rễ của việc không được làm sạch
lỗi giá trị và do đó thường là một chiến thắng năng suất của lập trình viên, mặc dù chạy nhiều hơn
chậm rãi.

Độ chính xác: Memcheck theo dõi nguồn gốc khá chính xác. Để tránh không gian và thời gian quá lớn
chi phí chung, một số ước tính được thực hiện. Có thể, mặc dù không chắc, điều đó
Memcheck sẽ báo xuất xứ không chính xác, hoặc không xác định được xuất xứ nào.

Lưu ý rằng sự kết hợp --track-origin = yes và --undef-value-error = không is
vô nghĩa. Memcheck kiểm tra và từ chối sự kết hợp này khi khởi động.

--partial-loading-ok = [vỡ nợ: đúng]
Kiểm soát cách Memcheck xử lý các tải 32-, 64-, 128- và 256-bit được căn chỉnh tự nhiên từ
địa chỉ mà một số byte có thể định địa chỉ được và một số byte khác thì không. Khi nào Vâng, như là
tải không tạo ra lỗi địa chỉ. Thay vào đó, các byte được tải có nguồn gốc từ bất hợp pháp
địa chỉ được đánh dấu là chưa được khởi tạo và những địa chỉ tương ứng với địa chỉ hợp pháp là
xử lý theo cách thông thường.

Thời Gian Không, tải từ các địa chỉ không hợp lệ một phần được coi giống như tải từ
địa chỉ hoàn toàn không hợp lệ: lỗi địa chỉ bất hợp pháp được đưa ra và kết quả là
byte được đánh dấu là đã khởi tạo.

Lưu ý rằng mã hoạt động theo cách này vi phạm tiêu chuẩn ISO C / C ++,
và nên được coi là hỏng. Nếu có thể, mã như vậy nên được sửa.

--expensive-xác định-kiểm tra = [vỡ nợ: không]
Kiểm soát xem Memcheck có nên sử dụng chính xác hơn nhưng cũng đắt hơn hay không (thời gian
tiêu thụ) các thuật toán khi kiểm tra tính xác định của một giá trị. Cài đặt mặc định là
không để làm điều đó và nó thường là đủ. Tuy nhiên, đối với mã được tối ưu hóa cao
valgrind đôi khi có thể phàn nàn không chính xác. Mời valgrind với
--expensive-xác định-kiểm tra = có hữu ích nhưng đi kèm với chi phí hiệu suất. Thời gian chạy
suy thoái 25% đã được quan sát thấy nhưng chi phí phụ thuộc rất nhiều vào
ứng dụng trong tầm tay.

--keep-stacktraces = cert | free | cert-and-free | cert-then-free | none [vỡ nợ:
cấp phát và miễn phí]
Kiểm soát (các) dấu vết ngăn xếp cần giữ cho các khối malloc'd và / hoặc free'd.

Với cấp phát sau đó miễn phí, một dấu vết ngăn xếp được ghi lại tại thời điểm phân bổ và được liên kết
với khối. Khi khối được giải phóng, dấu vết ngăn xếp thứ hai được ghi lại và điều này
thay thế dấu vết ngăn xếp phân bổ. Do đó, bất kỳ lỗi "sử dụng sau khi miễn phí" liên quan
đối với khối này chỉ có thể hiển thị một dấu vết ngăn xếp cho nơi khối được giải phóng.

Với cấp phát và miễn phí, cả phân bổ và dấu vết ngăn xếp phân bổ giao dịch cho khối
được cất giữ. Do đó, lỗi "sử dụng sau khi miễn phí" sẽ hiển thị cả hai, điều này có thể gây ra lỗi
dễ chẩn đoán hơn. So với cấp phát sau đó miễn phí, cài đặt này tăng lên một chút
Bộ nhớ của Valgrind sử dụng làm khối chứa hai tham chiếu thay vì một.

Với cấp phát, chỉ dấu vết ngăn xếp phân bổ được ghi lại (và được báo cáo). Với tự do,
chỉ dấu vết ngăn xếp phân bổ được ghi lại (và được báo cáo). Những giá trị này phần nào
giảm mức sử dụng bộ nhớ và cpu của Valgrind. Chúng có thể hữu ích tùy thuộc vào lỗi
loại bạn đang tìm kiếm và mức độ chi tiết bạn cần phân tích chúng. Vì
Ví dụ, nếu bạn chỉ quan tâm đến lỗi rò rỉ bộ nhớ, chỉ cần ghi lại
dấu vết ngăn xếp phân bổ.

Với không ai, không có dấu vết ngăn xếp nào được ghi lại cho các hoạt động malloc và miễn phí. Nếu là của bạn
chương trình phân bổ nhiều khối và / hoặc phân bổ / giải phóng khỏi nhiều ngăn xếp khác nhau
dấu vết, điều này có thể làm giảm đáng kể cpu và / hoặc bộ nhớ cần thiết. Tất nhiên, ít
chi tiết sẽ được báo cáo cho các lỗi liên quan đến khối đống.

Lưu ý rằng khi một dấu vết ngăn xếp được ghi lại, Valgrind sẽ giữ dấu vết ngăn xếp trong bộ nhớ
ngay cả khi nó không được tham chiếu bởi bất kỳ khối nào. Một số chương trình (ví dụ: đệ quy
thuật toán) có thể tạo ra một số lượng lớn các dấu vết ngăn xếp. Nếu Valgrind sử dụng quá nhiều
trong những trường hợp như vậy, bạn có thể giảm bộ nhớ cần thiết với các tùy chọn
--giữ ngăn xếp và / hoặc bằng cách sử dụng giá trị nhỏ hơn cho tùy chọn --num-calllers.

--freelist-vol = [vỡ nợ: 20000000]
Khi chương trình khách giải phóng bộ nhớ bằng cách sử dụng tự do (trong C) hoặc xóa (C ++), bộ nhớ đó
không có sẵn ngay lập tức để phân bổ lại. Thay vào đó, nó được đánh dấu
không thể truy cập và được đặt trong một hàng đợi các khối được giải phóng. Mục đích là để trì hoãn miễn là
có thể là thời điểm mà bộ nhớ được giải phóng trở lại lưu thông. Điều này
tăng cơ hội mà Memcheck sẽ có thể phát hiện các truy cập không hợp lệ vào các khối
trong một khoảng thời gian đáng kể sau khi chúng đã được giải phóng.

Tùy chọn này chỉ định tổng kích thước tối đa, tính bằng byte, của các khối trong hàng đợi.
Giá trị mặc định là hai mươi triệu byte. Tăng điều này sẽ làm tăng tổng số tiền
bộ nhớ được sử dụng bởi Memcheck nhưng có thể phát hiện việc sử dụng không hợp lệ của các khối đã giải phóng sẽ
nếu không thì không bị phát hiện.

--freelist-big-blocks = [vỡ nợ: 1000000]
Khi tạo các khối từ hàng đợi các khối giải phóng có sẵn để phân bổ lại,
Memcheck sẽ ưu tiên lưu hành lại các khối có kích thước lớn hơn hoặc bằng
--freelist-big-block. Điều này đảm bảo rằng giải phóng các khối lớn (đặc biệt là giải phóng
khối lớn hơn --freelist-vol) không ngay lập tức dẫn đến việc tái lưu hành
tất cả (hoặc nhiều) khối nhỏ trong danh sách miễn phí. Nói cách khác, tùy chọn này
tăng khả năng phát hiện ra các con trỏ lơ lửng cho các khối "nhỏ", thậm chí
khi các khối lớn được giải phóng.

Đặt giá trị 0 có nghĩa là tất cả các khối được lưu chuyển lại theo thứ tự FIFO.

--workaround-gcc296-bug = [vỡ nợ: không]
Khi được bật, giả sử rằng đọc và ghi một số khoảng cách nhỏ bên dưới con trỏ ngăn xếp
là do lỗi trong GCC 2.96 và không báo cáo chúng. "Khoảng cách nhỏ" là 256
byte theo mặc định. Lưu ý rằng GCC 2.96 là trình biên dịch mặc định trên một số Linux cổ
bản phân phối (RedHat 7.X) và vì vậy bạn có thể cần sử dụng tùy chọn này. Không sử dụng nó nếu
bạn không cần phải làm như vậy, vì nó có thể gây ra các lỗi thực sự không thể bỏ qua. Một sự thay thế tốt hơn
là sử dụng GCC mới hơn, trong đó lỗi này đã được sửa.

Bạn cũng có thể cần sử dụng tùy chọn này khi làm việc với GCC 3.X hoặc 4.X trên 32-bit
PowerPC Linux. Điều này là do GCC tạo mã đôi khi truy cập vào bên dưới
con trỏ ngăn xếp, đặc biệt cho các chuyển đổi dấu phẩy động đến / từ số nguyên. Điều này
vi phạm thông số kỹ thuật PowerPC ELF 32-bit, điều này không cung cấp cho
vị trí bên dưới con trỏ ngăn xếp để có thể truy cập.

--show-mismatching-frees = [vỡ nợ: đúng]
Khi được bật, Memcheck sẽ kiểm tra xem các khối heap có được phân bổ bằng cách sử dụng một hàm
khớp với chức năng phân bổ. Đó là, nó mong đợi tự do được sử dụng để phân bổ
các khối được phân bổ bởi malloc, xóa cho các khối được phân bổ bởi mớivà xóa bỏ[] cho
các khối được phân bổ bởi Mới[]. Nếu không khớp được phát hiện, một lỗi sẽ được báo cáo. Đây là trong
quan trọng chung vì trong một số môi trường, giải phóng với một chức năng không phù hợp
có thể gây ra sự cố.

Tuy nhiên, có một trường hợp không thể tránh khỏi những sự không khớp như vậy. Đó là khi
người dùng cung cấp triển khai của mới/Mới[] cuộc gọi đó malloc và xóa/xóa bỏ[]
cuộc gọi đó tự do, và các hàm này được nội tuyến không đối xứng. Ví dụ, hãy tưởng tượng
việc này xóa bỏ[] được nội tuyến nhưng Mới[] không phải. Kết quả là Memcheck "nhìn thấy" tất cả
xóa bỏ[] cuộc gọi dưới dạng cuộc gọi trực tiếp tới tự do, ngay cả khi nguồn chương trình không chứa
cuộc gọi không khớp.

Điều này gây ra rất nhiều báo cáo lỗi khó hiểu và không liên quan.
--show-mismatching-frees = no vô hiệu hóa các kiểm tra này. Nói chung không nên
Tuy nhiên, hãy vô hiệu hóa chúng, vì kết quả là bạn có thể bỏ lỡ các lỗi thực sự.

--ignore-range = 0xPP-0xQQ [, 0xRR-0xSS]
Bất kỳ phạm vi nào được liệt kê trong tùy chọn này (và nhiều phạm vi có thể được chỉ định, phân tách bằng
dấu phẩy) sẽ bị bỏ qua bởi tính năng kiểm tra khả năng địa chỉ của Memcheck.

--malloc-fill =
Điền vào các khối được phân bổ bởi malloc, new, v.v., nhưng không phải bởi calloc, với giá trị được chỉ định
byte. Điều này có thể hữu ích khi cố gắng giải quyết các vấn đề hỏng bộ nhớ ít người biết đến.
Khu vực được phân bổ vẫn được Memcheck coi là không xác định - chỉ tùy chọn này
ảnh hưởng đến nội dung của nó. Lưu ý rằng --malloc-điền không ảnh hưởng đến một khối bộ nhớ khi
nó được sử dụng làm đối số cho các yêu cầu của khách hàng VALGRIND_MEMPOOL_ALLOC hoặc
VALGRIND_MALLOCLIKE_BLOCK.

--free-fill =
Điền vào các khối được giải phóng bằng cách miễn phí, xóa, v.v., với giá trị byte được chỉ định. Điều này có thể là
hữu ích khi cố gắng giải quyết các vấn đề hỏng bộ nhớ ít người biết đến. Khu vực giải phóng là
vẫn được Memcheck coi là không hợp lệ để truy cập - tùy chọn này chỉ ảnh hưởng đến
các nội dung. Lưu ý rằng - điền đầy miễn phí không ảnh hưởng đến một khối bộ nhớ khi nó được sử dụng làm
đối số với các yêu cầu của khách hàng VALGRIND_MEMPOOL_FREE hoặc VALGRIND_FREELIKE_BLOCK.

bộ đệm LỰA CHỌN

--I1 = , , kích thước>
Chỉ định kích thước, tính liên kết và kích thước dòng của bộ đệm chỉ lệnh cấp 1.

--D1 = , , kích thước>
Chỉ định kích thước, tính liên kết và kích thước dòng của bộ đệm dữ liệu cấp 1.

--LL = , , kích thước>
Chỉ định kích thước, tính liên kết và kích thước dòng của bộ nhớ cache cấp cuối cùng.

--cache-sim = no | yes [Đúng]
Bật hoặc tắt bộ sưu tập truy cập bộ nhớ cache và bỏ lỡ số lượng.

--branch-sim = không | có [Không]
Cho phép hoặc vô hiệu hóa việc thu thập chỉ thị rẽ nhánh và đếm sai. Qua
mặc định điều này bị tắt vì nó làm chậm Cachegrind xuống khoảng 25%. Lưu ý rằng
bạn không thể chỉ định --cache-sim = không và --branch-sim = không cùng nhau, vì điều đó sẽ rời đi
Cachegrind mà không có thông tin để thu thập.

--cachegrind-out-file =
Ghi dữ liệu hồ sơ vào tệp thay vì vào tệp đầu ra mặc định,
cachegrind.out. . Các %p và %q định dạng định dạng có thể được sử dụng để nhúng quá trình
ID và / hoặc nội dung của một biến môi trường trong tên, như trường hợp của
lựa chọn cốt lõi --log-tệp.

GỌI GỌI LỰA CHỌN

--callgrind-out-file =
Ghi dữ liệu hồ sơ vào tệp thay vì vào tệp đầu ra mặc định,
callgrind.out. . Các %p và %q định dạng định dạng có thể được sử dụng để nhúng quá trình
ID và / hoặc nội dung của một biến môi trường trong tên, như trường hợp của
lựa chọn cốt lõi --log-tệp. Khi nhiều kết xuất được thực hiện, tên tệp được sửa đổi
hơn nữa; xem bên dưới.

--dump-line = [vỡ nợ: đúng]
Điều này chỉ định rằng việc đếm sự kiện phải được thực hiện ở mức độ chi tiết của dòng nguồn.
Điều này cho phép chú thích nguồn cho các nguồn được biên dịch với thông tin gỡ lỗi
(-g).

--dump-Guid = [vỡ nợ: không]
Điều này chỉ định rằng việc đếm sự kiện phải được thực hiện ở mức độ chi tiết của mỗi lệnh.
Điều này cho phép chú thích mã lắp ráp. Hiện tại kết quả chỉ có thể được hiển thị
bởi KCachegrind.

--compress-string = [vỡ nợ: đúng]
Tùy chọn này ảnh hưởng đến định dạng đầu ra của dữ liệu hồ sơ. Nó chỉ định liệu
chuỗi (tên tệp và hàm) phải được xác định bằng số. Điều này thu nhỏ
nhưng khiến con người khó đọc hơn (điều này không được khuyến nghị trong bất kỳ
trường hợp).

--compress-pos = [vỡ nợ: đúng]
Tùy chọn này ảnh hưởng đến định dạng đầu ra của dữ liệu hồ sơ. Nó chỉ định liệu
các vị trí số luôn được chỉ định là giá trị tuyệt đối hoặc được phép
so với các số trước đó. Điều này thu nhỏ kích thước tệp.

--combine-bãi = [vỡ nợ: không]
Khi được bật, khi tạo nhiều phần dữ liệu hồ sơ, các phần này sẽ
được nối vào cùng một tệp đầu ra. Không được khuyến khích.

--dump-every-bb = [vỡ nợ: 0, không bao giờ]
Kết xuất dữ liệu hồ sơ mỗi tính các khối cơ bản. Chỉ cần kiểm tra kết xuất có cần thiết hay không
khi bộ lập lịch nội bộ của Valgrind được chạy. Do đó, cài đặt tối thiểu hữu ích là
khoảng 100000. Số đếm là một giá trị 64 bit để có thể thực hiện các khoảng thời gian kết xuất dài.

--dump-before =
Bán phá giá khi vào chức năng.

--zero-before =
Không có tất cả các chi phí khi nhập chức năng.

--dump-after =
Bán phá giá khi rời đi chức năng.

--instr-atstart = [vỡ nợ: đúng]
Chỉ định nếu bạn muốn Callgrind bắt đầu mô phỏng và lập hồ sơ từ đầu
chương trình. Khi được đặt thành không, Callgrind sẽ không thể thu thập bất kỳ thông tin nào,
bao gồm cả các cuộc gọi, nhưng nó sẽ có tốc độ tối đa là khoảng 4, đây là mức tối thiểu
Valgrind chi phí. Công cụ đo lường có thể được kích hoạt tương tác thông qua callgrind_control
-i vào.

Lưu ý rằng biểu đồ cuộc gọi kết quả hầu hết có thể sẽ không chứa chính, nhưng sẽ
chứa tất cả các chức năng được thực thi sau khi thiết bị đo được kích hoạt. Thiết bị đo đạc
cũng có thể được bật / tắt theo chương trình. Xem Callgrind bao gồm tệp callgrind.h
đối với macro mà bạn phải sử dụng trong mã nguồn của mình.

Đối với mô phỏng bộ nhớ cache, kết quả sẽ kém chính xác hơn khi bật thiết bị đo
sau đó trong quá trình chạy chương trình, vì trình mô phỏng bắt đầu với bộ đệm trống tại thời điểm đó.
Bật bộ sưu tập sự kiện sau để đối phó với lỗi này.

--collect-atstart = [vỡ nợ: đúng]
Chỉ định xem bộ sưu tập sự kiện có được bật khi bắt đầu chạy hồ sơ hay không.

Để chỉ xem xét các phần của chương trình, bạn có hai khả năng:

1. Bộ đếm sự kiện XNUMX trước khi vào phần chương trình bạn muốn lập hồ sơ và kết xuất
sự kiện đếm vào một tệp sau khi rời khỏi phần chương trình đó.

2. Bật / tắt trạng thái bộ sưu tập nếu cần để chỉ xem các bộ đếm sự kiện đang diễn ra
trong khi bên trong phần chương trình mà bạn muốn lập hồ sơ.

Tùy chọn thứ hai có thể được sử dụng nếu phần chương trình bạn muốn cấu hình được gọi là nhiều
lần. Phương án 1, tức là tạo ra nhiều bãi chứa là không thực tế ở đây.

Trạng thái bộ sưu tập có thể được chuyển đổi khi nhập và thoát một chức năng nhất định với tùy chọn
--toggle-sưu tầm. Nếu bạn sử dụng tùy chọn này, trạng thái bộ sưu tập sẽ bị vô hiệu hóa tại
sự khởi đầu. Lưu ý rằng đặc điểm kỹ thuật của --toggle-sưu tầm bộ ngầm
--collect-state = không.

Trạng thái bộ sưu tập cũng có thể được chuyển đổi bằng cách chèn yêu cầu của khách hàng
CALLGRIND_TOGGLE_COLLECT; tại các vị trí mã cần thiết.

--toggle-sưu tầm =
Chuyển đổi bộ sưu tập khi vào / ra khỏi chức năng.

--collect-jumps = [vỡ nợ: không]
Điều này chỉ định liệu thông tin cho các bước nhảy (có điều kiện) có nên được thu thập hay không. Như
ở trên, callgrind_annotate hiện không thể hiển thị cho bạn dữ liệu. Bạn phải sử dụng
KCachegrind để nhận các mũi tên nhảy trong mã được chú thích.

--collect-systime = [vỡ nợ: không]
Điều này chỉ định liệu thông tin về thời gian gọi của hệ thống có nên được thu thập hay không.

--collect-bus = [vỡ nợ: không]
Điều này chỉ định xem có nên thu thập số lượng sự kiện bus toàn cầu được thực thi hay không.
Loại sự kiện "Ge" được sử dụng cho các sự kiện này.

--cache-sim = [vỡ nợ: không]
Chỉ định nếu bạn muốn thực hiện mô phỏng bộ đệm đầy đủ. Theo mặc định, chỉ đọc hướng dẫn
lượt truy cập sẽ được tính ("Ir"). Với mô phỏng bộ nhớ cache, các bộ đếm sự kiện khác
đã kích hoạt: Bộ nhớ cache bỏ sót lần đọc hướng dẫn ("I1mr" / "ILmr"), truy cập đọc dữ liệu ("Dr")
và bộ nhớ cache liên quan bỏ lỡ ("D1mr" / "DLmr"), truy cập ghi dữ liệu ("Dw") và bộ nhớ cache liên quan
bỏ lỡ ("D1mw" / "DLmw"). Để biết thêm thông tin, hãy xem Cachegrind: một bộ nhớ cache và nhánh-
hồ sơ dự đoán.

--branch-sim = [vỡ nợ: không]
Chỉ định xem bạn có muốn thực hiện mô phỏng dự đoán nhánh hay không. Các quầy sự kiện khác là
đã bật: Số nhánh có điều kiện được thực thi và bộ dự đoán liên quan bị bỏ lỡ
("Bc" / "Bcm"), thực hiện các bước nhảy gián tiếp và các lần bỏ lỡ liên quan của dự đoán địa chỉ bước nhảy
("Bi" / "Bỉm").

GIÚP ĐỠ LỰA CHỌN

--free-is-write = no | yes [vỡ nợ: không]
Khi được bật (không phải mặc định), Helgrind xử lý việc giải phóng bộ nhớ heap như thể
bộ nhớ đã được ghi ngay lập tức trước khi miễn phí. Điều này cho thấy các cuộc đua mà bộ nhớ là
được tham chiếu bởi một chuỗi và được giải phóng bởi một chuỗi khác, nhưng không có
sự kiện đồng bộ hóa để đảm bảo rằng tham chiếu xảy ra trước khi miễn phí.

Chức năng này là mới trong Valgrind 3.7.0 và được coi là thử nghiệm. Nó là
không được bật theo mặc định vì tương tác của nó với trình cấp phát bộ nhớ tùy chỉnh không
hiểu rõ ở hiện tại. Phản hồi của người dùng được hoan nghênh.

--track-lockorders = không | có [vỡ nợ: đúng]
Khi được bật (mặc định), Helgrind thực hiện kiểm tra tính nhất quán của thứ tự khóa. Vì
một số chương trình có lỗi, số lượng lớn các lỗi lệnh khóa được báo cáo có thể trở thành
khó chịu, đặc biệt nếu bạn chỉ quan tâm đến các lỗi cuộc đua. Do đó bạn có thể
thấy hữu ích khi tắt tính năng kiểm tra lệnh khóa.

--history-level = không có | xấp xỉ | đầy đủ [vỡ nợ: đầy]
--history-level = full (mặc định) khiến Helgrind thu thập đủ thông tin về
quyền truy cập "cũ" mà nó có thể tạo ra hai dấu vết ngăn xếp trong một báo cáo cuộc đua - cả hai ngăn xếp
theo dõi cho truy cập hiện tại và theo dõi cho truy cập cũ hơn, xung đột. Đến
giới hạn sử dụng bộ nhớ, dấu vết ngăn xếp truy cập "cũ" được giới hạn ở mức tối đa 8 mục nhập,
ngay cả khi --num-calllers giá trị lớn hơn.

Việc thu thập thông tin như vậy rất tốn kém cả về tốc độ và bộ nhớ, đặc biệt là đối với
các chương trình thực hiện nhiều sự kiện đồng bộ hóa liên luồng (khóa, mở khóa, v.v.).
Nếu không có thông tin như vậy, việc truy tìm nguyên nhân gốc rễ của các cuộc đua trở nên khó khăn hơn.
Tuy nhiên, bạn có thể không cần nó trong các tình huống mà bạn chỉ muốn kiểm tra
sự hiện diện hoặc vắng mặt của chủng tộc, ví dụ, khi thực hiện kiểm tra hồi quy của một
chương trình không có cuộc đua trước đây.

--history-level = không có là cực ngược lại. Nó khiến Helgrind không thu thập bất kỳ
thông tin về các lần truy cập trước đó. Điều này có thể nhanh hơn đáng kể so với
--history-level = full.

--history-level = xấp xỉ cung cấp một sự thỏa hiệp giữa hai thái cực này. Điều đó gây ra
Hỗ trợ để hiển thị đầy đủ dấu vết cho việc truy cập sau này và thông tin gần đúng
liên quan đến quyền truy cập sớm hơn. Thông tin gần đúng này bao gồm hai ngăn xếp và
truy cập sớm hơn được đảm bảo đã xảy ra ở đâu đó giữa các điểm chương trình
được biểu thị bằng hai ngăn xếp. Điều này không hữu ích bằng việc hiển thị ngăn xếp chính xác cho
quyền truy cập trước đó (với tư cách là --history-level = full không), nhưng tốt hơn là không có gì, và nó
gần như nhanh như --history-level = không có.

--conflict-cache-size = N [vỡ nợ: 1000000]
Cờ này chỉ có hiệu lực tại --history-level = full.

Thông tin về các truy cập xung đột "cũ" được lưu trữ trong bộ nhớ cache có kích thước hạn chế,
với quản lý kiểu LRU. Điều này là cần thiết vì không thực tế để lưu trữ
dấu vết ngăn xếp cho mỗi lần truy cập bộ nhớ duy nhất được thực hiện bởi chương trình. Thông tin lịch sử
trên các vị trí không được truy cập gần đây sẽ bị loại bỏ định kỳ, để giải phóng dung lượng trong
bộ nhớ cache.

Tùy chọn này kiểm soát kích thước của bộ nhớ cache, về số lượng bộ nhớ khác nhau
các địa chỉ mà thông tin truy cập xung đột được lưu trữ. Nếu bạn thấy rằng
Helgrind đang hiển thị lỗi cuộc đua với chỉ một ngăn xếp thay vì hai ngăn xếp như mong đợi
ngăn xếp, hãy thử tăng giá trị này.

Giá trị tối thiểu là 10,000 và giá trị tối đa là 30,000,000 (gấp ba mươi lần giá trị mặc định
giá trị). Việc tăng giá trị lên 1 sẽ làm tăng yêu cầu bộ nhớ của Helgrind lên rất nhiều
khoảng 100 byte, vì vậy giá trị tối đa sẽ dễ dàng tiêu tốn thêm ba gigabyte hoặc hơn
của bộ nhớ.

--check-stack-refs = no | yes [vỡ nợ: đúng]
Theo mặc định, Helgrind kiểm tra tất cả các truy cập bộ nhớ dữ liệu do chương trình của bạn thực hiện. Cờ này
cho phép bạn bỏ qua việc kiểm tra quyền truy cập vào ngăn xếp luồng (biến cục bộ). Cái này có thể
cải thiện hiệu suất, nhưng phải trả giá bằng việc bỏ lỡ các cuộc đua trên dữ liệu được phân bổ theo ngăn xếp.

--ignore-thread-create = [vỡ nợ: không]
Kiểm soát xem có nên bỏ qua tất cả các hoạt động trong quá trình tạo luồng hay không. Theo mặc định
chỉ được bật trên Solaris. Solaris cung cấp thông lượng cao hơn, song song và
khả năng mở rộng hơn các hệ điều hành khác, với chi phí khóa chi tiết hơn
hoạt động. Điều này có nghĩa là ví dụ: khi một chuỗi được tạo dưới glibc, chỉ một
khóa lớn được sử dụng cho tất cả các thiết lập luồng. Solaris libc sử dụng một số khóa tinh xảo
và chuỗi người tạo tiếp tục các hoạt động của nó càng sớm càng tốt, chẳng hạn như rời khỏi
ngăn xếp và trình tự thiết lập TLS cho luồng đã tạo. Tình huống này khiến Helgrind bối rối
vì nó giả định rằng có một số thứ tự sai giữa người tạo và người tạo
chủ đề; và do đó nhiều loại điều kiện chủng tộc trong ứng dụng sẽ không
đã báo cáo. Để ngăn chặn thứ tự sai như vậy, tùy chọn dòng lệnh này được đặt thành có bằng cách
mặc định trên Solaris. Do đó, tất cả hoạt động (tải, cửa hàng, yêu cầu của khách hàng) đều bị bỏ qua
suốt trong:

· Pthread_create () gọi trong chuỗi người tạo

· Giai đoạn tạo luồng (thiết lập ngăn xếp và TLS) trong luồng đã tạo

Ngoài ra, bộ nhớ mới được cấp phát trong quá trình tạo luồng không được theo dõi, đó là báo cáo cuộc đua
bị đàn áp ở đó. DRD ngầm thực hiện điều tương tự. Điều này là cần thiết bởi vì
Solaris libc lưu trữ nhiều đối tượng và sử dụng lại chúng cho các chủ đề khác nhau và
làm Helgrind bối rối.

DRD LỰA CHỌN

--check-stack-var = [vỡ nợ: không]
Kiểm soát xem DRD có phát hiện các cuộc đua dữ liệu trên các biến ngăn xếp hay không. Xác minh các biến ngăn xếp
bị tắt theo mặc định vì hầu hết các chương trình không chia sẻ các biến ngăn xếp trên
chủ đề.

--exclusive-ngưỡng = [vỡ nợ: tắt]
In thông báo lỗi nếu bất kỳ khóa mutex hoặc khóa văn bản nào đã được giữ lâu hơn thời gian
được chỉ định bằng mili giây. Tùy chọn này cho phép phát hiện sự tranh chấp khóa.

--join-list-vol = [vỡ nợ: 10]
Các cuộc đua dữ liệu xảy ra giữa một câu lệnh ở cuối một chuỗi và một chuỗi khác
có thể bị bỏ lỡ nếu thông tin truy cập bộ nhớ bị loại bỏ ngay sau khi một chuỗi có
đã được tham gia. Tùy chọn này cho phép người ta chỉ định bao nhiêu bộ nhớ chuỗi đã tham gia
thông tin truy cập cần được giữ lại.

--first-race-only = [vỡ nợ: không]
Có báo cáo chỉ cuộc đua dữ liệu đầu tiên đã được phát hiện trên một vị trí bộ nhớ hay không
hoặc tất cả các chủng tộc dữ liệu đã được phát hiện trên một vị trí bộ nhớ.

--free-is-write = [vỡ nợ: không]
Có báo cáo cuộc đua giữa truy cập bộ nhớ và giải phóng bộ nhớ hay không. Kích hoạt điều này
tùy chọn này có thể khiến DRD chạy chậm hơn một chút. Ghi chú:

· Không bật tùy chọn này khi sử dụng trình cấp phát bộ nhớ tùy chỉnh sử dụng
VG_USERREQ__MALLOCLIKE_BLOCK và VG_USERREQ__FREELIKE_BLOCK vì điều đó sẽ
dẫn đến kết quả dương tính giả.

· Không bật tùy chọn này khi sử dụng các đối tượng được đếm tham chiếu vì điều đó sẽ
dẫn đến kết quả dương tính giả, ngay cả khi mã đó đã được chú thích đúng với
ANNOTATE_HAPPENS_BEFORE và ANNOTATE_HAPPENS_AFTER. Xem ví dụ: đầu ra của
ví dụ lệnh sau: valgrind --tool = drd --free-is-write = yes
drd / tests / annotate_smart_pointer.

--report-signal-unlock = [vỡ nợ: đúng]
Có báo cáo cuộc gọi đến pthread_cond_signal và pthread_cond_broadcast nơi
mutex được liên kết với tín hiệu thông qua pthread_cond_wait or
pthread_cond_timed_waitkhông bị khóa tại thời điểm tín hiệu được gửi đi. Gửi tín hiệu
không giữ khóa trên mutex liên quan là một lỗi lập trình phổ biến có thể
gây ra các điều kiện chủng tộc tinh vi và hành vi không thể đoán trước. Tồn tại một số không phổ biến
tuy nhiên, các mẫu đồng bộ hóa nơi có thể an toàn để gửi tín hiệu mà không cần giữ
khóa trên mutex liên quan.

--segment-merge = [vỡ nợ: đúng]
Kiểm soát việc hợp nhất phân đoạn. Hợp nhất phân đoạn là một thuật toán để giới hạn việc sử dụng bộ nhớ của
thuật toán phát hiện chủng tộc dữ liệu. Việc tắt hợp nhất phân đoạn có thể cải thiện độ chính xác của
cái gọi là 'phân đoạn khác' được hiển thị trong báo cáo cuộc đua nhưng cũng có thể gây ra
lỗi bộ nhớ.

- phân đoạn-hợp nhất-khoảng thời gian = [vỡ nợ: 10]
Chỉ thực hiện hợp nhất phân đoạn sau khi số lượng phân đoạn mới được chỉ định đã được
tạo. Đây là một tùy chọn cấu hình nâng cao cho phép người ta chọn xem có
giảm thiểu việc sử dụng bộ nhớ của DRD bằng cách chọn một giá trị thấp hoặc để DRD chạy nhanh hơn bằng cách
chọn giá trị cao hơn một chút. Giá trị tối ưu cho tham số này phụ thuộc vào
chương trình đang được phân tích. Giá trị mặc định hoạt động tốt cho hầu hết các chương trình.

- chia sẻ-ngưỡng = [vỡ nợ: tắt]
In thông báo lỗi nếu khóa đầu đọc được giữ lâu hơn thời gian quy định
(tính bằng mili giây). Tùy chọn này cho phép phát hiện sự tranh chấp khóa.

--show-confl-seg = [vỡ nợ: đúng]
Hiển thị các phân đoạn xung đột trong báo cáo cuộc đua. Vì thông tin này có thể giúp tìm ra
nguyên nhân của một cuộc chạy đua dữ liệu, tùy chọn này được bật theo mặc định. Vô hiệu hóa tùy chọn này làm cho
đầu ra của DRD nhỏ gọn hơn.

--show-stack-using = [vỡ nợ: không]
Sử dụng ngăn xếp in tại thời gian thoát luồng. Khi một chương trình tạo ra một số lượng lớn
luồng nó trở nên quan trọng để giới hạn số lượng bộ nhớ ảo được phân bổ cho
ngăn xếp luồng. Tùy chọn này giúp bạn có thể quan sát bộ nhớ ngăn xếp đã được
được sử dụng bởi mỗi luồng của chương trình khách hàng. Lưu ý: công cụ DRD tự phân bổ một số
dữ liệu tạm thời trên ngăn xếp luồng máy khách. Không gian cần thiết cho dữ liệu tạm thời này
phải được cấp phát bởi chương trình khách khi nó cấp phát bộ nhớ ngăn xếp, nhưng không
bao gồm trong việc sử dụng ngăn xếp do DRD báo cáo.

--ignore-thread-create = [vỡ nợ: không]
Kiểm soát xem có nên bỏ qua tất cả các hoạt động trong quá trình tạo luồng hay không. Theo mặc định
chỉ được bật trên Solaris. Solaris cung cấp thông lượng cao hơn, song song và
khả năng mở rộng hơn các hệ điều hành khác, với chi phí khóa chi tiết hơn
hoạt động. Điều này có nghĩa là ví dụ: khi một chuỗi được tạo dưới glibc, chỉ một
khóa lớn được sử dụng cho tất cả các thiết lập luồng. Solaris libc sử dụng một số khóa tinh xảo
và chuỗi người tạo tiếp tục các hoạt động của nó càng sớm càng tốt, chẳng hạn như rời khỏi
ngăn xếp và trình tự thiết lập TLS cho luồng đã tạo. Tình huống này gây nhầm lẫn cho DRD vì nó
giả sử có một số thứ tự sai giữa người tạo và luồng được tạo; và
do đó nhiều loại điều kiện chủng tộc trong ứng dụng sẽ không được báo cáo. Đến
ngăn chặn thứ tự sai như vậy, tùy chọn dòng lệnh này được đặt thành có theo mặc định trên
Solaris. Do đó, tất cả hoạt động (tải, cửa hàng, yêu cầu của khách hàng) đều bị bỏ qua trong thời gian:

· Pthread_create () gọi trong chuỗi người tạo

· Giai đoạn tạo luồng (thiết lập ngăn xếp và TLS) trong luồng đã tạo

--trace-addr = [vỡ nợ: không ai]
Theo dõi tất cả hoạt động tải và lưu trữ cho địa chỉ được chỉ định. Tùy chọn này có thể là
được chỉ định nhiều hơn một lần.

--ptrace-addr = [vỡ nợ: không ai]
Theo dõi tất cả hoạt động tải và lưu trữ cho địa chỉ được chỉ định và tiếp tục làm điều đó ngay cả
sau khi bộ nhớ tại địa chỉ đó đã được giải phóng và phân bổ lại.

--trace-Distribution = [vỡ nợ: không]
Theo dõi tất cả các phân bổ bộ nhớ và phân bổ giao dịch. Có thể tạo ra một lượng lớn sản lượng.

--trace-rào cản = [vỡ nợ: không]
Theo dõi tất cả các hoạt động của rào cản.

--trace-cond = [vỡ nợ: không]
Theo dõi tất cả hoạt động của biến điều kiện.

--trace-fork-join = [vỡ nợ: không]
Theo dõi tất cả quá trình tạo luồng và tất cả các sự kiện kết thúc luồng.

--trace-hb = [vỡ nợ: không]
Theo dõi thực thi ANNOTATE_HAPPENS_BEFORE (), ANNOTATE_HAPPENS_AFTER () và
ANNOTATE_HAPPENS_DONE () khách hàng yêu cầu.

--trace-mutex = [vỡ nợ: không]
Theo dõi tất cả hoạt động của mutex.

--trace-rwlock = [vỡ nợ: không]
Theo dõi tất cả hoạt động khóa người đọc-người viết.

--trace-semaphore = [vỡ nợ: không]
Theo dõi tất cả hoạt động semaphore.

KHỔNG LỒ LỰA CHỌN

--heap = [vỡ nợ: đúng]
Chỉ định xem có nên thực hiện cấu hình đống.

--heap-admin = [vỡ nợ: 8]
Nếu cấu hình heap được bật, hãy cung cấp số byte quản trị trên mỗi khối cho
sử dụng. Đây phải là một ước tính của mức trung bình, vì nó có thể thay đổi. Ví dụ,
bộ cấp phát được sử dụng bởi glibc trên Linux yêu cầu khoảng từ 4 đến 15 byte cho mỗi khối,
tùy thuộc vào các yếu tố khác nhau. Trình phân bổ đó cũng yêu cầu không gian quản trị để được giải phóng
khối, nhưng Massif không thể giải thích điều này.

--stacks = [vỡ nợ: không]
Chỉ định xem có nên thực hiện cấu hình ngăn xếp hay không. Tùy chọn này làm chậm Massif xuống
rất nhiều, và vì vậy bị tắt theo mặc định. Lưu ý rằng Massif giả định rằng ngăn xếp chính có
kích thước bằng không khi khởi động. Điều này không đúng, nhưng làm khác đi một cách chính xác thì rất khó.
Hơn nữa, bắt đầu từ XNUMX tốt hơn cho biết kích thước của phần của ngăn xếp chính
mà một chương trình người dùng thực sự có quyền kiểm soát.

--pages-as-heap = [vỡ nợ: không]
Cho Massif biết với bộ nhớ cấu hình ở cấp độ trang chứ không phải ở khối malloc'd
cấp độ. Xem ở trên để biết chi tiết.

--depth = [vỡ nợ: 30]
Độ sâu tối đa của các cây phân bổ được ghi lại để có ảnh chụp nhanh chi tiết. Tăng nó
sẽ làm cho Massif chạy chậm hơn, sử dụng nhiều bộ nhớ hơn và tạo ra đầu ra lớn hơn
các tập tin.

--alloc-fn =
Các chức năng được chỉ định với tùy chọn này sẽ được coi như thể chúng là một đống
chức năng phân bổ chẳng hạn như malloc. Điều này hữu ích cho các chức năng là trình bao bọc
malloc or mới, có thể lấp đầy các cây phân bổ với thông tin không thú vị.
Tùy chọn này có thể được chỉ định nhiều lần trên dòng lệnh, để đặt tên cho nhiều
chức năng.

Lưu ý rằng hàm được đặt tên sẽ chỉ được xử lý theo cách này nếu nó là mục nhập hàng đầu trong một
dấu vết ngăn xếp, hoặc ngay bên dưới một hàm khác được xử lý theo cách này. Ví dụ, nếu bạn có
một chức năng malloc1 kết thúc mallocvà malloc2 kết thúc malloc1, chỉ xác định
--alloc-fn = malloc2 sẽ không có hiệu lực. Bạn cần xác định --alloc-fn = malloc1 as
Tốt. Điều này hơi bất tiện, nhưng lý do là việc kiểm tra phân bổ
các chức năng chậm và sẽ tiết kiệm rất nhiều thời gian nếu Massif có thể ngừng xem qua
ngăn xếp các mục theo dõi ngay khi nó tìm thấy một mục không khớp thay vì phải
tiếp tục thông qua tất cả các mục.

Lưu ý rằng tên C ++ được gỡ bỏ. Cũng lưu ý rằng các tên C ++ bị quá tải phải được viết
đầy đủ. Các dấu ngoặc kép có thể cần thiết để ngăn không cho lớp vỏ bị phá vỡ.
Ví dụ:

--alloc-fn = 'operator new (unsigned, std :: nothrow_t const &)'

--ignore-fn =
Bất kỳ phân bổ heap trực tiếp nào (tức là một cuộc gọi đến malloc, mới, v.v. hoặc một lệnh gọi đến một hàm
được đặt tên bởi một --alloc-fn tùy chọn) xảy ra trong một chức năng được chỉ định bởi tùy chọn này sẽ
được bỏ qua. Điều này chủ yếu hữu ích cho các mục đích thử nghiệm. Tùy chọn này có thể được chỉ định
nhiều lần trên dòng lệnh, để đặt tên cho nhiều chức năng.

Bất kì phân bổ tài chính của một khối bị bỏ qua cũng sẽ bị bỏ qua, ngay cả khi phân bổ tài chính gọi không
không xảy ra trong một chức năng bị bỏ qua. Điều này tránh khả năng có kích thước đống âm
nếu các khối bị bỏ qua được thu nhỏ bằng phân bổ tài chính.

Các quy tắc để viết tên hàm C ++ giống như đối với --alloc-fn ở trên.

--threshold = [vỡ nợ: 1.0]
Ngưỡng ý nghĩa đối với phân bổ heap, theo tỷ lệ phần trăm của tổng dung lượng bộ nhớ.
Các mục nhập cây phân bổ chiếm ít hơn giá trị này sẽ được tổng hợp. Lưu ý rằng
điều này nên được chỉ định song song với tùy chọn cùng tên của ms_print.

--peak-thiếu chính xác = [vỡ nợ: 1.0]
Massif không nhất thiết phải ghi lại đỉnh cấp phát bộ nhớ toàn cầu thực tế; qua
mặc định nó chỉ ghi lại một đỉnh khi kích thước phân bổ bộ nhớ chung vượt quá
đỉnh trước đó ít nhất 1.0%. Điều này là do có thể có nhiều phân bổ địa phương
cao nhất trên đường đi và việc chụp nhanh chi tiết cho từng cái sẽ rất tốn kém
và lãng phí, vì tất cả ngoại trừ một trong số chúng sau này sẽ bị loại bỏ. Sự không chính xác này có thể
đã thay đổi (thậm chí thành 0.0%) thông qua tùy chọn này, nhưng Massif sẽ chạy chậm hơn đáng kể vì
số tiếp cận số không.

- đơn vị thời gian = [vỡ nợ: i]
Đơn vị thời gian được sử dụng để lập hồ sơ. Có ba khả năng: hướng dẫn
được thực thi (i), tốt cho hầu hết các trường hợp; thời gian thực (đồng hồ treo tường) (mili giây, tức là
mili giây), đôi khi hữu ích; và các byte được phân bổ / phân bổ giao dịch trên heap
và / hoặc ngăn xếp (B), hữu ích cho các chương trình chạy rất ngắn và để thử nghiệm
vì nó có thể tái tạo nhiều nhất trên các máy khác nhau.

--detailed-freq = [vỡ nợ: 10]
Tần suất của ảnh chụp nhanh chi tiết. Với --detailed-freq = 1, mọi ảnh chụp đều chi tiết.

- tối đa-ảnh chụp nhanh = [vỡ nợ: 100]
Số lượng ảnh chụp nhanh được ghi lại tối đa. Nếu được đặt thành N, đối với tất cả các chương trình ngoại trừ rất
những bức ảnh chạy ngắn hạn, số lượng ảnh chụp nhanh cuối cùng sẽ nằm trong khoảng N / 2 đến N.

--massif-out-file = [vỡ nợ: massif.out.% p]
Ghi dữ liệu hồ sơ vào tệp thay vì vào tệp đầu ra mặc định,
massif.out. . Các %p và %q các chỉ định định dạng có thể được sử dụng để nhúng ID quy trình
và / hoặc nội dung của một biến môi trường trong tên, như trường hợp của
lựa chọn cốt lõi --log-tệp.

KIỂM TRA LỰA CHỌN

Hiện tại không có tùy chọn dòng lệnh cụ thể cho SGCheck.

BBV LỰA CHỌN

--bb-out-file = [vỡ nợ: bb.out.% p]
Tùy chọn này chọn tên của tệp vectơ khối cơ bản. Các %p và %q định dạng
các chỉ định có thể được sử dụng để nhúng ID quy trình và / hoặc nội dung của môi trường
biến trong tên, như trường hợp của tùy chọn cốt lõi --log-tệp.

--pc-out-file = [vỡ nợ: pc.out.% p]
Tùy chọn này chọn tên của tệp PC. Tệp này chứa các địa chỉ bộ đếm chương trình
và thông tin tên chức năng cho các khối cơ bản khác nhau. Điều này có thể được sử dụng kết hợp
với tệp vectơ khối cơ bản để tua nhanh qua các tên hàm thay vì chỉ
số lượng hướng dẫn. Các %p và %q định dạng định dạng có thể được sử dụng để nhúng quá trình
ID và / hoặc nội dung của một biến môi trường trong tên, như trường hợp của
lựa chọn cốt lõi --log-tệp.

--interval-size = [vỡ nợ: 100000000]
Tùy chọn này chọn kích thước của khoảng thời gian sẽ sử dụng. Giá trị mặc định là 100 triệu
hướng dẫn, là một giá trị thường được sử dụng. Các kích thước khác có thể được sử dụng; nhỏ hơn
khoảng thời gian có thể giúp các chương trình có các giai đoạn chi tiết hơn. Tuy nhiên kích thước khoảng nhỏ hơn
có thể dẫn đến các vấn đề về độ chính xác do các hiệu ứng khởi động (Khi tua nhanh các
các tính năng kiến ​​trúc sẽ không được khởi tạo và sẽ mất một số
hướng dẫn trước khi chúng "khởi động" đến trạng thái, một mô phỏng đầy đủ sẽ không có
chuyển tiếp nhanh. Kích thước khoảng thời gian lớn có xu hướng giảm thiểu điều này.)

--instr-count-chỉ [vỡ nợ: không]
Tùy chọn này cho công cụ biết chỉ hiển thị tổng số lệnh và không
tạo tệp vectơ khối cơ bản thực tế. Điều này rất hữu ích cho việc gỡ lỗi và
thu thập thông tin về số lượng lệnh mà không cần tạo vectơ khối cơ bản lớn
các tập tin.

TAY SAI LỰA CHỌN

- số lượng cơ bản = [vỡ nợ: đúng]
Khi được bật, Lackey sẽ in các thống kê và thông tin sau về
thực hiện chương trình khách hàng:

1. Số lượng lệnh gọi đến hàm được chỉ định bởi --fnname tùy chọn (mặc định
là chính). Nếu chương trình bị tước ký hiệu, số lượng sẽ luôn là
số không.

2. Số lượng các nhánh có điều kiện gặp phải, số lượng và tỷ lệ
những người đã lấy.

3. Số lượng siêu khối được chương trình nhập và hoàn thành. Lưu ý rằng do
tối ưu hóa được thực hiện bởi JIT, đây hoàn toàn không phải là một giá trị chính xác.

4. Số lượng khách (x86, amd64, ppc, v.v.) hướng dẫn và báo cáo IR
Thực thi. IR là đại diện trung gian giống như RISC của Valgrind mà qua đó tất cả
thiết bị đo đạc được thực hiện.

5. Tỉ số giữa một số số đếm này.

6. Mã thoát của chương trình khách hàng.

--detailed-counts = [vỡ nợ: không]
Khi được bật, Lackey sẽ in một bảng chứa số lượng tải, cửa hàng và ALU
hoạt động, được phân biệt theo loại IR của chúng. Các loại IR được xác định bằng IR của chúng
tên ("I1", "I8", ... "I128", "F32", "F64" và "V128").

--trace-mem = [vỡ nợ: không]
Khi được kích hoạt, Lackey in kích thước và địa chỉ của hầu hết mọi truy cập bộ nhớ được thực hiện bởi
chương trình. Xem các nhận xét ở đầu tệp lackey / lk_main.c để biết chi tiết
về định dạng đầu ra, cách thức hoạt động và sự không chính xác trong dấu vết địa chỉ. Ghi chú
rằng tùy chọn này tạo ra một lượng lớn sản lượng.

--trace-superblocks = [vỡ nợ: không]
Khi được kích hoạt, Lackey sẽ in ra địa chỉ của mọi siêu khối (một mục nhập duy nhất,
nhiều lối ra, đoạn mã tuyến tính) được thực thi bởi chương trình. Điều này chủ yếu là của
quan tâm đến các nhà phát triển Valgrind. Xem các bình luận ở đầu tệp
lackey / lk_main.c để biết chi tiết về định dạng đầu ra. Lưu ý rằng tùy chọn này tạo ra
số lượng lớn sản lượng.

--fnname = [vỡ nợ: chủ yếu]
Thay đổi chức năng mà các cuộc gọi được tính khi --basic-counts = yes được quy định.

Sử dụng valgrind.bin trực tuyến bằng các dịch vụ onworks.net