The problem, I think, is the different way GDB handles breakpoints when
there are no debugging symbols.  If there are no debugging symbols,
"break" will break at the instruction's address listed for that global
symbol, in which case "break _start" works.  If there _are_ debugging
symbols, "break" tries to break after the function prologue.  Since
_start doesn't have a function prologue, it doesn't find the
appropriate place to break.  In that case, you need to break based on
the line number.  Break on the line of the _second_ instruction (for
some reason GDB has trouble breaking on the very first instruction).
In my case, "break 5" worked for me.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017

Sorry about the late response.  I had almost forgotten about this
thread!

Yeah, I read online somewhere that the common workaround is to do
exactly what you describe, so what I have done is just add a NOP as
the first instruction following _start, and told gdb to "break
*_start+1."  I just wanted to know why doing "break _start" didn't
work, even though telling gcc to make the file, using -nostartfiles,
resulted in a file that did work when I told gdb to "break _start."

Remember that calling GCC with "-v -nostartfiles" just calls "as" with
options that (as far as I can tell) do not result in a difference in
the symbols exported from those which are included when I run "as" by
myself with my options.  I prove this below; ld is the key.

Looking at gcc's steps, you can see that it runs the linker
("collect2," which, when you run it with the option "-v" simply
identifies itself as ld) with a ton of options, including automatic
linking with libc and libgcc.

I ran ld on my as-assembled object file, with the -lc option, and the
result was a file with the exact same size as the gcc-produced one,
but with a different md5sum.  When I tried to run it, I got the error
"bash: ./first.3: /usr/lib/libc.so.1: bad ELF interpreter: No such
file or directory."  Whoops, that's interesting, /usr/lib/libc.so.1
doesn't exist, and not only that, the gcc-version has
"/lib/ld-linux.so.2" where my file has "/usr/lib/libc.so.1" so I guess
that's the entry for the dynamic linker or the ELF
interpreter/loader/executor/whatever.  It's a learning process!

Anyway, so I ran ld with "-lc" and "-dynamic linker
/lib/ld-linux.so.2," and it ran fine, and broke at _start when I told
gdb to do it.

It seems like a shame that I have to link with libc just to do
breakpoints properly.  After all, GAS and GDB should be bosom buddies.
 If anyone can enlighten me to why this is (or direct me to proper
resources) without too much fuss, please do!

Thank you very much for your input.

spamtrap@crayne.org wrote in message news:<cekfon$n9@odbk17.prod.google.com>...
> The problem, I think, is the different way GDB handles breakpoints when
> there are no debugging symbols.  If there are no debugging symbols,
> "break" will break at the instruction's address listed for that global
> symbol, in which case "break _start" works.  If there _are_ debugging
> symbols, "break" tries to break after the function prologue.  Since
> _start doesn't have a function prologue, it doesn't find the
> appropriate place to break.  In that case, you need to break based on
> the line number.  Break on the line of the _second_ instruction (for
> some reason GDB has trouble breaking on the very first instruction).
> In my case, "break 5" worked for me.
> 
> Jon
> ----
> Learn to program using Linux assembly language
> http://www.cafeshops.com/bartlettpublish.8640017