<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/test/API/functionalities/executable_first, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[lldb] Fix Python test formatting (NFC)</title>
<updated>2024-02-16T06:54:00+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-02-16T06:53:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=096c530ab3ea5c96526451181117f30db17b4b1d'/>
<id>096c530ab3ea5c96526451181117f30db17b4b1d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Skip TestExecutableFirst.test_executable_is_first_before_run on ELF</title>
<updated>2024-01-17T10:36:44+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2024-01-17T10:34:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=15311d5822f5fcaf53bc7cfc728ad2b477a430e4'/>
<id>15311d5822f5fcaf53bc7cfc728ad2b477a430e4</id>
<content type='text'>
ELF does not have a hard distinction between shared libraries (and
position-independent) executables. It is possible to create a shared
library that will also be executable.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ELF does not have a hard distinction between shared libraries (and
position-independent) executables. It is possible to create a shared
library that will also be executable.
</pre>
</div>
</content>
</entry>
<entry>
<title>Add the Linux "you can use this binary" bits to run_to_source_breakpoint (#78377)</title>
<updated>2024-01-17T01:54:12+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2024-01-17T01:54:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=705c5b80ace9d6fb1b9d1129ca1529d6645f1f24'/>
<id>705c5b80ace9d6fb1b9d1129ca1529d6645f1f24</id>
<content type='text'>
Follow-on to a4cd99ea8736eda2b8b4de34453f55008bcf9c30 - I forgot you
have to add ANY shared library you want to use to extra_images...</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Follow-on to a4cd99ea8736eda2b8b4de34453f55008bcf9c30 - I forgot you
have to add ANY shared library you want to use to extra_images...</pre>
</div>
</content>
</entry>
<entry>
<title>Ensure that the executable module is ModuleList[0] (#78360)</title>
<updated>2024-01-17T01:12:32+00:00</updated>
<author>
<name>jimingham</name>
<email>jingham@apple.com</email>
</author>
<published>2024-01-17T01:12:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a4cd99ea8736eda2b8b4de34453f55008bcf9c30'/>
<id>a4cd99ea8736eda2b8b4de34453f55008bcf9c30</id>
<content type='text'>
We claim in a couple places that the zeroth element of the module list
for a target is the main executable, but we don't actually enforce that
in the ModuleList class. As we saw, for instance, in

32dd5b20973bde1ef77fa3b84b9f85788a1a303a

it's not all that hard to get this to be off. This patch ensures that
the first object file of type Executable added to it is moved to the
front of the ModuleList. I also added a test for this.

In the normal course of operation, where the executable is added first,
this only adds a check for whether the first element in the module list
is an executable. If that's true, we just append as normal.

Note, the code in Target::GetExecutableModule doesn't actually agree
that the zeroth element must be the executable, it instead returns the
first Module of type Executable. But I can't tell whether that was a
change in intention or just working around the bug that we don't always
maintain this ordering. But given we've said this in scripting as well
as internally, I think we shouldn't change our minds about this.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We claim in a couple places that the zeroth element of the module list
for a target is the main executable, but we don't actually enforce that
in the ModuleList class. As we saw, for instance, in

32dd5b20973bde1ef77fa3b84b9f85788a1a303a

it's not all that hard to get this to be off. This patch ensures that
the first object file of type Executable added to it is moved to the
front of the ModuleList. I also added a test for this.

In the normal course of operation, where the executable is added first,
this only adds a check for whether the first element in the module list
is an executable. If that's true, we just append as normal.

Note, the code in Target::GetExecutableModule doesn't actually agree
that the zeroth element must be the executable, it instead returns the
first Module of type Executable. But I can't tell whether that was a
change in intention or just working around the bug that we don't always
maintain this ordering. But given we've said this in scripting as well
as internally, I think we shouldn't change our minds about this.</pre>
</div>
</content>
</entry>
</feed>
